Core Web Vitals reprovados? Como melhorar LCP, INP e CLS

Por SEOgrinder · Publicado em 4 de novembro de 2026 · 10 min de leitura

Resposta curta: uma avaliação reprovada dos Core Web Vitals significa que pelo menos uma de três métricas passa do limite para visitantes reais: o LCP (carregamento) deve ser de 2,5 segundos ou menos, o INP (resposta) de 200 milissegundos ou menos e o CLS (estabilidade visual) de 0,1 ou menos, todos medidos no percentil 75. Encontre a métrica que falha nos dados de campo de visitantes reais, e não na nota de laboratório, e corrija primeiro essa. O Google diz que os seus sistemas de ranking usam os Core Web Vitals, mas bons valores não garantem uma posição de destaque.

O que significa uma avaliação reprovada dos Core Web Vitals?

Os Core Web Vitals são a parte da iniciativa Web Vitals do Google que vale para toda página web. O web.dev cita três métricas, uma para cada aspecto da experiência:

Métrica	O que mede	Valor bom
LCP, Largest Contentful Paint	Carregamento: quando aparece a maior imagem, bloco de texto ou vídeo da área visível	2,5 segundos ou menos
INP, Interaction to Next Paint	Resposta: com que rapidez a página reage de forma visível a um clique, toque ou tecla	200 milissegundos ou menos
CLS, Cumulative Layout Shift	Estabilidade visual: quanto o conteúdo visível se desloca enquanto você usa a página	0,1 ou menos

Os valores são julgados no percentil 75 dos carregamentos de página, separadamente para celular e computador. Em palavras simples: em três de cada quatro visitas o valor precisa ser bom, e celular e computador recebem cada um o seu veredicto. O web.dev diz que as ferramentas devem considerar a página aprovada se ela atinge as metas no percentil 75 nas três métricas. Uma única métrica no vermelho, portanto, basta para reprovar.

Um detalhe no limite: o web.dev diz que INP e CLS devem ser “ou menos”, enquanto a documentação da Pesquisa do Google diz “less than 200 milliseconds” e “less than 0.1”, isto é, menos que. Mire claramente abaixo da linha e a diferença não importa.

Uma mudança que vale conhecer: o INP substituiu o First Input Delay (FID) como Core Web Vital em março de 2024, como diz o anúncio do web.dev. Um guia que ainda lista o FID está desatualizado. Lemos todas as páginas citadas neste artigo em 4 de novembro de 2026; a visão geral do web.dev foi atualizada pela última vez em 31 de outubro de 2024.

Os Core Web Vitals afetam o ranking no Google?

Sim, segundo o Google, mas ele não dá peso nenhum. A página do Google sobre experiência da página diz: “Core Web Vitals are used by our ranking systems.” Ela recomenda bons valores para ter sucesso na Pesquisa e acrescenta que não existe um único sinal de experiência da página.

A mesma página é igualmente clara sobre os limites. Bons resultados no relatório de Core Web Vitals da Search Console ou em ferramentas de terceiros “doesn't guarantee that your pages will rank at the top of Google Search results”. Ela diz também que perseguir uma nota perfeita só por causa do SEO pode não ser o melhor uso do seu tempo. O Google sempre tenta mostrar o conteúdo mais relevante, mesmo quando a experiência da página é ruim.

O que o Google não publica é quanto peso essas métricas têm, e por isso também não citamos número. Leitura nossa, e não um fato do Google: trate os limites como um padrão de qualidade para os seus visitantes, leve as três métricas para “bom” e depois devolva o seu tempo ao conteúdo. Os sistemas de ranking do Google costumam avaliar o conteúdo página por página, então verifique cada tipo de página que importa.

Dados de laboratório ou de campo: qual vale para os Core Web Vitals?

A avaliação se baseia em dados de campo: medições de visitas reais. O Chrome User Experience Report (CrUX) do Google os coleta de usuários reais do Chrome; o PageSpeed Insights e o relatório de Core Web Vitals da Search Console os mostram. Segundo o web.dev, um relatório do CrUX cobre um período de 28 dias.

Os dados de laboratório vêm de carregar a página uma vez em um ambiente controlado: um dispositivo, uma rede, um local. Isso é ideal para encontrar causas e testar uma correção antes de publicar, mas o guia do LCP alerta que “lab tests alone may not be entirely representative”. Quando os dois discordam, o guia do LCP diz para se concentrar primeiro nos dados de usuários reais. Eles diferem por bons motivos:

O elemento do LCP pode ser outro. Uma execução de laboratório sempre acha o mesmo elemento. Visitas reais têm outros tamanhos de tela, conteúdo para quem está logado ou testes A/B.
O INP precisa de gente de verdade. O Lighthouse e outras ferramentas de laboratório carregam a página sem que ninguém clique, então não conseguem medir o INP. O Total Blocking Time (TBT) é o substituto no laboratório; melhorias no TBT podem melhorar o INP.
O CLS continua contando depois do carregamento. As execuções de laboratório veem, na maioria, só o carregamento. No campo, conteúdo que aparece enquanto o visitante rola também pode deslocar o layout.
Caches ajudam visitantes reais. Testes de laboratório costumam começar com cache frio, enquanto visitantes que voltam e o cache de avançar/voltar (bfcache) carregam as páginas mais rápido.

Como ler os seus números em quatro passos:

Rode o seu endereço no PageSpeed Insights. A seção “Discover what your real users are experiencing” traz dados de campo; “Diagnose performance issues” traz a execução de laboratório.
Confira o que você está olhando. Alterne entre celular e computador e entre o URL individual e a origem inteira. Se um URL tem poucos dados, o PageSpeed Insights mostra os dados da origem no lugar.
Ache a métrica acima da linha no percentil 75. Essa é a sua métrica reprovada. Com pouco tráfego não há dados de campo; use os valores de laboratório e meça os seus próprios visitantes com a pequena biblioteca web-vitals do web.dev.
Abra os diagnósticos de laboratório dessa métrica para ver a causa e corrija primeiro essa única coisa.

Como melhorar o LCP: o maior elemento aparece tarde demais

O LCP informa quando a maior imagem, bloco de texto ou vídeo da área visível é desenhado. O guia do LCP do web.dev divide o tempo em quatro partes que somam o LCP: a resposta do servidor (TTFB), o atraso até o navegador começar a carregar o recurso do LCP, o tempo que esse recurso leva para carregar e o atraso até o elemento ser desenhado. Ache a maior parte antes de mudar qualquer coisa: reduzir uma parte pode só passar o tempo para outra. Uma imagem mais comprimida não ajuda se o elemento fica escondido até um script carregar.

A lista das correções mais eficazes da equipe do Chrome inclui estas:

Deixe a imagem do LCP fácil de achar e dê prioridade a ela. Use um <img> normal com src ou srcset, e não um data-src que precisa de JavaScript. Prefira renderizar no servidor a montar a página só no navegador. Adicione fetchpriority="high" e tire loading="lazy" só dessa imagem.
Encurte a resposta do servidor. Sirva e coloque o conteúdo em cache perto dos seus visitantes, em geral com uma CDN.

A mesma tag cuida do LCP e, pelo tamanho, do CLS:

<!-- Imagem principal: no HTML, alta prioridade, sem lazy, com tamanho -->
<img src="/img/hero.webp" width="1200" height="630" alt="Descrição curta" fetchpriority="high">

<!-- Imagens mais abaixo na página: lazy loading é adequado aqui -->
<img src="/img/equipe.webp" width="600" height="400" alt="Descrição curta" loading="lazy">

Como melhorar o INP: a página reage devagar demais

O INP observa cada clique, toque e tecla durante uma visita e informa, aproximadamente, o mais lento (em páginas com muitíssimas interações, os valores atípicos são descartados). Passar o mouse e rolar não contam. Segundo o guia do INP, cada interação tem três partes: o atraso de entrada, o tempo em que os manipuladores de evento rodam e o atraso até o próximo quadro ser exibido. O culpado de sempre é o JavaScript mantendo a thread principal ocupada. As principais correções da equipe do Chrome:

Quebre as tarefas longas. Uma tarefa acima de 50 milissegundos bloqueia a thread principal. Devolva o controle com frequência: scheduler.yield() onde o navegador suporta, setTimeout como alternativa mais antiga.
Envie menos JavaScript. Ache código não usado com a ferramenta de cobertura do Chrome DevTools, divida o código que não é necessário no início e limpe tags antigas no seu gerenciador de tags.
Evite grandes atualizações de renderização. Mantenha o DOM pequeno, evite layout forçado e use CSS containment para conteúdo fora da tela.

Como melhorar o CLS: o layout pula

O CLS não tem unidade. Ele combina quanto conteúdo visível se moveu com a distância que se moveu. No campo, ele conta durante a visita inteira, mas deslocamentos até 500 milissegundos depois de uma interação do usuário ficam de fora. O guia do CLS do web.dev lista as causas comuns: imagens sem dimensões, anúncios, embeds e iframes sem dimensões, conteúdo injetado dinamicamente e web fonts. O que ajuda:

Reserve espaço. Dê width e height a imagens e vídeos, ou use a propriedade CSS aspect-ratio. Para conteúdo de tamanho desconhecido, um min-height sensato é melhor que o padrão zero.
Anime com transform. Animar top, left ou margin desloca o layout. Banners de cookies que deslizam para dentro são um caso típico.
Deixe o cache de avançar/voltar trabalhar. Ele restaura páginas já totalmente desenhadas. Bloqueadores comuns são as diretivas de cache no-store e os ouvintes do evento unload.
Cuide das web fonts. font-display: optional, fontes de reserva compatíveis com size-adjust e o pré-carregamento das fontes críticas reduzem os deslocamentos causados por fontes.

Como o SEOgrinder verifica os Core Web Vitals

O SEOgrinder é a nossa ferramenta; nós a construímos. Digite um endereço público no SEOgrinder e os números de velocidade vêm do Google PageSpeed Insights, para celular e para computador. O cartão “Core Web Vitals” mostra LCP e CLS da execução de laboratório do Lighthouse e o INP de visitantes reais, e uma caixa separada mostra dados de usuários reais dos últimos 28 dias. Se o Google tem poucos dados da página, o relatório diz isso em vez de chutar. Tarefas como “Os visitantes reais no telemóvel esperam … pelo conteúdo” citam a métrica, o valor e a correção. Uma resposta lenta do servidor, que entra no LCP, ganha uma tarefa própria.

Limites: o SEOgrinder lê os números do Google e não substitui o seu próprio monitoramento de usuários reais. Ele não mede rankings. Se a cota diária do Google para a medição de velocidade acabou, o relatório sai sem ela.

Erros comuns

Confiar só na nota de laboratório. Ela não mede o INP e pode ser diferente do que os visitantes vivem. Comece pelos valores de visitantes reais.
Verificar só um dispositivo. Celular e computador são julgados separadamente.
Carregar a imagem principal com lazy loading. loading="lazy" na imagem do LCP acrescenta atraso.
Deixar de fora o tamanho das imagens. Sem width e height, o navegador não consegue reservar espaço.
Corrigir a parte errada do LCP. Comprima imagens só depois que a divisão mostrar que o tempo de carregamento é o problema.
Esperar um resultado instantâneo. Os dados de campo cobrem 28 dias, então mudam aos poucos. Confira a execução de laboratório logo depois da correção e os números de visitantes reais nas semanas seguintes.

Perguntas frequentes

O que é uma boa nota nos Core Web Vitals?

Não existe uma nota única. Uma página passa quando o LCP é de 2,5 segundos ou menos, o INP de 200 milissegundos ou menos e o CLS de 0,1 ou menos no percentil 75. O número de 0 a 100 que você talvez conheça do Lighthouse é um valor de laboratório e outra coisa.

Por que o PageSpeed Insights não mostra dados de usuários reais do meu site?

Em geral, há poucas visitas para o CrUX informar algo. O web.dev sugere, nesse caso, acrescentar a sua própria medição de visitantes reais. Até lá, trabalhe a partir dos valores de laboratório.

Preciso de uma nota perfeita?

Não. O objetivo é passar. O próprio Google diz que perseguir uma nota perfeita só por motivos de SEO pode não ser o melhor uso do seu tempo.

Seu próximo passo

Analise a sua página mais importante com o SEOgrinder, abra o cartão “Core Web Vitals” e olhe primeiro os valores de visitantes reais. Corrija a única métrica que reprova, clique em Verificar de novo e leia os valores de laboratório. O quadro geral está na nossa checklist de auditoria SEO.