Core Web Vitals resumem experiência real de página em três números: carregamento, resposta à interação e estabilidade visual. Desde 2024 o conjunto oficial é LCP, INP e CLS. O FID saiu; não use FID como referência atual.
Elas importam para SEO como um sinal entre muitos, e importam ainda mais para conversão: quem veio de anúncio ou busca abandona se a página demora, trava no clique ou pula o botão. Conteúdo e oferta continuam pesando. CWV bom não salva proposta fraca; CWV ruim estraga proposta boa.
1. As três métricas, na prática
LCP (Largest Contentful Paint)
Marca quando o maior conteúdo da tela inicial aparece. Em landing, costuma ser o hero, a foto principal ou o bloco de título. Se o LCP atrasa, a pessoa ainda não “entrou” na página: só viu fundo e spinner.
O que mais atrasa LCP: imagem hero sem compressão, CSS gigante no caminho crítico, fonte display bloqueando texto, carrossel pesado acima da dobra.
INP (Interaction to Next Paint)
Mede quanto a página demora para responder a cliques, toques e teclas ao longo da visita. Substituiu o FID. Formulário pesado, menu com muito JavaScript ou script de terceiros competindo na thread principal aparecem aqui.
CLS (Cumulative Layout Shift)
Soma deslocamentos inesperados. Botão que desce quando a fonte carrega, banner que empurra o CTA, embed sem altura reservada: o dedo erra o alvo e a confiança cai.
Velocidade sem estabilidade ainda frustra. As três métricas precisam caminhar juntas.
2. Limites que o Google considera bons
Os limiares “bons” publicados para experiência de página são:
- LCP: até 2,5 segundos
- INP: até 200 milissegundos
- CLS: até 0,1
Passar desses valores não “remove” o site do Google. Piora o sinal de experiência e, na prática, piora a taxa de quem completa a ação. Em campanha paga isso aparece como clique estável e conversão caindo.
Evite: tratar a nota 100 do Lighthouse como meta de negócio. O que importa é o visitante real no celular completar o CTA.
3. Laboratório versus campo
O PageSpeed Insights mostra laboratório (simulação na hora) e, quando há volume, campo (CrUX: usuários reais nos últimos períodos). O Search Console também reporta CWV de campo.
- Use o campo para saber se o problema é real em produção.
- Use o laboratório para reproduzir, isolar o recurso culpado e validar o conserto.
- Olhe o relatório mobile primeiro. Desktop bom e mobile ruim ainda é falha.
Se o campo ainda não tem dados (site novo ou pouco tráfego), o laboratório orienta, mas confirme de novo depois de algumas semanas com usuários reais.
4. Ordem de correção (faça nesta sequência)
Primeiro: LCP
- Comprima e redimensione o hero (WebP, largura próxima do uso real).
- Defina width e height (ou aspect-ratio) para reservar espaço.
- Preload só da imagem crítica do hero, sem competir com meia dúzia de preloads.
- Corte CSS e fontes que atrasam a primeira pintura do título.
Depois: INP
- Adie scripts que não são da primeira interação (chat, animações decorativas).
- Mantenha o listener do CTA e do formulário leves.
- Evite trabalho pesado em todo scroll; use requestAnimationFrame e pause quando idle.
Em seguida: CLS
- Reserve espaço para imagens, iframes e banners.
- Evite injetar blocos acima do CTA depois do load.
- Teste troca de fonte: se o layout pula, ajuste fallback ou display.
Se a lentidão é óbvia mesmo sem métrica, comece pelo diagnóstico prático em por que site lento mata conversão e use LCP, INP e CLS para provar que o conserto pegou.
5. Como validar antes de declarar “resolvido”
- Rode de novo o PageSpeed na URL exata da landing (não só na home).
- Teste o CTA no celular real: toque, teclado, WhatsApp ou envio do form.
- Compare campo no Search Console após janela com tráfego suficiente.
- Confirme que tracking e pixels não reintroduziram bloqueio na thread principal.
Pronto quando: mobile no laboratório está na faixa boa nas três métricas e, com tráfego real, o campo não fica vermelho de forma consistente. Aí a performance deixa de ser desculpa e a conversão volta a depender de oferta e mensagem.