Core Web Vitals: deixar um site rápido de verdade

A armadilha clássica: o desenvolvedor testa em fibra, um MacBook recente, com o cache quente. O usuário real, por sua vez, chega de um celular intermediário, num 4G instável, com o cache vazio. Entre os dois, a experiência não tem nada a ver.

Os Core Web Vitals existem para medir o que o usuário realmente vive. O Google os transformou num fator de posicionamento — e, sobretudo, eles preveem a conversão: cada segundo de carregamento a mais afugenta visitantes.

• LCP (Largest Contentful Paint) — o tempo até que o elemento principal (muitas vezes a imagem ou o título do hero) apareça. Meta: abaixo de 2,5 s.
• INP (Interaction to Next Paint) — a responsividade: o atraso entre um clique e a resposta visível. Meta: abaixo de 200 ms. É o nervo da guerra em sites carregados de JavaScript.
• CLS (Cumulative Layout Shift) — a estabilidade: aqueles saltos de layout que fazem clicar no lugar errado quando uma imagem ou anúncio carrega. Meta: abaixo de 0,1.

Um site bonito e lento é um site fracassado. O desempenho não é inimigo do design — é uma restrição que força escolhas nítidas.

Deixar um site rápido não tem nada de mágico, é uma soma de decisões:

• Imagens — formato moderno (AVIF/WebP), dimensões corretas, lazy loading abaixo da dobra e uma reserva de espaço para evitar saltos (CLS).
• Fontes — font-display: swap, pré-carregamento dos pesos realmente usados e, sobretudo: carregar só esses.
• JavaScript — enviar o mínimo possível. O código mais rápido é o que não se envia ao navegador. Componentes de servidor, carregamento diferido do não crítico.
• Renderização — privilegiar o estático (pré-gerado no build) quando o conteúdo permite: nada supera um arquivo já pronto.
• Medição contínua — um orçamento de desempenho e um monitoramento (Lighthouse, Speed Insights) para que uma regressão apareça antes da produção, não depois.

Há duas formas de medir: os dados de laboratório (Lighthouse, ambiente controlado) e os dados de campo (os usuários reais, via Chrome UX Report). Ambos são úteis, mas só o segundo reflete a realidade. Um site pode marcar 100 em laboratório e decepcionar em campo por causa de uma conexão lenta ou de um aparelho modesto.

Minha disciplina: otimizar em laboratório para ir rápido, mas validar em campo antes de cantar vitória.

Um site rápido não é só um capricho técnico. É mais visitantes que ficam, melhor posicionamento no Google e mais conversões. A velocidade é uma das raras melhorias que serve ao mesmo tempo ao usuário, ao posicionamento e ao faturamento. É por isso que a trato como uma exigência, não como um bônus.