Neste artigo
Existe uma diferença grande entre um site com boa nota e um site que parece rápido. As Core Web Vitals foram criadas justamente para medir a segunda coisa.
São três métricas, e cada uma responde a uma pergunta diferente do visitante.
LCP — "já dá para ler alguma coisa?"
O Largest Contentful Paint mede quanto tempo leva até o maior elemento visível aparecer. Normalmente é a imagem do topo ou o título principal.
O que costuma estragar o LCP:
- Imagem de topo pesada ou sem dimensões declaradas
- Fonte que bloqueia a renderização — o texto existe, mas fica invisível esperando o arquivo da fonte
- Servidor lento para responder o primeiro byte, o que empurra tudo para frente
O que resolve, em ordem de impacto: servir a imagem no formato e no tamanho certos, pré-carregar o que aparece acima da dobra, e usar font-display: swap para o texto aparecer com a fonte do sistema enquanto a definitiva carrega.
INP — "a página responde quando eu toco?"
O Interaction to Next Paint substituiu o antigo FID e é a métrica mais honesta das três: mede o atraso entre a pessoa interagir e a tela reagir.
O vilão quase sempre é o mesmo: JavaScript demais. Cada script de terceiro — chat, pixel, mapa de calor, teste A/B — ocupa a thread principal. Enquanto ela está ocupada, o clique não vira nada.
Aqui a melhoria costuma ser menos técnica do que política: decidir quais scripts realmente precisam existir. Um site com quatro ferramentas de rastreamento tem um problema de gestão, não de código.
CLS — "por que o botão fugiu?"
O Cumulative Layout Shift mede o quanto o conteúdo pula durante o carregamento. É a métrica que mais irrita e a mais barata de corrigir.
As causas são quase sempre três: imagens sem width e height, anúncios ou banners inseridos depois, e fontes que trocam de tamanho ao carregar. Declarar as dimensões e reservar o espaço resolve a maior parte.
Por que a nota do PageSpeed engana
O PageSpeed Insights mostra dois blocos, e a maioria das pessoas olha só o primeiro.
- Dados de laboratório: uma simulação, em condições fixas. É o número grande e colorido.
- Dados de campo: o que aconteceu com visitantes reais nos últimos 28 dias. É o que o Google usa.
Um site pode ter 98 em laboratório e reprovar em campo — basta o público real acessar por 4G num aparelho modesto. Olhe sempre o bloco de campo primeiro. Se ele não aparece, é porque o site ainda não tem tráfego suficiente para o relatório.
Onde performance vira arquitetura
Muita coisa não se resolve com plugin. Um site montado com dezenas de componentes carregando bibliotecas próprias vai ser lento por construção, e nenhuma otimização posterior conserta isso de verdade.
Por isso performance é decisão de projeto, não ajuste final. As escolhas que mais pesam — quanto JavaScript existe, como as imagens são servidas, o que carrega antes — são feitas na primeira semana, não na última.