Core Web Vitals em 2026

Core Web Vitals são três métricas que o Google usa para avaliar se uma página entrega boa experiência de uso: LCP (velocidade de carregamento do elemento principal), INP (responsividade a interações) e CLS (estabilidade visual).

Elas são fator de ranqueamento desde 2021 e influenciam diretamente conversão, taxa de rejeição e custo de mídia paga. Apesar de já estarem no radar há cinco anos, a maioria dos sites corporativos ainda falha em pelo menos uma delas — e quase sempre por motivos previsíveis e corrigíveis.

Este artigo explica o que cada métrica mede, por que sites grandes continuam falhando, como medir corretamente (lab vs field data) e quais são as correções que efetivamente movem o ponteiro.

O que cada métrica mede e qual é o valor considerado bom

As três métricas avaliam dimensões distintas da experiência percebida pelo usuário. Não basta ter um site rápido em uma única dimensão — o Google considera "aprovado" apenas o site que passa nas três simultaneamente, e somente em field data (dados de usuários reais).

O INP substituiu o FID (First Input Delay) em março de 2024 e é a métrica mais punitiva do trio. Enquanto o FID media apenas o atraso da primeira interação, o INP avalia a responsividade ao longo de toda a sessão — clicar em um menu, abrir um filtro, expandir um acordeão. Isso significa que sites com muito JavaScript no client-side, especialmente os baseados em frameworks pesados, regrediram visivelmente quando a métrica mudou.

Por que grandes empresas ainda falham nessas métricas

Em auditorias que conduzo em sites corporativos de médio e grande porte, cinco causas explicam mais de 90% dos problemas. Nenhuma delas é exótica — são padrões repetidos por equipes que tratam performance como tarefa de fim de sprint.

Conteúdo "above-the-fold" pesado. Uma home com vídeo em autoplay, slider de imagens em largura total e widget de chat carregando ao mesmo tempo praticamente garante reprovação em LCP. O navegador precisa resolver todos esses recursos antes de pintar o maior elemento visível.

Imagens sem dimensões definidas. Quando uma <img> carrega sem atributos width e height, o navegador não reserva espaço para ela. O texto ao redor renderiza primeiro e, quando a imagem chega, empurra tudo para baixo. Esse "pulo" é o CLS.

Scripts de terceiros bloqueando a thread principal. Tags de analytics, pixels de mídia, ferramentas de chat e gerenciadores de tags rodam na main thread. Quando se acumulam — e raramente são auditados — cada clique do usuário entra em fila de espera. Um único script de terceiro mal otimizado tira um site inteiro do "Bom" em INP.

Web fonts em excesso. Cada família e peso de fonte é uma requisição de rede. Páginas que carregam quatro arquivos de fonte antes de renderizar texto inevitavelmente reprovam em LCP, especialmente em conexões móveis.

Imagens em formato e resolução errados. JPEG e PNG servidos em resolução desktop para usuários mobile, sem compressão, sem WebP ou AVIF, adicionam peso desnecessário em todo carregamento.

Lab data e field data: a diferença que ninguém explica para o cliente

Existe uma distinção crítica entre os dois tipos de dado de Core Web Vitals, e ela é fonte recorrente de confusão em reuniões de status com diretoria.

Lab data vem de ferramentas como PageSpeed Insights, Lighthouse e WebPageTest. São simulações em ambiente controlado — um navegador headless rodando em hardware padrão, em uma rede simulada. Lab data é útil para diagnosticar gargalos específicos e validar correções antes do deploy, mas não é o que o Google usa para ranquear.

Field data (também chamado de Real User Monitoring, ou RUM) vem de usuários reais do Chrome, agregado pelo Chrome User Experience Report (CrUX). É exatamente esse dado que aparece no Search Console, e é ele que pesa como sinal de ranqueamento. Field data quase sempre é pior que lab data, porque reflete a variabilidade real de dispositivos, conexões e localização geográfica dos usuários.

A implicação prática: um site pode pontuar 95 no PageSpeed Insights (lab) e ainda assim ser classificado como "Precisa de melhorias" no Search Console (field). Quando isso acontece, o problema costuma estar em segmentos de usuário invisíveis no lab — um grupo grande de usuários em conexão 3G, ou um dispositivo Android antigo dominante na base.

Para sites com volume baixo de tráfego, não há field data suficiente no CrUX, e você trabalha apenas com lab. É importante deixar isso claro com a diretoria desde o início, para evitar a expectativa de que melhorias apareçam imediatamente no Search Console.

Como corrigir cada métrica de forma cirúrgica

LCP: priorize o elemento principal e entregue pela borda

A correção mais barata e de maior impacto para LCP é adicionar fetchpriority="high" na tag da imagem hero. Esse atributo, suportado em todos os navegadores modernos desde 2023, instrui o browser a priorizar aquele recurso acima dos demais. Se o hero é uma imagem de fundo CSS, troque para <img> — imagens de fundo não são descobertas pelo preload scanner do navegador.

Em paralelo, verifique se o hosting serve as imagens via CDN com cache de borda. Entrega via edge reduz drasticamente o time-to-first-byte, que alimenta diretamente o LCP. Para a maioria dos sites corporativos brasileiros, com servidor único em São Paulo e usuários em todo o país, ativar uma CDN é a mudança isolada com maior efeito sobre LCP regional.

CLS: defina dimensões para cada elemento de mídia

Toda imagem, vídeo e slot de anúncio precisa de width e height explícitos no HTML. Se o layout é responsivo, defina a proporção via aspect-ratio no CSS e deixe o tamanho fluido — o navegador só precisa de informação suficiente para reservar o espaço antes do recurso carregar.

Evite inserir conteúdo acima de conteúdo já existente após o load. É o que acontece com banners de cookies, headers fixos que mudam de altura ao rolar e blocos de anúncio dinâmicos. Quando esses elementos são necessários, ancore-os em posições fixas para que não empurrem nada.

INP: reduza a competição pela thread principal

Audite os scripts de terceiros e remova ou adie o que não for essencial. O painel Performance do Chrome DevTools mostra exatamente quais scripts bloqueiam a main thread e por quanto tempo. Em uma auditoria recente em um e-commerce de moda, identifiquei 18 tags carregando antes do DOMContentLoaded — apenas três eram realmente necessárias para a operação inicial da página.

Carregue chat, analytics e tags publicitárias de forma assíncrona, depois do caminho crítico. Para a maioria dos cenários, mover scripts não essenciais para depois do DOMContentLoaded é uma melhoria significativa de INP sem nenhum impacto visível para o usuário final.

Para aplicações com bundles JavaScript pesados — típico de SPAs em React, Vue ou Angular — quebre tarefas longas em pedaços menores usando a Scheduler API ou simplesmente dividindo componentes, de forma que a thread principal nunca fique bloqueada por mais de 50 milissegundos seguidos.

Quanto Core Web Vitals realmente afetam o ranqueamento

Sendo direto: Core Web Vitals são um fator de desempate, não o sinal dominante. O Google deixou isso claro em comunicações oficiais — qualidade e relevância de conteúdo continuam pesando muito mais. Um site com performance impecável e conteúdo raso não vai superar um concorrente com conteúdo profundo, mesmo que esse concorrente tenha CLS de 0,15.

O que Core Web Vitals afetam de fato é a experiência que sustenta o ranqueamento. Páginas com LCP ruim têm taxa de rejeição mensuravelmente maior. Sites com CLS alto perdem usuários no meio da sessão. E esses sinais comportamentais — tempo na página, retornos, conversões — são observáveis pelo Google e incorporados nas decisões de ranking de forma indireta.

Para gestores de marketing, o argumento mais forte para investir em Core Web Vitals não é SEO direto: é receita. Um estudo da Renault em parceria com a consultoria fifty-five, publicado pelo Google no web.dev, mostrou que cada segundo de melhoria em LCP correlacionou com queda de 14 pontos percentuais na taxa de rejeição e aumento de 13% nas conversões, em uma base analítica de 10 milhões de visitas. Casos posteriores reforçaram a direção do efeito em magnitudes variáveis: o QuintoAndar reduziu LCP em 26% e bounce rate em 46%; a Vodafone, com 31% de melhoria em LCP, registrou 8% de aumento em vendas; a Carpe, em 2023, melhorou LCP em 52% e aumentou receita em 15%. Para sites que monetizam por leads ou e-commerce, essa é uma conta que se paga rapidamente.

Processo recorrente: como integrar Core Web Vitals à operação

Core Web Vitals não são correção de uma única vez. Plataformas mudam, scripts novos são adicionados, campanhas trazem widgets de parceiros. Sem processo recorrente, qualquer melhoria regride em três a seis meses.

O processo que recomendo para times de marketing e produto em grandes empresas tem quatro pontos:

1. Auditoria pré-launch obrigatória. Toda nova página, landing ou release entra em PageSpeed Insights antes de ir ao ar. LCP, INP e CLS de mobile e desktop são registrados. Qualquer métrica em "Precisa de melhorias" ou "Ruim" trava o deploy até correção.
2. Revisão mensal do Search Console. O relatório de Core Web Vitals do Search Console mostra problemas em field data conforme aparecem. Detectar uma regressão na primeira semana é trivial; explicar uma queda de tráfego três meses depois, não.
3. Documentação de evolução. Diretoria não enxerga métricas técnicas espontaneamente. Um relatório mensal de uma página, mostrando antes/depois com impacto em conversão, transforma trabalho técnico em valor visível para o C-level.
4. Mobile-first sempre. O Google indexa mobile primeiro, e field data mostra que CWV mobile é quase sempre pior que desktop. Quando há trade-off de prioridade, mobile vence.

Empresas que tratam Core Web Vitals como parte do ciclo normal de QA — e não como projeto pontual quando o ranking cai — são as que sustentam performance ao longo do tempo. As demais entram num ciclo previsível de regressão, auditoria emergencial e nova regressão.

Perguntas frequentes sobre Core Web Vitals

Preciso passar nas três métricas para ter o boost de ranqueamento?

Sim. O Google considera o site aprovado em Core Web Vitals apenas quando LCP, INP e CLS estão simultaneamente na faixa "Bom" no field data. Passar em duas e falhar em uma equivale, para fins de ranqueamento, a falhar nas três.

O INP é mais difícil de otimizar que o FID era?

Sim, consideravelmente. O FID media apenas o atraso da primeira interação do usuário, geralmente em uma página recém-carregada. O INP avalia a responsividade ao longo de toda a sessão, o que expõe problemas que o FID nunca capturava — como menus lentos, filtros que travam e formulários que demoram para responder.

Como saber se meu site tem field data suficiente para aparecer no Search Console?

O Chrome User Experience Report exige um volume mínimo de visitas únicas em um período de 28 dias para gerar dados agregados. Sites com tráfego abaixo de aproximadamente 1.000 visitas mensais via Chrome geralmente não terão field data e dependem apenas de lab data via PageSpeed Insights.

Posso melhorar Core Web Vitals sem mexer no código do site?

Parcialmente. CDN, otimização de imagens via serviços de borda e desativação de tags de terceiros não essenciais podem ser feitas sem deploy. Mas correções estruturais — fetchpriority, dimensões de imagem, divisão de bundles JavaScript — exigem alteração no código-fonte.

Quanto tempo leva para o Google atualizar os scores após uma correção?

O Search Console atualiza Core Web Vitals com base em uma janela móvel de 28 dias de field data. Isso significa que, mesmo após uma correção 100% efetiva, o relatório oficial só refletirá a melhora após algumas semanas. Use lab data para validar correções no curto prazo e field data para confirmar o ganho consolidado.

Plataformas de site otimizadas resolvem Core Web Vitals automaticamente?

Apenas em parte. Plataformas modernas aplicam por padrão práticas como WebP, lazy loading e minificação de CSS, o que melhora o ponto de partida. Mas qualquer customização agressiva — temas de terceiros, sliders pesados, integrações de marketing — pode anular esses ganhos. A plataforma reduz o esforço, não elimina a necessidade de auditoria.