Core Web Vitals: o que são LCP, INP e CLS e como melhorar

Core Web Vitals são três métricas do Google que medem, com dados de usuários reais, a experiência de uma página: o LCP (Largest Contentful Paint) mede o carregamento, o INP (Interaction to Next Paint) mede a resposta às interações e o CLS (Cumulative Layout Shift) mede a estabilidade visual. Uma página é considerada boa quando, no percentil 75 das visitas, o LCP fica em até 2,5 segundos, o INP em até 200 milissegundos e o CLS em até 0,1, com celular e desktop avaliados em separado (web.dev). Os sistemas de ranking do Google usam essas métricas, mas um resultado bom não garante posição e não passa na frente da relevância do conteúdo (Google Search Central).

Este guia vale para as definições em vigor em outubro de 2026. Ele explica cada métrica, como a avaliação é feita, o que o Google diz sobre ranking, onde ver os números e por onde começar a melhorar cada um.

As três métricas e os limites de cada uma

Cada métrica tem três faixas: bom, precisa melhorar e ruim. Os limites abaixo são os mesmos no PageSpeed Insights e no relatório do Search Console (documentação do PageSpeed Insights, ajuda do Search Console).

LCP: quando o conteúdo principal aparece

O LCP marca o momento em que o maior elemento visível na área inicial da tela é renderizado, contado a partir do início da navegação. Contam como candidatos imagens (<img> e <image> dentro de um SVG), vídeos (vale o pôster ou o primeiro quadro, o que vier antes), elementos com imagem de fundo carregada por url() no CSS (gradientes não contam) e blocos de texto (web.dev, LCP). O elemento escolhido pode mudar conforme o tamanho da tela, porque cada aparelho mostra uma parte diferente da página (web.dev, diferenças entre laboratório e campo).

INP: quanto a página demora para responder

O INP observa os cliques, toques e teclas pressionadas durante toda a visita e mede quanto tempo cada interação leva até a tela mostrar a resposta. Rolagem, hover e zoom não entram. O valor da visita é a interação mais lenta; em páginas com muitas interações, a mais lenta de cada grupo de 50 é descartada, para que um caso isolado não defina o resultado (web.dev, INP).

O INP substituiu o FID (First Input Delay) como Core Web Vital em 12 de março de 2024. O FID media só o atraso até o navegador começar a tratar a primeira interação; o INP considera todas as interações e vai até a tela ser atualizada. O Chrome deu prazo até 9 de setembro de 2024 para quem consumia FID nas APIs do CrUX e do PageSpeed Insights migrar para o INP (web.dev, anúncio do INP). Material que ainda fala em FID como Core Web Vital está desatualizado.

CLS: quanto a página pula

O CLS mede os deslocamentos de layout inesperados, como um botão que desce porque um banner carregou acima dele. Os deslocamentos são agrupados em janelas: entram na mesma janela os que acontecem com menos de 1 segundo entre si, e cada janela dura no máximo 5 segundos. O CLS da página é a janela com a maior soma, observada durante toda a vida da página, inclusive depois da rolagem. Deslocamentos que acontecem até 500 ms depois de um clique, toque ou tecla são tratados como esperados e ficam de fora (web.dev, CLS).

Como a avaliação funciona: percentil 75, celular e desktop

O Google não avalia uma visita isolada. A medida recomendada é o percentil 75 (p75) das visitas, separado entre celular e desktop (web.dev). Percentil 75 significa que três de cada quatro visitas tiveram aquele valor ou melhor. A web.dev explica que esse corte garante que a maioria das visitas atingiu a meta sem deixar que casos extremos distorçam o número (web.dev, definição dos limites).

Uma página ou origem passa na avaliação quando o p75 das três métricas está na faixa boa. No PageSpeed Insights, quando não há dados suficientes de INP, a avaliação considera só LCP e CLS (PageSpeed Insights).

Os limites são os mesmos para celular e desktop, porque a expectativa do usuário não muda com o aparelho. Como o celular tem hardware e rede mais limitados, a maior parte dos limites foi definida pensando nele (web.dev). Os resultados, porém, saem separados: no Search Console, cada grupo de páginas recebe um status para celular e outro para desktop, e o status do grupo é o da pior métrica (ajuda do Search Console). Um resultado bom no desktop não diz nada sobre o celular.

O que o Google diz sobre Core Web Vitals no ranking

A documentação de experiência na página do Google Search Central, atualizada em setembro de 2026, afirma o seguinte (Google Search Central, experiência na página):

• As Core Web Vitals são usadas pelos sistemas de ranking, e o Google recomenda ter bons resultados nelas para o sucesso na busca e para a experiência do usuário em geral.

• Bons resultados no relatório do Search Console ou em ferramentas de terceiros não garantem que as páginas fiquem no topo dos resultados.

• Buscar uma pontuação perfeita só por motivo de SEO pode não ser o melhor uso do seu tempo.

• A busca sempre tenta mostrar o conteúdo mais relevante, mesmo quando a experiência na página é ruim. Quando há muito conteúdo útil disponível para uma consulta, uma boa experiência na página pode contribuir para o resultado.

• Não existe um sinal único de experiência na página; os sistemas olham vários sinais.

• Fora as Core Web Vitals, os outros aspectos de experiência na página não ajudam diretamente no ranking, embora deixem o site mais agradável de usar.

• A avaliação é feita em geral por página, com algumas avaliações do site inteiro.

O Google não publica o peso das Core Web Vitals no ranking. A leitura prudente dessa documentação é tratar as métricas como um fator entre muitos: vale corrigir o que está na faixa ruim, sobretudo em páginas que disputam consultas com muito conteúdo útil concorrente, mas não faz sentido esperar que sair de "precisa melhorar" para "bom" mude posições sozinho. O motivo mais sólido para melhorar continua sendo o visitante, que espera menos e não clica no lugar errado.

Onde ver os números do seu site

Existem dois tipos de dado. Dado de campo vem de visitas reais, com os aparelhos e as redes que os visitantes usam de fato. Dado de laboratório vem de um carregamento simulado, com aparelho e rede fixos. A recomendação da web.dev é começar pelo campo para saber se existe problema e usar o laboratório para descobrir a causa (web.dev, ferramentas). A diferença entre as fontes está detalhada em Lighthouse, CrUX e RUM: qual dado de Core Web Vitals usar.

As fontes da tabela estão na documentação do PageSpeed Insights, na ajuda do Search Console, na metodologia do CrUX, na página de Web Vitals e no repositório da biblioteca web-vitals.

O CrUX (Chrome User Experience Report) é a base pública de dados de campo do Google. Ele reúne visitas de usuários do Chrome no desktop e no Android que ativaram o envio de estatísticas de uso e a sincronização do histórico. Só entram páginas e origens que podem ser descobertas publicamente e que têm visitas suficientes; o Google não divulga o mínimo (metodologia do CrUX). A CrUX API é gratuita, atualiza os dados diariamente e devolve a média móvel dos últimos 28 dias, com recorte por celular, desktop e tablet.

RUM (real user monitoring, ou monitoramento de usuários reais) é a coleta feita pelo próprio site. A biblioteca web-vitals, mantida pelo time do Chrome, mede as métricas do mesmo jeito que o Chrome mede para as ferramentas do Google (web-vitals). Isso permite ver dados por página, por tipo de página e com o elemento responsável, coisa que o CrUX não mostra.

FCP, TTFB e TBT: métricas de apoio, não Core Web Vitals

Algumas ferramentas mostram outras métricas ao lado das Core Web Vitals. Elas ajudam a achar a causa de um problema, mas não entram na avaliação (web.dev).

A própria web.dev diz que um TTFB acima de 0,8 s não é um problema em si quando não atrapalha as métricas que importam (web.dev, TTFB). O mesmo raciocínio vale para FCP e TBT: use-os para explicar um LCP ou INP ruim, não como meta isolada.

Como melhorar cada métrica

As recomendações abaixo resumem as que a web.dev considera mais eficazes (web.dev, as formas mais eficazes de melhorar as Core Web Vitals). Cada métrica tem um guia próprio neste blog.

LCP

O ponto de partida é fazer o recurso do LCP (em geral uma imagem) aparecer já no HTML inicial, sem carregamento adiado (lazy loading) e com prioridade alta. Depois vem o tempo de resposta do servidor, que pode cair com cache do HTML em uma CDN perto do usuário. Navegações instantâneas, com back/forward cache e pré-renderização, também reduzem o LCP. O passo a passo, dividido nas quatro partes do tempo do LCP, está em Como melhorar o LCP.

INP

O INP piora quando a thread principal do navegador está ocupada com JavaScript na hora do clique. As frentes principais são quebrar tarefas longas para devolver o controle ao navegador com frequência, enviar menos JavaScript (inclusive tags antigas de terceiros) e evitar atualizações grandes de renderização, com um DOM menor. Detalhes em Como melhorar o INP.

CLS

A maior parte do CLS some quando todo conteúdo carregado depois (imagens, anúncios, embeds) tem espaço reservado, com width e height, aspect-ratio ou uma altura mínima. Também ajuda deixar a página apta ao back/forward cache e animar com transform em vez de propriedades que mexem no layout, como top ou margin. Veja Como corrigir o CLS.

Depois de corrigir, os dados de campo do CrUX levam até 28 dias para refletir a mudança por inteiro, porque são uma média móvel. Para quem cuida de muitos sites e precisa pegar regressões logo depois de um deploy, o processo está em Como monitorar a performance de vários sites.

Como verificar o seu site

O teste de Core Web Vitals do WebVyze mostra os dados do CrUX dos últimos 28 dias, para celular e desktop, de até 10 URLs. Quando uma métrica está ruim, os diagnósticos de LCP, INP e CLS usam o Google PageSpeed para apontar a causa. Para acompanhar ao longo do tempo, os planos pagos incluem auditorias agendadas, alertas e um script de visitantes reais (cerca de 10 KB, baseado na biblioteca web-vitals) que registra LCP, INP e CLS de cada visita com a causa. O WebVyze só lê páginas públicas e não altera o site.