Core Web Vitals são três métricas que o Google usa para descrever como uma página se comporta para quem visita de verdade: Largest Contentful Paint (LCP) mede o carregamento, Interaction to Next Paint (INP) mede a resposta a cliques e toques, e Cumulative Layout Shift (CLS) mede a estabilidade visual. O Google coleta esses dados de usuários reais do Chrome e avalia cada métrica no percentil 75 das visitas. A página está boa quando o LCP fica em até 2,5 segundos, o INP em até 200 milissegundos e o CLS em até 0,1. O INP substituiu o First Input Delay em março de 2024.
Essa é a resposta curta. A longa importa mais, porque boa parte da confusão que encontro em auditoria vem de gente lendo o número certo na ferramenta errada, ou corrigindo uma métrica que nunca foi o problema. Aqui explico o que cada métrica mede, de onde vêm os números e como ler. Se o seu site é WordPress e você quer a ordem de correção, siga depois para o guia completo de Core Web Vitals no WordPress.
O que são as Core Web Vitals, uma por uma?
Cada métrica responde a uma pergunta que o visitante faria sem conhecer o vocabulário.
- LCP: quando o conteúdo principal apareceu? É o tempo de renderização da maior imagem ou bloco de texto visível na tela.
- INP: quando eu toquei ou cliquei, quanto tempo a página levou para responder na tela? Ele observa a latência das interações durante toda a visita e reporta uma das mais lentas.
- CLS: as coisas pularam enquanto eu lia? Ele soma os deslocamentos de layout inesperados, agrupados em janelas, e reporta a maior rajada.
Repare no que ficou de fora. Peso total da página, número de requisições e nota do Lighthouse não são Core Web Vitals. Podem explicar uma métrica ruim, mas o Google não avalia nenhum deles.
Quais são os limites de bom, precisa melhorar e ruim?
O Google publica três faixas para cada métrica. O valor que conta é o percentil 75 das visitas reais: três em cada quatro visitas precisam estar dentro da faixa boa para a página passar naquela métrica.
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP | Carregamento do conteúdo principal | Até 2,5 s | Acima de 2,5 s até 4 s | Acima de 4 s |
| INP | Resposta a interações | Até 200 ms | Acima de 200 ms até 500 ms | Acima de 500 ms |
| CLS | Estabilidade visual | Até 0,1 | Acima de 0,1 até 0,25 | Acima de 0,25 |
O percentil 75 é uma escolha pensada. A média esconde quem acessa de celular fraco e rede ruim. O p75 obriga você a cuidar de uma fatia grande dessas pessoas sem deixar que meia dúzia de casos extremos decida o resultado.
De onde o Google tira os dados de Core Web Vitals?
Do Chrome User Experience Report, o CrUX. Ele coleta dados de desempenho de usuários do Chrome que aceitaram compartilhar estatísticas de uso e agrega tudo por URL e por origem, numa janela móvel de 28 dias. Isso é dado de campo: aparelho real, rede real, gente real rolando a tela e tocando em botões.
Os números do CrUX aparecem em alguns lugares:
- No PageSpeed Insights, na seção do topo, junto com a avaliação das Core Web Vitals.
- No relatório Core Web Vitals do Google Search Console, que agrupa URLs parecidas.
- Na API do CrUX e no conjunto público no BigQuery, para quem quer os dados brutos.
Quando uma página não recebe tráfego suficiente do Chrome, o CrUX não tem dado no nível da URL. O PageSpeed Insights então mostra a origem, ou seja, o site inteiro, e o Search Console junta a URL com páginas semelhantes. Site pequeno muitas vezes só tem dado de origem. Isso é normal e já diz bastante coisa.
A janela de 28 dias tem um efeito prático que muita gente esquece: depois que você publica uma correção, os números de campo mudam aos poucos, ao longo de umas quatro semanas. Se o relatório estiver igual no dia seguinte, nada quebrou.
Dado de campo ou de laboratório: qual vale?
Para a avaliação, vale o dado de campo. Dado de laboratório é o que uma ferramenta como o Lighthouse produz ao carregar a página uma vez, num aparelho emulado, com uma rede simulada. É repetível e ótimo para depurar, mas é uma visita sintética, não o seu público.
O INP mostra bem a diferença. Num teste de laboratório ninguém clica, então o Lighthouse não consegue reportar INP num carregamento normal. Ele mostra o Total Blocking Time, que aponta para o mesmo problema (tarefas longas de JavaScript na thread principal) sem ser o mesmo número. Escrevi mais sobre isso em dados de campo vs dados de laboratório nas Core Web Vitals, e as duas ferramentas do Google que mostram cada tipo estão comparadas em PageSpeed Insights vs Lighthouse.
Minha regra nas auditorias: o dado de campo diz se existe problema e em quais templates. O laboratório e o DevTools dizem o porquê.
Por que o INP substituiu o FID?
O First Input Delay media só o atraso até o navegador começar a tratar a primeira interação. Ignorava quanto tempo o próprio handler rodava, ignorava o tempo para pintar o resultado e ignorava todas as interações depois da primeira. Quase todo site passava com folga, o que fazia dele um sinal fraco.
O INP cobre o ciclo inteiro da interação (atraso de entrada, tempo de processamento e o atraso até o próximo quadro ser pintado) e considera as interações da visita toda. O Google transformou o INP em Core Web Vital em março de 2024 e aposentou o FID. No WordPress, é a métrica que expõe page builder pesado, script de plugin rodando a cada clique e tag de terceiros. Os detalhes estão em como corrigir o INP no WordPress.
As Core Web Vitals são iguais no celular e no desktop?
Os limites são os mesmos. Os dados são separados. O CrUX reporta visitas de celular e de desktop de forma independente, e tanto o PageSpeed Insights quanto o Search Console mostram cada uma numa aba.
Na prática, o celular quase sempre está pior, porque o processador é mais lento e a rede varia mais. Um site WordPress pode passar no desktop e reprovar no celular com o mesmo HTML. Quando um cliente me diz “nossas Core Web Vitals estão ótimas”, a primeira coisa que confiro é qual aba ele estava olhando.
O que costuma derrubar cada métrica?
Vejo os mesmos padrões o tempo todo. Não são as únicas causas, mas são onde eu olho primeiro.
- LCP: servidor lento por falta de cache de página, imagem de destaque com lazy load, imagem em tamanho de desktop servida para celular e CSS e JavaScript bloqueando a renderização. Veja LCP no WordPress.
- INP: JavaScript demais na thread principal, vindo de builder, slider, chat, analytics e anúncios, além de DOM muito grande.
- CLS: imagens e embeds sem largura e altura, fontes web que trocam com métricas diferentes, banner de cookies e barra promocional inseridos acima do conteúdo e anúncios sem espaço reservado. Veja CLS no WordPress.
O TTFB merece menção, mesmo não sendo Core Web Vital. Um primeiro byte lento atrasa tudo que vem depois e puxa o LCP para baixo direto. A orientação do Google considera bom até 0,8 segundo. Se a resposta do servidor está lenta, comece por ela.
Como verificar as Core Web Vitals do meu site?
Uma ordem simples que funciona em qualquer site:
- Abra o PageSpeed Insights, coloque uma URL importante e leia primeiro a seção de dados de campo. Confira a visão da URL e a da origem, no celular e no desktop.
- Abra o Search Console, vá ao relatório Core Web Vitals e veja quais grupos de URLs reprovam e em qual métrica.
- Escolha o pior template, abra no Chrome DevTools e use o painel Performance para achar a causa.
- Só então rode o Lighthouse para confirmar a correção em laboratório antes de publicar.
Se o site tem pouco tráfego e nenhum dado no CrUX, adicione monitoramento de usuário real. A biblioteca JavaScript web-vitals, do Google, reporta as mesmas métricas a partir dos seus visitantes, e a versão de atribuição mostra qual elemento ou interação gerou o número.
Perguntas frequentes
Quantas Core Web Vitals existem?
Três: LCP, INP e CLS. O Google pode mudar o conjunto com o tempo, e já mudou uma vez, quando o INP substituiu o FID em março de 2024. Outras métricas, como TTFB e First Contentful Paint, ajudam no diagnóstico, mas não são Core Web Vitals.
Preciso de nota perfeita no PageSpeed para passar?
Não. A nota de performance do Lighthouse é um número de laboratório e não entra na avaliação. Uma página pode tirar 60 e poucos e passar nos dados de campo, ou tirar 95 e reprovar porque visitantes reais em celular fraco veem um LCP tardio.
Quanto tempo leva para uma correção aparecer nos dados?
O CrUX usa uma janela móvel de 28 dias, então conte com umas quatro semanas para os números de campo mudarem depois que a alteração entra no ar. As ferramentas de laboratório mostram o efeito na hora, por isso uso o laboratório para confirmar a correção e o campo para confirmar o resultado.
Se você quer alguém para ler os seus dados de campo, achar os templates que reprovam e dizer o que corrigir primeiro, é esse o trabalho que faço como especialista em Core Web Vitals.