Site lento? O que são Core Web Vitals e como melhorar de verdade

Um site lento não é só um detalhe técnico chato. É venda que não acontece, cliente que desiste no meio do carregamento e posição perdida no Google. E o pior: quase sempre dá pra resolver — depois que você para de adivinhar e passa a medir.

Este guia explica o que são os Core Web Vitals, como o Google mede a velocidade do seu site e o que fazer, na ordem certa, pra deixar as páginas rápidas de verdade.

Por que velocidade virou fator de ranqueamento

Desde 2021 o Google usa a experiência de página (Page Experience) como sinal de ranqueamento, e o coração disso são os Core Web Vitals: três métricas que traduzem, em números, o que o usuário sente ao abrir sua página.

A lógica é simples: o Google quer entregar resultados que as pessoas conseguem usar. Um site que demora 6 segundos pra ficar interativo frustra o visitante — e um visitante frustrado volta pro resultado de busca e clica no concorrente. Esse "voltar e clicar em outro" (o famoso pogo-sticking) é exatamente o que o Google tenta evitar.

Do lado do negócio, os números são conhecidos: a cada segundo a mais de carregamento, a taxa de conversão cai. Em e-commerce, a diferença entre 1s e 3s de LCP costuma valer dois dígitos percentuais de faturamento.

Os três Core Web Vitals, sem jargão

LCP — Largest Contentful Paint

Quanto tempo até o maior elemento visível (geralmente a imagem de destaque ou o bloco de texto principal) aparecer na tela. É a métrica de "quando a página parece pronta".

• Bom: até 2,5s
• Precisa melhorar: 2,5s a 4s
• Ruim: acima de 4s

Culpados comuns: imagem de hero pesada, servidor lento pra responder, CSS ou fontes que bloqueiam a renderização.

INP — Interaction to Next Paint

Substituiu o antigo FID em 2024. Mede a resposta à interação: você clica num botão, e quanto tempo leva até a tela reagir. É a métrica de "o site trava quando eu mexo?".

• Bom: até 200ms
• Precisa melhorar: 200ms a 500ms
• Ruim: acima de 500ms

Culpado número um: JavaScript demais rodando na thread principal — scripts de terceiros, tags de analytics, chat, pixels.

CLS — Cumulative Layout Shift

Mede o quanto o layout pula enquanto carrega. Aquele momento em que você vai clicar num link e um banner empurra tudo pra baixo — isso é CLS alto.

• Bom: até 0,1
• Precisa melhorar: 0,1 a 0,25
• Ruim: acima de 0,25

Culpados: imagens e anúncios sem dimensão reservada, fontes que trocam de tamanho ao carregar, conteúdo injetado por cima.

Lab data vs. field data: a confusão que atrapalha todo mundo

Aqui mora o erro mais comum de quem tenta otimizar sozinho. Existem dois tipos de medição, e eles não concordam:

• Lab data (laboratório): o Lighthouse roda a página num ambiente controlado, sempre igual. Ótimo pra diagnosticar e comparar antes/depois. É o que o PageSpeed Insights mostra na aba de "análise".
• Field data (campo): o CrUX (Chrome User Experience Report) coleta métricas de usuários reais que visitaram seu site nos últimos 28 dias. É isto que o Google usa pra ranqueamento — não o número do laboratório.

Traduzindo: você pode ter 95 no Lighthouse e ainda assim estar reprovado nos Core Web Vitals, porque seus usuários reais (em 4G, celular mais fraco, rede instável) vivem uma realidade diferente da máquina de teste. Otimize olhando os dois.

O passo a passo pra deixar o site rápido

Na ordem de maior impacto pra menor esforço:

1. Meça mobile primeiro. A maioria do tráfego é mobile, e é onde o Google avalia. Um site que voa no desktop e trava no 4G reprova.
2. Ataque o LCP na fonte. Comprima e sirva a imagem de hero em formato moderno (WebP/AVIF), com tamanho certo. Pré-carregue (preload) o recurso do LCP. Reduza o tempo de resposta do servidor (TTFB) — cache e um bom hosting resolvem metade.
3. Enxugue o JavaScript. Cada script de terceiro (chat, pixel, A/B test) come INP. Carregue o que dá de forma assíncrona (defer), remova o que não usa, e questione cada tag nova antes de adicionar.
4. Reserve espaço pra tudo. Defina width e height em imagens e iframes. Use font-display: optional ou swap com fallback de tamanho parecido. CLS zera com disciplina.
5. Meça de novo — e continue medindo. Otimização de performance não é projeto com fim; é manutenção. Um plugin novo, uma tag de marketing, uma imagem sem compressão sobem tudo de novo em silêncio.

Esse último ponto é onde a maioria falha: melhora uma vez, comemora, e três meses depois o site está lento outra vez sem ninguém perceber — até o tráfego orgânico cair.

Onde o Sentinela entra

Medir uma vez qualquer um faz no PageSpeed Insights. O problema é medir sempre e ser avisado quando degradar.

O módulo de Performance do Sentinela roda PageSpeed/Lighthouse nas suas páginas de forma agendada, guarda o histórico (então você vê a evolução, não só um retrato) e mistura lab data com o field data do CrUX — mobile e desktop. Quando uma métrica sai da faixa "boa", você recebe alerta antes do cliente reclamar. E como o Sentinela também cuida de uptime e segurança, é o site inteiro "visto de fora" num painel só.

Se você quer entender o outro lado da conta — o custo de um site que não carrega ou que cai —, vale ler quanto custa uma hora de site fora do ar. Velocidade e disponibilidade são o mesmo problema visto de dois ângulos: o site precisa estar no ar e responder rápido pra converter.

Comece medindo. Veja os planos e coloque suas páginas principais pra rodar — o que não é medido não melhora.