Criação de sites

Core Web Vitals: o que medem e por que pesam em serviço público digital

Entenda LCP, INP e CLS, os limites de cada um e por que o teste de campo, com celular simples e rede instável, é o que vale para o cidadão.

Por Equipe Evo Tech · 27 de outubro de 2026

As três métricas e o que cada uma sente

Core Web Vitals são três métricas do Google que medem o que a pessoa sente ao abrir e usar uma página: o LCP (Largest Contentful Paint) mede o carregamento, o INP (Interaction to Next Paint) mede a resposta ao toque e o CLS (Cumulative Layout Shift) mede a estabilidade visual.

Cada sigla corresponde a uma pergunta que o usuário se faz sem perceber. Este texto mostra os limites de cada uma e explica por que o resultado muda tanto conforme o aparelho e a rede de quem acessa.

Métrica	O que a pessoa sente	Bom	Ruim
LCP	A página apareceu?	até 2,5 s	mais de 4,0 s
INP	Meu toque funcionou?	até 200 ms	mais de 500 ms
CLS	O botão fugiu?	até 0,1	mais de 0,25

Entre o "bom" e o "ruim" existe a faixa "precisa melhorar": de 2,5 a 4,0 s no LCP, de 200 a 500 ms no INP e de 0,1 a 0,25 no CLS. Os limites vêm do web.dev, e a página só passa se atingir "bom" nas três métricas.

LCP: a página apareceu?

O LCP marca o momento em que o maior elemento visível da tela termina de carregar. Costuma ser uma imagem de destaque, um banner ou um bloco de texto grande.

O relógio começa na navegação, não quando o código do site começa a rodar. Entram na conta a resposta do servidor, os redirecionamentos e a conexão. Segundo o web.dev, o valor é considerado bom até 2,5 segundos.

Para quem usa, a leitura é simples: ou o conteúdo principal chegou, ou a pessoa está olhando para uma tela vazia.

INP: meu toque funcionou?

O INP olha para cliques, toques e uso do teclado durante toda a visita, e reporta aproximadamente a pior interação. Ele mede quanto tempo a página leva para mostrar alguma resposta depois do gesto.

Um menu que demora a abrir ou um botão que parece não ter recebido o toque aparecem aqui. O web.dev considera bom até 200 milissegundos. O INP é o sucessor do FID, que olhava só a primeira interação.

CLS: o botão fugiu?

O CLS soma as mudanças inesperadas de posição dos elementos. Mais precisamente, é a maior rajada delas durante a visita, e o valor bom é até 0,1, segundo o web.dev.

Um exemplo comum: o cidadão vai tocar em "Emitir", um banner termina de carregar e empurra o botão para baixo. O toque cai em outro lugar. Ele perde a ação, e muitas vezes não entende o que aconteceu.

Laboratório e campo não medem a mesma coisa

Existem dois jeitos de medir, e eles respondem a perguntas diferentes.

Laboratório é um teste em ambiente controlado: um aparelho e uma rede simulados, o mesmo roteiro a cada rodada. O Lighthouse funciona assim. É ótimo para depurar, porque o resultado se repete e dá para comparar antes e depois de uma mudança.

Campo são os dados de usuários reais, coletados enquanto eles navegam. É a medição que vale para os Core Web Vitals: o web.dev os trata, antes de tudo, como métricas de campo. A avaliação usa o 75º percentil, separado entre celular e desktop. Em outras palavras, três em cada quatro visitas precisam estar dentro do limite.

O que o laboratório não enxerga

O laboratório não mede o INP, porque não há uma pessoa tocando na tela. Para aproximar, usa-se o Total Blocking Time (TBT), que indica quanto tempo a página ficou ocupada demais para responder durante o carregamento. É um indício útil, mas não é a mesma medida.

Por isso, uma nota verde no laboratório não prova que o cidadão está bem atendido. Ela diz que, naquele aparelho simulado e naquela rede simulada, a página se saiu bem.

Isso não torna o laboratório errado. Ele é complementar: o campo mostra se há um problema e para quem, e o laboratório ajuda a descobrir por quê. O Google usa essas métricas como sinal na busca, mas o motivo principal para acompanhá-las é outro: elas descrevem a experiência de quem usa o serviço.

Por que o cidadão com celular simples é o teste real

Aparelho com pouco processamento demora mais para executar o JavaScript da página. Rede instável atrasa o download de tudo o que ela precisa. O primeiro efeito pesa no INP e o segundo no LCP, e os dois se somam quando a pessoa tem as duas limitações ao mesmo tempo.

Uma equipe que testa só no notebook do escritório, com fibra, vê um site que não é o que boa parte do público recebe.

Serviço público não escolhe quem o acessa. A mesma página atende quem tem um aparelho recente e quem usa um modelo de entrada, quem está no Wi-Fi do órgão e quem está com sinal fraco no ônibus. Para o gestor, isso muda a pergunta: em vez de "a nossa nota está boa?", vale perguntar "como está para o pior caso razoável do nosso público?".

Esse raciocínio é parente do que se aplica à acessibilidade. O eMAG parte da mesma ideia: o portal precisa funcionar para todas as pessoas, e não só para o usuário que a equipe tem em mente.

Onde a arquitetura do front-end resolve e onde não resolve

Boa parte dos problemas de LCP, INP e CLS nasce na forma como o front-end foi construído. A arquitetura de front-end resolve bem quando o problema é:

Excesso de JavaScript, que pesa no download e trava a resposta ao toque;
Imagens sem dimensão declarada, que fazem o layout se mexer quando carregam e causam CLS;
Renderização no navegador sem necessidade, quando o servidor poderia entregar a página pronta;
Elemento do LCP carregado tarde, como a imagem principal que só começa a baixar depois de o script rodar.

Ela não resolve, sozinha, o que está fora do front-end:

um servidor lento para responder, que já estoura parte do orçamento do LCP;
consultas pesadas no banco de dados;
limitações de infraestrutura;
scripts de terceiros, como widgets e ferramentas de análise que a equipe não controla.

Onde olhar primeiro

Comece pelos dados de campo, separados entre celular e desktop, e descubra qual das três métricas está fora do limite. Cada uma aponta para um lugar diferente.

Se o problema é o LCP, descubra qual é o elemento e quanto do tempo se perde antes de ele começar a carregar. Se é o INP, procure a interação lenta e o que o JavaScript estava fazendo naquele momento. Se é o CLS, identifique o elemento que se move e por quê: quase sempre falta reservar o espaço dele.

Só depois decida se a correção está no código da página ou em outra camada. Se o gargalo é o servidor, trocar o framework do front-end não vai ajudar.

Quando o site é novo, vale pensar nisso desde o início. Costuma ser mais barato nascer com uma estrutura que respeita essas medidas do que corrigi-la depois, e a criação de sites pode incluir esse cuidado já no projeto.

Fontes

Limites conferidos em 25 de outubro de 2026. O Google pode revisá-los, então confirme nas páginas acima.