Core Web Vitals Explicado Sem Jargão

Você abriu o PageSpeed Insights, viu três siglas em vermelho e um número que não explica nada. LCP, INP, CLS. Este artigo traduz cada uma delas, mostra o limiar oficial que o Google usa para dizer se a sua página passa ou não, e lista as correções que resolvem a maior parte dos problemas reais.

O que o Google realmente mede

Core Web Vitals é um conjunto de três métricas que tentam responder três perguntas sobre a experiência de quem abre a sua página:

1. Carregou rápido o que importa? Isso é o LCP.
2. Quando eu cliquei, respondeu rápido? Isso é o INP.
3. O conteúdo ficou parado ou pulou na minha cara? Isso é o CLS.

Repare no que não está nessa lista. Não está o tempo total de carregamento. Não está o número de requisições. Não está a nota de 0 a 100 do Lighthouse. O Google escolheu medir percepção, não estatística de servidor. Uma página pode levar oito segundos para terminar de carregar tudo e mesmo assim passar nas três métricas, desde que o conteúdo principal apareça cedo, responda ao toque e não se mova.

Cada métrica tem três faixas: boa, precisa melhorar e ruim. Para uma página ser considerada aprovada, ela precisa estar na faixa boa nas três métricas, e essa avaliação usa o percentil 75 dos acessos reais. Ou seja: não basta ser rápido para você, no seu computador. Precisa ser bom para 75% de quem entra.

LCP: o maior elemento visível

LCP significa Largest Contentful Paint, ou pintura do maior elemento com conteúdo. O navegador olha para a área visível da tela e pergunta: qual é o maior bloco de conteúdo aqui? Costuma ser a imagem do topo, um vídeo, um bloco grande de texto ou o título principal. O LCP é o momento em que esse elemento termina de aparecer.

Os limiares oficiais:

Na prática, LCP ruim quase sempre tem uma de quatro causas: o servidor demora a responder o primeiro byte, a imagem do topo é gigante e sem otimização, existe CSS ou JavaScript bloqueando a renderização antes do conteúdo, ou a imagem principal só é descoberta depois que o JavaScript roda. A parte de imagem está detalhada em imagens que não derrubam o seu site.

Descobrir qual é o seu elemento de LCP leva trinta segundos. No relatório do PageSpeed Insights existe um item que aponta o elemento exato, e nas ferramentas de desenvolvedor do Chrome, na aba de performance, o marcador de LCP fica visível na linha do tempo. Vale fazer isso antes de otimizar qualquer coisa, porque é comum o time gastar horas comprimindo uma imagem que nem é o elemento medido.

INP: a resposta ao clique, que substituiu o FID em 2024

Em março de 2024, o Google trocou o FID pelo INP como métrica oficial de responsividade. A diferença importa. O FID media só o atraso do primeiro clique da sessão, e por isso quase todo site passava. O INP, Interaction to Next Paint, mede o intervalo entre a interação e o momento em que a tela é efetivamente atualizada, considerando todas as interações da visita e reportando essencialmente a pior delas.

Os limiares:

INP ruim é quase sempre culpa de JavaScript. O navegador tem uma única linha de execução para o seu código. Se um script trava essa linha por 400 milissegundos processando alguma coisa, o clique do usuário fica na fila esperando. Excesso de plugins, banners de terceiros, chats, mapas embutidos e scripts de rastreamento são os suspeitos habituais.

CLS: o layout que pula

CLS é Cumulative Layout Shift, deslocamento cumulativo de layout. É aquela experiência de ir clicar em um botão e, no instante do toque, uma imagem terminar de carregar acima e empurrar tudo para baixo, fazendo você clicar em outra coisa. O CLS mede o quanto de conteúdo se moveu sem que o usuário tenha pedido.

O CLS é o mais barato de corrigir dos três, porque a causa é quase sempre a mesma: algo entrou na página sem ter espaço reservado. Imagem sem atributos de largura e altura. Banner que aparece depois. Fonte personalizada que troca e muda a altura do texto. Aviso de cookies que empurra o cabeçalho.

Um detalhe que confunde: deslocamentos causados por uma ação do usuário não contam, desde que aconteçam logo em seguida. Abrir um menu sanfonado e ver o conteúdo abaixo descer é esperado e não penaliza. O que conta é o movimento que a pessoa não pediu. Para reproduzir o problema, abra a página com o cache desativado e a rede limitada nas ferramentas de desenvolvedor: o que carrega devagar revela exatamente onde falta espaço reservado.

Dados de laboratório vs dados de campo

Essa é a confusão mais comum, e vale entender de uma vez.

Dados de laboratório vêm de uma simulação. O Lighthouse abre a sua página em um ambiente controlado, com uma velocidade de rede e um processador simulados, e mede. É reproduzível, roda em segundos e serve para diagnosticar. Mas é uma simulação, e o INP nem sequer aparece nela de forma real, porque não existe um usuário clicando.

Dados de campo vêm de gente de verdade. O Chrome coleta, de usuários que optaram por compartilhar, as métricas das páginas que eles visitam. Esse conjunto é o CrUX, Chrome User Experience Report, e usa uma janela móvel de 28 dias. É esse dado que aparece no relatório de Core Web Vitals do Search Console e no topo do PageSpeed Insights.

Consequências práticas disso:

• Uma nota 100 no Lighthouse não significa que a sua página está aprovada. Só o dado de campo decide.
• Depois de uma correção, o dado de campo demora semanas para refletir, porque a janela é de 28 dias.
• Site com pouco tráfego pode não ter dado de campo suficiente para uma URL específica. Nesse caso, o Google pode avaliar o conjunto do domínio.

Use o laboratório para consertar e o campo para confirmar. Nunca o contrário.

Vale notar também que o dado de campo mistura todos os aparelhos e conexões de quem entrou. Um site com muitos acessos por celular em rede móvel vai ter números piores que a média do laboratório em um desktop com fibra, e isso não é erro de medição: é a realidade do seu público. Por isso o PageSpeed Insights separa os resultados entre celular e computador, e a coluna de celular é quase sempre a que decide.

As 6 correções que resolvem a maioria dos casos

1. Sirva a imagem do topo no tamanho certo e em formato moderno. Uma foto de 3000 pixels de largura exibida em uma área de 800 pixels é desperdício puro de LCP.
2. Marque a imagem principal como prioritária. Use fetchpriority="high" nela e nunca use loading="lazy" no elemento do topo. Adiar a imagem do hero é atrasar o próprio LCP.
3. Declare largura e altura em toda imagem e vídeo. Isso resolve boa parte do CLS sozinho, porque o navegador reserva o espaço antes de o arquivo chegar.
4. Tire JavaScript de terceiros do caminho crítico. Chats, mapas, pixels e widgets podem carregar depois. Cada script de terceiro no topo do HTML é um risco de INP.
5. Controle as fontes. Use font-display: swap, pré-carregue os arquivos que realmente usa e defina uma fonte de fallback com métricas parecidas para reduzir o salto na troca.
6. Reduza o tempo de resposta do servidor. Cache, hospedagem adequada e HTML pré-renderizado atacam a base do LCP. Se o primeiro byte demora, nada do que vem depois compensa. Vale ler a comparação entre tipos de hospedagem.

Três mitos sobre Core Web Vitals

Mito 1: passar nos Core Web Vitals coloca o site em primeiro lugar. Não coloca. As métricas fazem parte dos sinais de experiência da página, que pesam menos que relevância e qualidade do conteúdo. Elas tendem a funcionar como desempate entre páginas parecidas, não como atalho.

Mito 2: nota 100 no Lighthouse é aprovação. Já vimos por quê. Laboratório não é campo.

Mito 3: é problema do desenvolvedor, não meu. Boa parte dos pontos perdidos vem de decisões de negócio: instalar o quarto script de rastreamento, subir a foto direto da câmera, aceitar um banner de terceiros no topo. Quem decide o que entra na página decide o resultado das métricas.

Se você quer um roteiro mais amplo para colocar a parte técnica em ordem, o checklist de SEO técnico cobre o que vem antes e depois das métricas de performance.

Quer saber por que a sua página está fora dos limiares e o que exatamente precisa mudar? Fale com a ALB Seven e a gente analisa o seu caso com dados reais, não com achismo.