Problema de LCP, INP e CLS no Search Console: o que significa e como corrigir

O que cada métrica mede, sem jargão

As Core Web Vitals são três números que o Google usa pra resumir a experiência de quem abre a página. Cada um responde uma pergunta:

• LCP (Largest Contentful Paint): quanto tempo até o maior bloco visível aparecer na tela. Normalmente é a foto principal, o banner do topo ou o primeiro parágrafo grande. Contam imagens (<img>, <image> dentro de SVG), vídeos, elementos com imagem de fundo via url() e blocos de texto.
• INP (Interaction to Next Paint): quanto tempo a página leva pra mostrar a reação a um clique, toque ou tecla. Rolar a página, passar o mouse e dar zoom não contam. O valor final é a interação mais lenta da visita, descartando a pior a cada 50 interações em páginas com muitas. O INP substituiu o FID, que só media o atraso da primeira interação.
• CLS (Cumulative Layout Shift): quanto o conteúdo se mexe sem a pessoa pedir. Sabe quando você vai tocar num link e um banner empurra tudo pra baixo? É isso. Mudanças que acontecem até 500 ms depois de um clique ou toque não entram na conta, porque são esperadas.

Os limites: Bom, Melhorias necessárias e Ruim

O Search Console classifica cada grupo de URLs em três faixas. Os nomes na tela em português são Bom, Melhorias necessárias e Ruim.

Duas regras mudam a leitura da tabela:

1. Vale o percentil 75. O número do relatório é o valor que 75% das visitas atingiram ou superaram pra melhor. Um LCP de 3,1 s significa que 75% das visitas viram o maior elemento em até 3,1 s, e o resto demorou mais. A média não importa: o que conta é a cauda lenta.
2. Vale a pior métrica. O status do grupo é o mais lento entre as três, por tipo de dispositivo. Se o CLS está Ruim e o LCP está em Melhorias necessárias, o grupo aparece como Ruim no celular.

Celular e computador são avaliados separado, cada um com seu gráfico. É comum o computador estar todo verde e o celular cheio de aviso, porque é no celular que estão os aparelhos mais lentos e as redes piores.

De onde vem o dado do relatório

O relatório não testa o seu site. Ele lê o Chrome User Experience Report (CrUX), que junta as medições de usuários reais do Chrome que abriram suas páginas. Na prática, isso significa:

• Janela de 28 dias. Cada número é um agregado dos últimos 28 dias. Uma correção publicada hoje vai diluindo os dados ruins aos poucos; o gráfico não muda de um dia pro outro.
• Grupos de URLs, não páginas soltas. O Search Console agrupa URLs com experiência parecida (todas as páginas de produto, todos os posts) e mostra uma URL de exemplo de cada grupo. A tabela tem limite de 200 linhas.
• Precisa de volume. Se um grupo não tem dados mínimos de LCP e CLS, ele fica fora do relatório. Se faltam dados num grupo, o Search Console sobe pra um grupo de origem (protocolo, host e porta, ou seja, o site inteiro). Sem dados nem na origem, o relatório mostra "Não há dados disponíveis". Site novo ou com pouco tráfego costuma cair aqui, e não é erro.

Por que o PageSpeed dá nota boa e o Search Console reclama

É a dúvida mais comum. O PageSpeed Insights mostra duas coisas diferentes na mesma tela:

• Em cima, dados de campo: o mesmo CrUX do Search Console, dos 28 dias anteriores, da URL quando ela tem dados suficientes ou da origem inteira quando não tem. É aqui que aparece se a página passa ou não na avaliação das Core Web Vitals.
• Embaixo, dados de laboratório: um teste do Lighthouse feito agora, num aparelho simulado, com uma rede fixa, saindo de um lugar só. É daqui que vem a nota de 0 a 100 (90 ou mais é bom, 50 a 89 precisa de melhoria, abaixo de 50 é ruim).

A nota 95 é do laboratório. O Search Console só olha o campo. Os dois divergem por motivos concretos que o web.dev lista:

• O laboratório testa um aparelho e uma rede; seus visitantes usam celulares baratos em 4G fraco.
• O laboratório carrega sem cache; no campo, parte das visitas já tem arquivos guardados, o que às vezes deixa o campo melhor.
• O laboratório não rola a página nem clica. O CLS de quem rola até o fim e vê um anúncio entrar no meio do texto só aparece no campo.
• Conteúdo personalizado (logado, carrinho, banner de cookies, teste A/B) muda o elemento do LCP de uma pessoa pra outra.
• O teste de carregamento do Lighthouse não mede INP, porque não há interação no teste. O TBT (Total Blocking Time) é uma pista, mas o web.dev avisa que uma página pode ter INP ruim mesmo com TBT ótimo.

Mais dois detalhes do próprio Search Console: o relatório trabalha com grupos, então a URL que você testou pode ser a exceção boa de um grupo ruim. E o PageSpeed ignora os parâmetros da URL, enquanto o relatório leva eles em conta pra separar páginas.

Quanto isso pesa no ranking

O que a documentação do Google diz, sem exagero:

• "As Core Web Vitals são usadas pelos nossos sistemas de classificação", e o Google recomenda alcançar boas Core Web Vitals pra ter bons resultados na Pesquisa.
• Não existe um sinal único de experiência na página: os sistemas olham vários.
• A Pesquisa Google sempre busca mostrar o conteúdo mais relevante, mesmo que a experiência na página seja inferior.
• Ir bem no relatório de Core Web Vitals não garante que suas páginas fiquem no topo dos resultados.

Traduzindo: uma página lenta com o melhor conteúdo ainda pode ganhar de uma rápida e rasa. Corrigir CWV não salva um site com problema de indexação, e não vai mandar ninguém do 30º pro 1º lugar. Ainda assim, entre páginas parecidas, a experiência conta, e quem abandona uma página que não carrega não volta. Se o site também tem páginas fora do índice, comece pela auditoria de SEO técnico: indexação vem antes de velocidade.

Passo a passo: achar o elemento do LCP

Não dá pra corrigir o LCP sem saber qual elemento é. Pegue a URL de exemplo do grupo com aviso e siga:

No PageSpeed Insights

1. No Search Console, abra Core Web Vitals, clique em Abrir relatório ao lado do gráfico do celular e entre no problema. Copie uma URL de exemplo.
2. Cole no PageSpeed Insights e deixe na aba de celular.
3. No bloco de campo, confira se o dado é da URL ou da origem. Se for da origem, o número não é daquela página.
4. No diagnóstico do Lighthouse, procure o item do elemento da Largest Contentful Paint. Ele mostra qual é o elemento (o trecho de HTML) e divide o tempo em partes.

No Chrome DevTools

1. Abra a página no Chrome, aperte F12 e vá na aba Performance.
2. Sem gravar nada, a tela de métricas ao vivo já mostra o LCP e o CLS locais. Passe o mouse no elemento do LCP indicado ali: o Chrome destaca ele na página.
3. Em Field data, use Set up pra puxar os dados do CrUX e comparar com o seu teste. O painel sugere limitação de CPU e Network pra simular o aparelho dos seus visitantes. Use, porque no seu notebook tudo é rápido.
4. Clique em gravar o carregamento (Record load performance) e abra a aba Insights na lateral. Ali aparecem as partes do LCP e os problemas de descoberta da requisição do LCP.

O web.dev divide o LCP em quatro partes. Saber qual delas é grande diz o que corrigir:

Numa página bem otimizada, segundo o web.dev, TTFB e duração do carregamento ficam com uns 40% cada, e os dois atrasos com menos de 10% cada.

Como corrigir o LCP

1. Dê prioridade alta à imagem do topo

Por padrão, o navegador não sabe que aquela imagem é a mais importante. O atributo fetchpriority="high" avisa:

<img src="/img/banner-principal.webp" fetchpriority="high"
     width="1200" height="600" alt="Tênis de corrida azul em promoção">

Use só na imagem que realmente é o LCP. Segundo o web.dev, prioridade alta em mais de uma ou duas imagens deixa de ajudar o LCP.

2. Tire o lazy-load da imagem do topo

O web.dev é direto: nunca use carregamento lento na imagem do LCP, porque isso sempre gera atraso desnecessário. Muito tema de WordPress e componente de imagem aplica loading="lazy" em todas as imagens. Confira no HTML que o servidor entrega:

curl -s https://seusite.com.br/ | grep -o '<img[^>]*>' | head -5

Se a imagem do LCP (a que você achou no passo a passo acima) vier com loading="lazy", remova nela e mantenha nas de baixo. Se quem coloca o atributo é o tema, o plugin de otimização ou o componente de imagem do framework, procure a opção que exclui a primeira imagem do lazy-load.

3. Pré-carregue a imagem quando ela vem do CSS ou do JavaScript

Imagem de fundo definida no CSS, ou carrossel montado por JavaScript, só é descoberta depois que esses arquivos chegam. Um preload no <head> manda o navegador buscar logo:

<link rel="preload" fetchpriority="high" as="image"
      href="/img/banner-principal.webp" type="image/webp">

Se a imagem já está num <img> no HTML, o fetchpriority basta. Melhor ainda é trocar o fundo de CSS por um <img> de verdade.

4. Baixe o TTFB

Um TTFB alto pode tornar difícil, ou até impossível, chegar num LCP de 2,5 s. Meça com curl, repetindo algumas vezes:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s  total: %{time_total}s\n" https://seusite.com.br/

O que costuma derrubar o TTFB: cache de página inteira na CDN (HTML servido da borda, não gerado a cada visita), menos consultas ao banco por página e nenhum redirect antes da página final. Cada salto, como http pra https e depois pra www, soma tempo; o verificador de redirect mostra a corrente inteira. HTML gigante também pesa: o verificador de tamanho do HTML mostra quantos KB o servidor manda.

5. Quando o LCP é texto: cuide da fonte

Se o elemento do LCP é um título ou parágrafo, a fonte personalizada pode segurar a exibição. Coloque a declaração da fonte direto no <head>, use font-display: swap (é o valor que menos atrasa o texto) e, se a fonte vem do Google Fonts, adiante a conexão:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<style>
  @font-face {
    font-family: "Minha Fonte";
    src: url("/fonts/minha-fonte.woff2") format("woff2");
    font-display: swap;
  }
</style>

O swap ajuda o LCP mas pode gerar um pequeno pulo quando a fonte troca. A saída pra isso está na parte de CLS, mais abaixo.

Como corrigir o INP

O INP de uma interação tem três partes: o atraso de entrada (o navegador estava ocupado com outra coisa quando você clicou), o tempo de processamento (o código do clique rodando) e o atraso de apresentação (desenhar a tela nova). Quase sempre o vilão é JavaScript ocupando a thread principal.

1. Quebre tarefas longas

Qualquer tarefa acima de 50 ms é uma tarefa longa, e durante ela a página não responde. A saída é dividir o trabalho e devolver o controle ao navegador entre um pedaço e outro. Esta é a função que o web.dev recomenda, usando scheduler.yield() quando existe e setTimeout como reserva:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

Uso típico num clique que faz várias coisas: primeiro o que a pessoa vê, depois o resto.

botao.addEventListener("click", async () => {
  abrirCarrinho();        // o que a pessoa precisa ver agora
  await yieldToMain();    // deixa o navegador desenhar a tela
  enviarEventoAnalytics();
  await yieldToMain();
  atualizarRecomendacoes();
});

Hoje o scheduler.yield() existe no Chrome e no Edge (129 em diante) e no Firefox (142 em diante), mas não no Safari. Por isso a checagem com setTimeout de reserva: chamar scheduler.yield() direto dá erro no Safari, e com a reserva a página continua cedendo a vez ao navegador.

2. Faça menos dentro do evento

O conselho geral do web.dev é fazer o mínimo possível no callback do evento. Validação pesada, cálculo de recomendações e envio de métricas podem esperar o próximo quadro. E DOM gigante deixa cada redesenho mais caro: em listas longas, a propriedade CSS content-visibility: auto faz o navegador só renderizar o que está perto da tela.

3. Corte e adie JavaScript de terceiros

Chat, pixels de anúncio, mapas de calor e widgets rodam na mesma thread que o seu clique. Se o atraso de entrada é alto, comece por eles:

• Liste o que carrega e pergunte se ainda é usado. Pixel de campanha que acabou é o primeiro a sair.
• Carregue de forma assíncrona tudo que não precisa rodar antes da página aparecer:

<script async src="https://terceiro.exemplo.com/widget.js"></script>
<script defer src="/js/analytics.js"></script>

• Carregue chat e vídeos incorporados só depois do conteúdo principal, ou quando a pessoa clicar.

Pra ver qual interação está lenta, use o painel Performance: ao clicar na página, o INP local aparece nos cartões de métrica, e a aba Interactions lista cada interação capturada. Teste com limitação de CPU, durante o carregamento, que é quando a thread principal está mais ocupada.

Como corrigir o CLS

1. width e height em toda imagem e vídeo

Sem dimensões, o navegador reserva zero de altura e empurra o texto quando a imagem chega. Com elas, ele calcula a proporção antes do download:

<img src="/img/produto.webp" width="640" height="480" alt="Mochila cinza de lado">

img {
  width: 100%;
  height: auto;
}

O CSS deixa a imagem responsiva sem perder a proporção. Quando não dá pra pôr os atributos, use aspect-ratio no CSS.

2. Reserve espaço pra anúncio, embed e banner

Anúncio que carrega depois, vídeo incorporado, avisos de "frete grátis" inseridos no topo: tudo isso empurra o conteúdo. Reserve o espaço antes, e não deixe ele sumir quando o anúncio não vier:

.slot-anuncio {
  min-height: 250px;
}
.video-embed {
  aspect-ratio: 16 / 9;
}

O banner de cookies merece atenção especial: se ele entra no topo e empurra a página, gera CLS em toda primeira visita. Faça ele flutuar sobre o conteúdo (position: fixed no rodapé), fora do fluxo do documento, ou reserve o espaço desde o primeiro desenho.

3. Fonte que troca de tamanho

Quando a fonte personalizada chega e é maior ou menor que a fonte reserva, o texto inteiro reflui. Duas saídas:

• font-display: optional: a fonte só é usada se chegar a tempo do primeiro layout. Sem troca, sem pulo. Bom pra fonte de corpo de texto.
• Ajustar a fonte reserva pra ocupar o mesmo espaço, com size-adjust, ascent-override, descent-override e line-gap-override:

@font-face {
  font-family: "Reserva Ajustada";
  src: local("Arial");
  size-adjust: 105%;
  ascent-override: 92%;
}
body {
  font-family: "Minha Fonte", "Reserva Ajustada", sans-serif;
}

Os percentuais acima são exemplo: os valores certos dependem da sua fonte, teste até o texto parar de mexer na troca.

4. Anime com transform

Animar top, height ou margin recalcula o layout e pode contar como deslocamento. Use transform (mover, escalar, girar), que não mexe no layout dos vizinhos.

Medir no campo sem esperar o CrUX

O Search Console é lento de propósito: 28 dias. Pra saber em dias se a correção funcionou, meça seus próprios usuários com a biblioteca web-vitals, do time do Chrome, que mede do mesmo jeito que as ferramentas do Google:

import { onLCP, onINP, onCLS } from "web-vitals";

function enviar(metrica) {
  const dados = JSON.stringify(metrica);
  if (!(navigator.sendBeacon && navigator.sendBeacon("/analytics", dados))) {
    fetch("/analytics", { body: dados, method: "POST", keepalive: true });
  }
}

onLCP(enviar);
onINP(enviar);
onCLS(enviar);

Com os dados chegando, olhe o percentil 75 por página e por dispositivo, não a média. Se 75% das visitas estão abaixo dos limites, o Search Console vai acompanhar.

Validar correção e os 28 dias

Depois de publicar, volte ao relatório, abra o problema e clique em Validar a correção (na página de detalhes do problema, a ajuda chama o passo de Iniciar rastreamento). O que acontece:

1. O Search Console começa uma sessão de monitoramento de 28 dias nos dados do CrUX.
2. Se o problema não aparecer em nenhuma URL durante o período todo, ele é considerado corrigido. Se aparecer em qualquer URL, a validação falha.
3. Iniciar a validação não faz o Google reindexar nada nem medir de novo. Ele só observa o campo.

Os estados que aparecem são: Não foi iniciado, Iniciado, Tudo certo até agora, Aprovado, N/D e Falha. Cada URL fica como Pendente, Aprovado ou Falha.

Duas dicas práticas. Só clique em validar quando a correção estiver no ar pra todo mundo, senão a contagem roda em cima de dados ruins. E, como o dado é de 28 dias corridos, o gráfico melhora em rampa: é normal ver o grupo em Melhorias necessárias por duas ou três semanas depois de um LCP já resolvido.

Não deixar piorar de novo

O padrão mais comum não é o site nascer lento, é ficar lento: um plugin novo, um pixel de campanha, um banner que entrou no topo, uma imagem de 3 MB no destaque. Como o CrUX demora, você só descobre semanas depois. Teste no PageSpeed a cada mudança grande no topo da página e guarde o resultado. A varredura grátis da Varrida confere o lado técnico que costuma andar junto (redirects, tamanho do HTML, o que o robô recebe), e o plano Pro roda isso todo dia e avisa por e-mail quando algo piora depois de um deploy.