Core Web Vitals em 2026: o que medir e como corrigir
LCP, INP e CLS — os três números que o Google mede e que decidem se sua página é rápida de verdade. Os limites atuais e o que fazer quando você não passa.
"O site está lento" é uma reclamação sem alça para segurar. Core Web Vitals transformam essa sensação em três números medidos no navegador de gente real — e o Google usa esses números como sinal de ranqueamento. Vale entender exatamente o que cada um mede, onde está a linha de corte e o que costuma resolver.
Os três números
- LCP — Largest Contentful Paint. Quando o maior elemento visível (geralmente uma imagem de destaque ou o bloco de título) termina de aparecer. É a métrica de percepção de carregamento: o momento em que o usuário sente que a página chegou.
- INP — Interaction to Next Paint. Quanto tempo a página leva para responder visualmente às interações do usuário (cliques, toques, teclas) ao longo da visita. É a métrica de responsividade. Desde 2024 o INP substituiu o antigo FID, e é bem mais exigente: mede a interação inteira, não só o primeiro toque.
- CLS — Cumulative Layout Shift. O quanto o layout "pula" enquanto carrega — aquele botão que se move no instante em que você vai clicar. É a métrica de estabilidade visual e não tem unidade: é uma pontuação.
Os limites (2026)
O Google classifica cada métrica em três faixas. Para uma página ser considerada boa, as três precisam estar na faixa verde:
| Métrica | Bom | Precisa melhorar | Ruim | | ------- | -------- | ---------------- | -------- | | LCP | < 2,5 s | 2,5 s – 4,0 s | ≥ 4,0 s | | INP | < 200 ms | 200 ms – 500 ms | ≥ 500 ms | | CLS | < 0,1 | 0,1 – 0,25 | ≥ 0,25 |
Um detalhe que muda tudo: o Google avalia no percentil 75 dos seus visitantes reais. Ou seja, não basta ficar rápido no seu MacBook — pelo menos 75% das visitas precisam cair na faixa boa, incluindo celulares medianos em redes ruins. A média engana; o percentil 75 é honesto.
Corrigindo o LCP
O LCP quase sempre é uma imagem ou um bloco de texto grande. O que costuma resolver:
- Não faça o elemento de LCP esperar. Pré-carregue a imagem principal e sirva-a em
formato moderno e no tamanho certo. No Next.js,
next/imagecompriorityna imagem "acima da dobra" cuida de boa parte disso. - Reduza o tempo até o primeiro byte. Renderização no servidor e cache aproximam o HTML do usuário — conteúdo que já chega pronto não espera JavaScript para aparecer.
- Tire fontes e scripts do caminho crítico. Fonte que bloqueia renderização atrasa o
texto; use
next/font, que já lida com isso.
Corrigindo o INP
INP é onde apps ricos em JavaScript tropeçam. A causa raiz costuma ser a mesma: a main thread ocupada demais para responder ao usuário.
- Menos JavaScript no cliente. Todo script que você não envia é trabalho que a thread principal não precisa fazer. React Server Components ajudam aqui por manterem no servidor o que não é interativo.
- Quebre trabalho longo. Uma função que trava 300 ms segura toda interação nesse intervalo. Divida o processamento e adie o que não é urgente.
- Cuidado com re-renders em cascata. No React, um estado mal posicionado re-renderiza meia árvore a cada tecla digitada. Memoização e componentes bem delimitados evitam isso.
Corrigindo o CLS
CLS é o mais fácil de zerar e o mais fácil de ignorar até um usuário clicar no lugar errado:
- Reserve espaço para mídia. Sempre declare
widtheheight(ou umaspect-ratio) em imagens, vídeos e iframes. Onext/imagereserva o espaço automaticamente. - Evite injetar conteúdo empurrando o resto. Banners, avisos de cookie e anúncios que entram depois deslocam a página. Reserve o espaço deles desde o início.
- Fontes sem "salto". Configure o fallback para que a troca da fonte não mude a altura das linhas.
Lab não é campo
Um alerta que evita muita confusão. A nota do Lighthouse (ou do painel do DevTools) é um teste de laboratório: uma simulação, num ambiente controlado. Os Core Web Vitals que o Google usa para ranquear vêm do campo — dados reais de usuários (o dataset CrUX).
Eles divergem, e é normal: o Lighthouse não mede INP de verdade porque não há ninguém interagindo. Use o lab para diagnosticar e iterar rápido; use o campo (Search Console, CrUX, ou instrumentação de RUM no seu próprio site) para saber se você realmente passou.
Quer um diagnóstico dos Core Web Vitals do seu produto e um plano para entrar no verde? Fale com a gente.