LGMdevs
Back to blog
Equipe LGMdevs

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.

PerformanceSEOReact

"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/image com priority na 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 width e height (ou um aspect-ratio) em imagens, vídeos e iframes. O next/image reserva 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.

Fontes