Core Web Vitals explicado: LCP, INP e CLS sem complicação

Core Web Vitals são três métricas do Google que medem a experiência real de uma página: LCP (velocidade de carregamento, ideal até 2,5 segundos), INP (resposta aos cliques, ideal até 200 milissegundos) e CLS (estabilidade visual, ideal até 0,1). Elas fazem parte da experiência de página e ajudam no SEO, mas não substituem conteúdo relevante.

Resumo rápido

• LCP mede quando o maior elemento visível da página termina de aparecer. Bom: até 2,5 s. Ruim: acima de 4 s.
• INP mede o tempo entre um clique, toque ou tecla e a resposta visual da página. Bom: até 200 ms. Ruim: acima de 500 ms. Ele substituiu o FID em março de 2024.
• CLS mede o quanto o layout "pula" enquanto carrega. Bom: até 0,1. Ruim: acima de 0,25.
• O alvo é o percentil 75 das visitas reais, separando celular e computador.
• Para medir, use o relatório do Search Console e o PageSpeed Insights. Os dados reais vêm do CrUX, e o teste de laboratório serve para depurar.
• O Google diz que relevância vem primeiro: uma página ótima em velocidade mas fraca em conteúdo não vence.

Como ler: se você cuida de um site mas não programa, leia as definições, a tabela de limites e a lista de passos, que dizem o que pedir ao desenvolvedor. Se você já faz SEO técnico, vá às seções sobre dados de campo versus laboratório, peso no ranking e correções por métrica. Este post complementa o SEO técnico para quem não é programador e usa termos que estão no glossário de SEO, AEO e GEO.

O que são Core Web Vitals?

São três métricas que o Google escolheu para representar a experiência de uso de uma página: carregamento (LCP), interatividade (INP) e estabilidade visual (CLS). A documentação do Google Search recomenda bons valores nelas para o sucesso na busca, e diz que elas se alinham ao que os sistemas centrais de ranqueamento procuram recompensar.

Em linguagem simples: imagine entrar em uma loja física. LCP é quanto tempo leva até o balcão principal aparecer. INP é o tempo que o atendente leva para reagir quando você levanta a mão. CLS é o chão que se mexe: você vai apertar um botão e, de repente, ele sai do lugar e você clica no errado.

Para quem já trabalha com SEO: os Core Web Vitals são o subconjunto de métricas que o Google trata como essenciais e coleta no CrUX. Há outras métricas úteis para diagnóstico (TTFB, FCP, TBT), mas só LCP, INP e CLS entram na avaliação "aprovado ou reprovado" do relatório do Search Console.

Quais são os limites oficiais de LCP, INP e CLS?

Os limites oficiais, segundo a documentação do web.dev, são os da tabela abaixo. Eles são avaliados no percentil 75 das visitas, ou seja, 75% dos acessos precisam estar dentro do limite "bom" para a página ser aprovada, e os dados são segmentados entre celular e computador.

Métrica	O que mede	Bom	Precisa melhorar	Ruim
LCP (Largest Contentful Paint)	Quando o maior elemento visível termina de renderizar	até 2,5 s	de 2,5 s a 4 s	acima de 4 s
INP (Interaction to Next Paint)	Latência das interações até o próximo quadro visual	até 200 ms	de 200 ms a 500 ms	acima de 500 ms
CLS (Cumulative Layout Shift)	Soma da maior sequência de mudanças inesperadas de layout	até 0,1	de 0,1 a 0,25	acima de 0,25

Duas observações evitam confusão. Primeiro, o CLS não tem unidade: é uma pontuação, calculada pelo impacto da mudança na tela multiplicado pela distância percorrida pelos elementos. Segundo, o INP substituiu o FID (First Input Delay) como métrica oficial em 12 de março de 2024, segundo o anúncio do web.dev. Se um relatório antigo ainda cita FID, ele está desatualizado.

O que é LCP e como melhorar?

O LCP registra quando o maior elemento visível (normalmente uma imagem de destaque, um vídeo ou um bloco grande de texto) termina de carregar. A definição do web.dev considera imagens, vídeos, imagens de fundo via CSS e blocos de texto, e o valor final é o último maior elemento registrado antes da primeira interação do usuário.

O guia de otimização do LCP do web.dev divide o tempo em quatro partes: tempo até o primeiro byte (cerca de 40%), atraso para o recurso começar a carregar (menos de 10%), duração do download do recurso (cerca de 40%) e atraso até a renderização (menos de 10%). A ordem de ataque sugerida é eliminar primeiro o atraso de carregamento e o de renderização, depois reduzir o download e, por fim, o tempo de resposta do servidor.

Correções que costumam trazer mais retorno:

• Nunca aplique loading="lazy" na imagem principal acima da dobra. O carregamento preguiçoso é para o que está abaixo.
• Marque a imagem principal com fetchpriority="high" e deixe-a visível no HTML inicial, e não injetada por JavaScript depois.
• Comprima e sirva a imagem no tamanho certo, em formato moderno como WebP ou AVIF, e use CDN.
• Reduza redirecionamentos e acelere o servidor, porque o LCP inclui tempo de conexão e de resposta. Prefira renderizar o conteúdo principal no servidor.

Para quem já trabalha com SEO: olhe a imagem do hero no relatório de laboratório e confira se ela é o elemento de LCP. Um erro frequente é o carrossel ou o slider que carrega o primeiro slide via script. Outro: corrigir o peso da imagem quando o gargalo real é o TTFB, algo que a decomposição em quatro partes mostra de imediato.

O que é INP e como melhorar?

O INP mede a responsividade da página observando a latência de todos os cliques, toques e teclas durante a visita, do momento da ação até o navegador mostrar o próximo quadro com resposta visual. Rolagem, passar o mouse e zoom não entram, de acordo com a explicação do web.dev sobre INP. Diferentemente do antigo FID, que só olhava a primeira interação, o INP cobre a página inteira.

Cada interação tem três fases: atraso de entrada (o navegador ainda está ocupado), tempo de processamento (seu código reage) e atraso de apresentação (o navegador desenha o resultado). O guia de otimização do INP do web.dev recomenda quebrar tarefas longas de JavaScript, fazer o mínimo possível dentro dos manipuladores de evento, adiar trabalho não essencial, reduzir o tamanho do DOM e evitar leituras e escritas de layout alternadas.

Em termos práticos:

• Remova ou adie scripts de terceiros que travam a página: chat, pixels, testes A/B.
• Divida funções pesadas em pedaços menores, devolvendo o controle ao navegador entre eles.
• Mostre algum feedback imediato ao clique (um estado de carregando) antes de processar tudo.

Em linguagem simples: INP é o "toc" do botão. Se você clica em "Adicionar ao carrinho" e nada acontece por meio segundo, o INP está ruim, mesmo que a página tenha carregado rápido.

O que é CLS e como melhorar?

O CLS mede o quanto os elementos visíveis mudam de lugar de forma inesperada enquanto você usa a página. O web.dev agrupa as mudanças em "janelas de sessão" (rajadas com no máximo 1 segundo entre elas e 5 segundos de duração) e reporta a maior janela. Mudanças causadas por um clique do usuário, em até 500 ms, são consideradas esperadas e não entram.

As causas mais comuns e as correções, segundo o guia de otimização do CLS do web.dev:

• Imagens e vídeos sem dimensões: sempre declare width e height, ou use aspect-ratio no CSS.
• Anúncios, embeds e banners que aparecem depois: reserve o espaço com min-height ou aspect-ratio antes do conteúdo chegar.
• Fontes que trocam depois de carregar: use font-display: optional ou fontes reserva parecidas para reduzir o salto de texto.
• Animações: prefira transform a mudar top, left ou tamanhos, porque transform não força o resto da página a se mover.

Como medir Core Web Vitals no seu site?

Meça com três ferramentas: o relatório de Core Web Vitals do Search Console para ver o site inteiro, o PageSpeed Insights para analisar uma URL e o próprio navegador para depurar. A diferença que muda tudo é dados de campo (usuários reais) versus dados de laboratório (um teste simulado).

O relatório do Search Console usa o CrUX, o Relatório de Experiência do Usuário do Chrome, que reúne métricas anônimas de visitas reais. Ele agrupa URLs semelhantes, classifica cada grupo como bom, precisa melhorar ou ruim, e o status do grupo é o da métrica pior. Quando você corrige um problema e clica em validar, o Google acompanha o CrUX por 28 dias para confirmar.

O PageSpeed Insights mostra os dois tipos de dado. Os dados de campo são o histórico dos últimos 28 dias no CrUX. Os dados de laboratório vêm de uma simulação do Lighthouse, em uma só condição de dispositivo e rede. Se o site não tem tráfego suficiente, o PSI não exibe dados de campo da URL e pode cair para o nível da origem, ou não mostrar nada.

Para quem já trabalha com SEO: quando campo e laboratório divergem, confie no campo para decidir se há problema e use o laboratório para achar a causa. Testes de laboratório que só carregam a página não medem INP; reproduza fluxos reais (abrir menu, filtrar, adicionar ao carrinho) no DevTools. Para medir no seu próprio site, a biblioteca JavaScript web-vitals, mantida pelo time do Chrome, coleta as métricas tratando casos que a API crua do navegador deixa passar.

Passo a passo para um diagnóstico em 30 minutos

1. Abra o relatório de Core Web Vitals no Search Console, no celular e no computador, e veja quais grupos de URLs estão "ruins" ou "precisam melhorar".
2. Pegue uma URL representativa de cada grupo (um produto, uma categoria, um artigo) e rode no PageSpeed Insights.
3. Compare os dados de campo com os de laboratório. Anote qual das três métricas reprova.
4. Para LCP, identifique o elemento e as quatro partes do tempo. Para CLS, veja quais elementos se movem. Para INP, teste no DevTools as interações mais usadas.
5. Corrija uma causa por vez, publique, e aguarde cerca de 28 dias de dados de campo antes de concluir. Valide no Search Console.

Core Web Vitals pesam no ranking?

Pesam, mas pouco e sem substituir relevância. A orientação do Google sobre experiência de página diz que a Busca sempre procura mostrar o conteúdo mais relevante, mesmo que a experiência da página não seja boa, e que não há um sinal único: os sistemas olham para vários sinais ligados à experiência geral.

Na prática: não sacrifique conteúdo para ganhar 0,2 segundo, e não ignore uma página que reprova nas três métricas. Uma página lenta e travada perde visitantes antes de qualquer algoritmo, o que é um motivo prático (conversão e retenção) independente de ranking. Sobre prioridade, a ordem sensata é indexação e conteúdo primeiro, Core Web Vitals depois, e performance fina por último. A auditoria de SEO passo a passo mostra onde essa checagem entra, e o checklist de SEO on-page cobre os itens da própria página.

Exemplo hipotético: uma loja tem a página de categoria com LCP de 3,8 s. O elemento de LCP é um banner promocional que carrega por JavaScript depois do restante. A equipe aplica fetchpriority="high" no banner, remove o loading="lazy" e passa a servi-lo no HTML inicial. O LCP do laboratório cai para perto do limite bom. O resultado em dados de campo só aparece após cerca de quatro semanas, e o efeito no ranking, se houver, será discreto. O ganho garantido é a experiência de quem acessa.

Perguntas frequentes

Core Web Vitals são fator de ranqueamento do Google?

Sim, fazem parte dos sinais de experiência de página, mas o Google deixa claro que relevância do conteúdo vem primeiro e que não há um único sinal decisivo. Bons valores ajudam, mas não compensam conteúdo fraco. Trate como parte de uma base saudável, junto com indexação, conteúdo e links.

O que mudou do FID para o INP?

O FID só media o atraso da primeira interação. O INP observa todos os cliques, toques e teclas da visita e inclui o tempo até o navegador mostrar o resultado. Ele passou a ser Core Web Vital estável em 12 de março de 2024, e o FID foi descontinuado. Por isso o INP é mais exigente e revela problemas que o FID escondia.

Por que o PageSpeed Insights mostra notas diferentes do Search Console?

Porque medem coisas distintas. O Search Console usa dados de campo agregados por grupo de URLs, com histórico de 28 dias. O PageSpeed Insights mostra a URL específica, com dados de campo quando existem e um teste de laboratório simulado. Divergências são normais. Use o campo para decidir e o laboratório para depurar.

Meu site tem pouco tráfego e não aparece dados de campo. E agora?

Sem volume suficiente, o CrUX não publica dados da URL, e o PageSpeed Insights usa a origem ou não mostra nada. Nesse caso, use os testes de laboratório como guia, siga as boas práticas de cada métrica e, se quiser dados reais, instale a biblioteca web-vitals no site para coletar as suas próprias medições.

Próximo passo

Se o seu site ainda tem problemas básicos de indexação, resolva-os antes de otimizar milissegundos: revise como o Google rastreia, indexa e ranqueia e configure o Google Search Console para acompanhar os relatórios de experiência. Se você publica artigos no WordPress e quer manter o ritmo de conteúdo, veja como a Contentor gera artigos com IA e revise o resultado com as boas práticas deste guia.

Leia também:

• SEO técnico para quem não é programador: o essencial
• Auditoria de SEO passo a passo: técnico, conteúdo e autoridade
• SEO on-page: checklist completo para cada página