Core Web Vitals: o que são LCP, INP e CLS — e quanto isso pesa
As três métricas, os limites atuais e a diferença entre o número do laboratório e o número que o Google usa de verdade.
Core Web Vitals são três medidas que o Google usa para descrever a experiência de carregamento de uma página. Elas mudaram em 2024 — a métrica de resposta a interação foi trocada —, e a maior parte do material em português ainda descreve a versão antiga.
As três métricas e os limites
| Métrica | O que mede | Bom | Ruim acima de |
|---|---|---|---|
| LCP Largest Contentful Paint | Quando o maior elemento visível termina de aparecer | ≤ 2,5 s | 4 s |
| INP Interaction to Next Paint | Quanto a página demora a responder a um toque ou clique | ≤ 200 ms | 500 ms |
| CLS Cumulative Layout Shift | Quanto o conteúdo se mexe sozinho durante o carregamento | ≤ 0,1 | 0,25 |
INP substituiu o FID em março de 2024. A diferença importa: o FID media só o atraso da primeira interação; o INP olha as interações ao longo de toda a visita e reporta praticamente a pior delas. É bem mais difícil de passar — e bem mais parecido com a experiência real.
O detalhe que muda tudo: campo, não laboratório
A avaliação não usa a nota do PageSpeed. Ela usa dados de visitas reais, e o critério é o percentil 75: pelo menos 75% das visitas precisam ficar na faixa boa. Não é a média — é quase o pior quarto dos seus visitantes.
Isso explica a frustração mais comum do assunto: nota 98 no teste e reprovação na avaliação real. O teste roda numa máquina rápida, num ponto de rede específico, uma vez. O dado real inclui o celular de sete anos numa conexão ruim. Se boa parte do seu público está nessa situação, o número que conta é o dele.
Há uma consequência prática desagradável: site com pouco tráfego pode não ter dado de campo nenhum. Sem volume suficiente, o Google não tem amostra para a sua URL e trabalha com o agregado do domínio, ou com nada. Nesse caso, otimizar o número do laboratório é o que sobra — mas sabendo que ele é um substituto, não a medida.
O que realmente move cada uma
- LCP — quase sempre é uma imagem. Reduzir o arquivo, não adiar o carregamento do elemento de abertura, e não deixar o CSS bloquear a pintura. Um erro que vimos no nosso próprio site: a imagem de abertura marcada para carregamento adiado, o que atrasa exatamente o que precisava vir primeiro.
- INP — é JavaScript ocupando a linha principal. Script de terceiro, chat e rastreamento são os suspeitos habituais. Adiar o carregamento deles costuma render mais do que otimizar o próprio código.
- CLS — imagem sem
widtheheight, anúncio que entra empurrando o texto, fonte que troca e muda a altura da linha.
Uma nuance honesta sobre o CLS
Quando auditamos este site, nenhuma das 25 imagens tinha dimensão declarada — o clássico causador de CLS. Medimos esperando um número ruim e o CLS deu zero. O motivo: as imagens ficavam em contêineres de altura fixa e carregavam adiadas, então o pulo não chegava a acontecer.
Corrigimos assim mesmo, porque era risco latente: bastaria alguém mexer no CSS do cartão para o problema aparecer. Mas vale o registro contra o alarmismo — a falta de width e height é um risco, não um dano automático. Medir antes de consertar evita gastar o dia no lugar errado.
Quanto isso pesa no rankeamento
Menos do que se vende e mais do que os céticos dizem. É um sinal entre muitos, e serve principalmente como desempate: entre duas páginas igualmente boas para a mesma busca, a experiência conta. Não é o que faz uma página ruim superar uma boa.
O efeito maior é comercial, não de posição: página lenta perde gente antes de ser lida. Essa perda não aparece em relatório nenhum, porque quem desistiu nunca virou uma visita.
Veja também: a auditoria de velocidade do nosso site e os demais artigos.