Core Web Vitals: Como medir, corrigir e otimizar
Core Web Vitals é o conjunto de 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, por exemplo. Apesar de já estarem no radar há cinco anos, a maioria dos sites ainda falha em pelo menos uma delas, quase sempre por motivos previsíveis e corrigíveis.
Este artigo explica o que cada métrica mede, por que mesmo sites grandes continuam falhando, como medir corretamente e quais são as correções que efetivamente importam.
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 aprovado em uma única dimensão: o Google considera "aprovado" apenas o site que passa nas três simultaneamente, e somente em field data, ou seja, dados de usuários reais.
| Métrica | O que mede | Valor "Bom" | Valor "Ruim" |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Tempo até o maior elemento visível ser renderizado | até 2,5s | acima de 4s |
| INP (Interaction to Next Paint) | Latência de resposta da página a cada interação do usuário | até 200ms | acima de 500ms |
| CLS (Cumulative Layout Shift) | Quanto os elementos da página "pulam" durante o carregamento | até 0,1 | acima de 0,25 |
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 accordion). 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 os sites ainda falham nessas métricas
De acordo com um levantamento anual feito pelo HTTP Archive, cinco causas explicam mais de 90% dos problemas. Nenhuma delas é exótica, mas são padrões repetidos por equipes que não priorizam a performance na etapa de planejamento dos sites.
Conteúdo "above-the-fold" pesado. Uma página com vídeo em autoplay, slider de imagens em alta resolução 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 que acontece é que o texto ao redor renderiza primeiro e, quando a imagem é carregada, empurra tudo para baixo. Esse deslocamento é o que aumenta o CLS.
Scripts e lógica pesada na thread principal. O problema com o INP não está nos scripts que carregam de forma assíncrona, como os de analytics e pixels de mídia, mas no que acontece na interação. Handlers de evento com lógica pesada, re-renders em cascata em frameworks JavaScript, DOM excessivamente grande e janelas de hidratação em sites SSR são os culpados mais frequentes, todos eles bloqueiam a main thread no momento exato em que o usuário age. É aí que o INP é medido, e é aí que a maioria dos sites perde pontos.
Web fonts em excesso. Cada família e peso de fonte é uma requisição de rede. Páginas que carregam muitos 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.
A diferença entre lab data e field data
Existe uma distinção crítica entre os dois tipos de dado de Core Web Vitals, e ela é fonte recorrente de confusão.
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.
Para sites com volume baixo de tráfego, não há field data suficiente no CrUX e você trabalha apenas com lab. A implicação prática é a seguinte: 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, como um grupo grande de usuários em conexões ou um dispositivo Android antigo dominante na base.
Como corrigir cada métrica
Otimizar LCP: priorize o elemento principal e use um CDN
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>, pois 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. Esse tipo de entrega reduz drasticamente o time-to-first-byte, que alimenta diretamente o LCP. Para a maioria dos sites brasileiros, com servidores concentrados em São Paulo e usuários em todo o país, ativar uma CDN é a mudança isolada com maior efeito sobre LCP.
Veja o artigo completo em Como otimizar LCP.
Otimizar CLS: defina dimensões para cada elemento de mídia
Toda imagem, vídeo e slot de anúncio precisa ter altura e largura explícitos no HTML. Se o layout é responsivo, defina a proporção via aspect-ratio no CSS e deixe o tamanho fluido, pois o navegador só precisa de informação suficiente para reservar o espaço antes do recurso carregar.
Evite inserir conteúdo acima de outro 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.
Veja o artigo completo em Como otimizar CLS.
Otimizar 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.
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ípicos 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.
Veja o artigo completo em Como otimizar INP.
Quanto Core Web Vitals realmente afetam o ranqueamento
O Google deixou claro em comunicações oficiais que qualidade e relevância de conteúdo continuam pesando muito mais e Core Web Vitals são um fator de desempate, não o sinal dominante. Um site com performance impecável e conteúdo raso não vai superar um concorrente com conteúdo profundo, mesmo que esse concorrente não tenha CWV tão bons.
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, como tempo na página, retornos e conversões, são observáveis pelo Google e incorporados nas decisões de ranking de forma indireta.
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.
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 e sem monitoramento, qualquer melhoria pode regredir em poucos meses.
Quatro pontos recomendados para times de marketing e SEO:
Auditoria pré-publicação obrigatória. O controle de qualidade precisa acontecer no ambiente de homologação, não em produção. Antes de qualquer publicação de nova página ou alteração de modelo de página, rode o PageSpeed Insights na URL de homologação com a configuração de dispositivo móvel e registre LCP, INP e CLS separadamente para celular e computador. O que vale registrar não é só a pontuação geral, mas o elemento de LCP identificado e os scripts de terceiros listados porque esses dois fatores são os que mais mudam entre publicações e os primeiros a explicar regressões futuras.
Para times com acesso ao código, o PageSpeed Insights tem uma API gratuita que permite automatizar esse controle como etapa do pipeline de entrega: a publicação só avança se as três métricas estiverem na faixa "Bom". Para quem não tem esse nível de automação, uma lista de verificação preenchida antes de cada publicação já elimina a maioria das regressões por descuido.
Revisão mensal do Search Console. No Search Console, o relatório fica em Experiência → Core Web Vitals e apresenta URLs agrupadas por status (Bom, Precisa de melhorias, Ruim) e por tipo de dispositivo. O primeiro passo é segmentar por modelo de página, não por URL individual, pois um problema em 200 páginas de produto quase sempre tem a mesma causa raiz e é tratado uma vez só.
O segundo passo é correlacionar qualquer mudança no relatório com o histórico de publicações. Se um modelo de página que estava em "Bom" entrou em "Precisa de melhorias" entre duas revisões, a causa mais provável é alguma alteração ocorrida nesse intervalo, como um script novo, mudança de layout, plugin adicionado. Sem um registro de publicações paralelo, esse diagnóstico vira adivinhação.
O Search Console opera com uma janela móvel de 28 dias de dados reais de usuários, então uma correção implementada hoje vai demorar semanas para aparecer no relatório. Use o PageSpeed Insights para confirmar que a correção funcionou no curto prazo e use o Search Console para confirmar o ganho consolidado nos dados de campo.
Documentação de evolução. A planilha de acompanhamento precisa registrar mais do que os três números. Para ser útil como ferramenta de diagnóstico retroativo, cada entrada mensal deve incluir: data da captura, modelo de página avaliado, valores de LCP, INP e CLS em celular e computador, elemento de LCP identificado, lista de scripts de terceiros ativos na página e qualquer publicação ou alteração relevante ocorrida no período. Essa última coluna é o que transforma a planilha em um registro de causalidade para que quando uma regressão em CWV ocorrer, a investigação comece pela coluna de alterações, não pelo número em si.
Uma prática útil é capturar os dados sempre na mesma semana do mês e sempre a partir das mesmas URLs de referência por modelo de página Isso elimina variação de amostra e torna as comparações mês a mês mais confiáveis.
Priorização quando os recursos são limitados A priorização mais eficiente parte de dois critérios: volume de tráfego do modelo de página e impacto da métrica no comportamento do usuário. Modelos de página com alto tráfego em "Ruim" têm prioridade absoluta, já que são os que mais afetam os dados de campo e os que mais aparecem nos relatórios do Google. Dentro desses modelos, LCP e CLS costumam ser mais rápidos de corrigir do que INP. LCP frequentemente se resolve com prioridade de carregamento na imagem principal e uso de rede de distribuição de conteúdo e CLS se resolve com dimensões explícitas nos elementos de mídia. INP quase sempre exige investigação mais profunda do JavaScript e, quando a causa não é evidente, é o caso que mais justifica envolver alguém com experiência específica em desempenho web.
Times que tratam Core Web Vitals como parte do ciclo normal de QA sustentam performance ao longo do tempo. Os demais entram num ciclo previsível de regressão, auditoria emergencial, 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 (First Input Delay) 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. Algumas melhorias são de configuração ou operação, como ativar CDN, otimização de imagens via CMS ou mesmo antes de subir e desativação de tags de terceiros não essenciais podem ser feitas sem alterar o código. Correções estruturais, por outro lado, exigem alteração no código-fonte: adicionar fetchpriority="high" na imagem hero, declarar dimensões explícitas a imagens para evitar CLS, ou dividir bundles JavaScript pesados com code splitting. Tudo que você controla via painel, plugin ou GTM pode ser feito sem dev. Tudo que está no template, no HTML ou no JavaScript do site precisa de alguém com acesso ao código.
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?
Em parte. Plataformas como Shopify, Webflow e WordPress com tema nativo aplicam por padrão práticas como WebP, lazy loading e minificação de CSS — o que melhora o ponto de partida. O problema começa quando o site cresce: um tema de marketplace com dezenas de arquivos JS embutidos, um builder de página como Elementor ou Divi carregando blocos não utilizados, ou um pixel de parceiro adicionado fora do GTM são suficientes para anular esses ganhos. A plataforma reduz o esforço inicial, não elimina a necessidade de auditoria.
Para validar se sua página atende ao critério de INP e aos outros 60+ critérios técnicos de SEO, use o SEO Check. Para entender se seu site está preparado para ser citado por motores de busca generativa como ChatGPT, Perplexity e Copilot, use o GEO Check.