O que mais atrapalha os Core Web Vitals de um site?
Na maioria dos sites: imagens sem dimensão declarada (que geram CLS), JavaScript de terceiros bloqueando a thread principal (que gera INP e TBT altos) e recursos em cadeia no caminho crítico (que atrasam o LCP). Medir antes de otimizar é o que evita gastar esforço no lugar errado.
Medir antes de otimizar
A regra que economiza mais tempo é também a mais ignorada: descobrir onde está o custo antes de mexer. Neste próprio site, duas tentativas de otimizar o motor 3D do topo não moveram nada — o gargalo era o navegador calculando layout da página inteira para pintar só a primeira dobra.
Os três que importam
- LCP — quando o maior elemento aparece. Costuma ser a headline ou a imagem do topo. Ataque a cadeia de requests até ele.
- CLS — quanto a página "pula". Quase sempre imagem sem dimensão ou decisão de layout tomada tarde demais por JavaScript.
- INP — quanto tempo até a página responder ao toque. Depende de quão ocupada está a thread principal.
Decisões que mudam layout têm que vir antes do primeiro paint
Se o JavaScript no rodapé decide se um bloco aparece de um jeito ou de outro, o navegador já pintou uma vez e vai pintar de novo — isso é CLS na certa. Um script mínimo no <head> que marca a decisão numa classe do <html> resolve, e ainda evita downloads que aquele modo nem usa.
Nem toda economia é ganho
Existe otimização que piora. Neste site, recortar a região de uma imagem para desenhar menos pixels no canvas ficou mais lento que desenhar a imagem inteira — a sub-região tira a cópia do caminho rápido do navegador. Sem medir, teria ficado no código como "melhoria".
Próximo passo
Quer isso rodando no seu negócio?
Diagnóstico gratuito: você recebe um mapa do que faríamos e uma faixa honesta de investimento.