Core Web Vitals: como corrigir LCP, INP e CLS

Quais são os limites "bom" e o que cada métrica mede?

Os Core Web Vitals são três medidas da experiência de quem visita a página. O Google avalia o percentil 75 das visitas, separando celular e computador: para passar, três em cada quatro visitas precisam estar dentro do limite, nas três métricas. Os valores abaixo são os do web.dev:

Para ler o relatório do PageSpeed Insights, veja teste de velocidade do site. Aqui o foco é corrigir. O Google recomenda bons Core Web Vitals para quem quer sucesso na busca, mas avisa que eles não garantem posição e que não há um sinal único: são uma parte da experiência da página.

Dados de campo ou de laboratório: qual usar para decidir?

• Campo: visitas reais, medidas ao longo de semanas. É o que aparece no relatório de Core Web Vitals do Search Console (últimos 28 dias) e no topo do PageSpeed Insights. Mostra qual métrica falha.
• Laboratório: uma simulação feita na hora (Lighthouse, ferramentas do Chrome). Serve para reproduzir o problema e testar a correção. O Lighthouse não mede o INP, porque não há toque de ninguém, e usa outra medida como aproximação.

Use o campo para escolher o alvo e o laboratório para conferir se a correção funcionou. Site novo costuma não ter dado de campo ainda, e aí o laboratório é o guia.

Como corrigir o LCP (o conteúdo principal demora)?

Na maioria das páginas, o LCP é a imagem do topo ou o título grande. Segundo o guia de otimização do LCP, numa página bem ajustada o tempo se divide em cerca de 40% esperando o servidor, 40% baixando a imagem e menos de 10% em cada etapa de espera. Por isso, os ganhos vêm de duas frentes:

1. A imagem do topo leve: em WebP (ou AVIF), comprimida e no tamanho que a tela precisa, sem mandar 3.000 pixels para um celular.
2. A imagem carregada cedo: nunca com carregamento preguiçoso (loading="lazy"), com fetchpriority="high", e presente no HTML em vez de escondida num CSS ou script.
3. Um servidor rápido: cache, poucos redirecionamentos e hospedagem que responda logo. O web.dev considera bom um TTFB (tempo até o primeiro byte) de até 0,8 s. Ele não é um Core Web Vital, mas consome tempo do LCP.
4. Menos bloqueio na tela: scripts com defer ou async e CSS enxuto.

Exemplo de imagem do topo bem montada:

<img src="/img/topo-800.webp"
     srcset="/img/topo-480.webp 480w, /img/topo-800.webp 800w, /img/topo-1200.webp 1200w"
     sizes="100vw"
     width="1200" height="675"
     fetchpriority="high"
     alt="Descrição curta da imagem">

Como corrigir o INP (a página responde devagar)?

O INP piora quando o navegador está ocupado demais para reagir. A causa quase sempre é JavaScript em excesso: plugins, sliders, chat, pixels de anúncio, mapas e gerenciadores de tags. O guia do INP e o de scripts de terceiros apontam o caminho:

• Remova o que não gera resultado. O primeiro conselho do web.dev para um script de terceiros é tirá-lo se ele não agrega valor claro.
• Adie o que fica abaixo da tela: defer, async e carregamento só quando a pessoa rola até lá.
• Quebre tarefas longas em pedaços, para o navegador respirar entre eles (trabalho de desenvolvedor).
• Deixe o DOM pequeno. Páginas com estrutura muito grande demoram mais para atualizar a tela.

Teste de verdade: abra o menu e os botões em um celular simples. Se a resposta demora, o visitante sente.

Como corrigir o CLS (a página pula)?

O CLS é o mais barato de resolver e o mais irritante para o visitante: o botão desce na hora do toque. As causas conhecidas:

• Imagens sem width e height (ou sem aspect-ratio). O navegador não sabe quanto espaço reservar.
• Banners, anúncios, vídeos e mapas que entram sem espaço reservado. Defina uma altura mínima.
• Aviso de cookies ou faixa de promoção empurrando o conteúdo para baixo. Use uma sobreposição ou um espaço fixo.
• Fontes que trocam depois de carregar, mudando o tamanho do texto.

Para as fontes, o que costuma funcionar é servir a fonte do próprio site, em WOFF2, com font-display:

@font-face {
  font-family: "MinhaFonte";
  src: url("/fonts/minhafonte.woff2") format("woff2");
  font-display: swap;
}

swap mostra o texto logo e troca depois. optional evita a troca, ao custo de às vezes usar a fonte reserva. Ajustar o tamanho da fonte reserva (size-adjust) reduz o salto nos dois casos.

Tabela: sintoma, causa provável e correção

Em que ordem atacar?

1. Veja o que falha, nos dados de campo ou, sem eles, no laboratório.
2. LCP primeiro: imagem do topo e servidor. É onde o ganho costuma ser maior.
3. CLS em seguida: dimensões e espaço reservado são correções baratas.
4. INP por último: primeiro remova scripts, só depois otimize os que ficam.
5. Meça de novo e espere. O relatório do Search Console usa os últimos 28 dias, então o efeito aparece em semanas.

No nosso site, o diagnóstico do Lighthouse de 06/10/2026 deu 96 de 100 no geral. Servimos imagens em WebP, fontes locais e o mínimo de JavaScript, e hospedamos em servidor próprio com cache. Ressalva: é nota de laboratório, e não prova o que os visitantes reais sentem. Se quiser uma leitura do seu site, o diagnóstico gratuito mede a velocidade no celular, e o trabalho de SEO e a manutenção do site cuidam de manter isso no verde.