Core Web Vitals: deixar um site rápido de verdade
A velocidade não é um luxo: é um fator de posicionamento no Google e de conversão. Análise dos Core Web Vitals — LCP, INP, CLS — e das alavancas concretas que uso para mantê-los no verde.
«Aqui funciona bem» não basta
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.
As três métricas que contam
- 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.
As alavancas que uso
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 loadingabaixo 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.
Medir em campo, não em laboratório
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.
Por que isso importa para um cliente
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.