Voltar ao blog
Core Web VitalsLCPINPCLSperformance webRUMSEO

Core Web Vitals em 2026: como medir e otimizar LCP, INP e CLS de verdade

2026-07-08
Core Web Vitals em 2026: como medir e otimizar LCP, INP e CLS de verdade

Todo mundo já ouviu que "site rápido converte mais e ranqueia melhor". O problema é que velocidade, sozinha, é um conceito vago. O que o Google mede, o que o usuário sente e o que o desenvolvedor otimiza precisam falar a mesma língua, e essa língua tem nome: Core Web Vitals. Em 2026, essas métricas deixaram de ser um exercício de dashboard verde no Lighthouse e se tornaram um indicador de negócio, ligado diretamente a taxa de rejeição, posição orgânica e receita.

Este guia é sobre métricas e otimização, não sobre modelo de renderização. Se você quer entender quando usar SSR, SSG ou ISR, esse é outro assunto (e temos um post inteiro sobre isso). Aqui, o foco é: o que cada métrica mede, como medir corretamente, e o que efetivamente move o ponteiro.

O que são os Core Web Vitals

Os Core Web Vitals são um subconjunto das métricas de experiência que o Google usa para avaliar páginas. São três, e cada uma responde a uma pergunta diferente que o usuário faz, mesmo sem perceber:

  • LCP (Largest Contentful Paint): "o conteúdo principal já apareceu?" Mede carregamento.
  • INP (Interaction to Next Paint): "a página responde quando eu clico?" Mede responsividade.
  • CLS (Cumulative Layout Shift): "as coisas ficam paradas no lugar?" Mede estabilidade visual.

A grande mudança recente foi a aposentadoria do antigo FID (First Input Delay) em favor do INP, que passou a ser Core Web Vital oficial em 2024. O FID media apenas o atraso da primeira interação; o INP observa a latência ao longo de toda a sessão e reporta praticamente o pior caso. Na prática, o INP é muito mais honesto sobre a sensação real de uso, e muito mais difícil de enganar.

As metas que importam

O Google avalia cada métrica pelo percentil 75 dos carregamentos reais: 75% das visitas precisam ficar dentro do limite "Bom". Não basta a mediana ser boa se a cauda de usuários em dispositivos modestos sofre.

Métrica O que mede Bom Precisa melhorar Ruim
LCP Tempo até o maior elemento visível renderizar ≤ 2,5s 2,5s a 4,0s > 4,0s
INP Latência das interações do usuário ≤ 200ms 200ms a 500ms > 500ms
CLS Deslocamento visual acumulado (sem unidade) ≤ 0,1 0,1 a 0,25 > 0,25

Guardar esses números é o primeiro passo. O segundo, e mais negligenciado, é medir do jeito certo.

Dados de laboratório x dados de campo

Aqui mora o erro mais comum de quem começa: rodar o Lighthouse uma vez, ver "95 de performance" e declarar vitória. Existem duas fontes de dados, e elas respondem a perguntas diferentes.

  • Dados de laboratório (lab): medições em ambiente controlado e simulado, como Lighthouse e WebPageTest. Ótimos para diagnóstico e para pegar regressões antes do deploy, porque são reproduzíveis. Mas rodam numa máquina e numa rede que não são as do seu usuário.
  • Dados de campo (field / RUM): métricas coletadas de usuários reais, com seus dispositivos, conexões e comportamentos de verdade. É o que o Google usa para ranquear, via CrUX (Chrome User Experience Report).

A regra prática: otimize com base no campo, diagnostique com o laboratório. Um detalhe importante: o INP quase não aparece de forma confiável no laboratório, porque depende de o usuário interagir. Sem RUM, você está voando às cegas justamente na métrica mais sensível.

As ferramentas certas

Um fluxo de medição maduro combina algumas camadas:

  1. PageSpeed Insights: junta laboratório (Lighthouse) e campo (CrUX) na mesma tela. Bom ponto de partida para uma URL.
  2. Search Console → relatório de Core Web Vitals: mostra o campo agregado por grupos de URLs do seu site, direto da fonte que o Google usa.
  3. Lighthouse / DevTools: diagnóstico local, trilha de performance, identificação do elemento LCP e das tarefas longas que travam o INP.
  4. RUM próprio: a biblioteca web-vitals do Google coletando métricas dos seus usuários reais e enviando para o seu analytics. É o que permite segmentar por página, país, dispositivo e versão de deploy.

Um exemplo mínimo de coleta de campo no navegador, com a biblioteca oficial:

import { onLCP, onINP, onCLS } from 'web-vitals';

function enviar(metric) {
  // envie para seu endpoint de analytics
  navigator.sendBeacon('/rum', JSON.stringify({
    nome: metric.name,      // LCP | INP | CLS
    valor: metric.value,
    id: metric.id,
    rota: location.pathname,
  }));
}

onLCP(enviar);
onINP(enviar);
onCLS(enviar);

Com esses dados no seu banco, você para de discutir "achismo de performance" e começa a olhar o percentil 75 real, por rota, semana a semana.

Como otimizar o LCP

O elemento LCP costuma ser a imagem do hero, um bloco de texto grande ou um vídeo. Otimizar LCP é, em essência, entregar o pixel mais importante o mais cedo possível.

  • Priorize o recurso crítico: use fetchpriority="high" na imagem do hero e rel="preload" para ela. Nunca deixe o LCP escondido atrás de lazy loading.
  • Sirva imagens modernas e dimensionadas: AVIF ou WebP, com srcset para cada tamanho de tela. Uma imagem de hero de 2 MB é a causa nº 1 de LCP ruim.
  • Ataque o TTFB: LCP começa a contar no primeiro byte. Cache na borda (CDN), respostas comprimidas e um servidor que não fica pensando ajudam antes de qualquer pixel.
  • Elimine recursos bloqueantes: CSS e fontes que bloqueiam a renderização adiam o LCP. Use font-display: swap e injete o CSS crítico inline.

Como otimizar o INP

O INP é sobre a thread principal do navegador. Toda vez que o JavaScript monopoliza essa thread, cliques e toques ficam na fila. As alavancas:

  • Quebre tarefas longas: qualquer bloco de JS acima de ~50ms é uma "long task". Divida com scheduler.yield() ou setTimeout, devolvendo o controle ao navegador entre pedaços.
  • Reduza o custo de hidratação: menos JavaScript enviado, menos trabalho no boot. Code splitting, carregamento sob demanda e evitar hidratar componentes que ninguém vê.
  • Adie o não essencial: scripts de terceiros (chat, analytics, tags de marketing) são vilões clássicos do INP. Carregue-os com defer, fora da thread crítica, ou via web worker quando possível.
  • Otimize o próprio handler: debounce em eventos de digitação, evitar layout thrashing (ler e escrever no DOM de forma alternada) e mostrar feedback visual imediato antes de trabalho pesado.

Como otimizar o CLS

CLS é o mais fácil de resolver e o mais fácil de ignorar. Ele mede saltos inesperados de layout, aquele momento em que você vai clicar num botão e um banner empurra tudo para baixo.

  • Reserve espaço para mídia: sempre defina width e height (ou aspect-ratio) em imagens, vídeos e iframes.
  • Cuidado com fontes: o "flash" de troca de fonte reorganiza o texto. Pré-carregue as fontes e use size-adjust para reduzir o salto.
  • Não injete conteúdo acima do existente: banners de cookie, avisos e anúncios que aparecem no topo empurram a página. Reserve o espaço deles desde o início.
  • Anime com transform, não com propriedades de layout: transições em top ou height deslocam o resto; transform e opacity não.

Um ciclo de melhoria que funciona

Performance não é um projeto com fim, é um processo. O ciclo que recomendamos:

  1. Meça o campo (CrUX / RUM) para saber qual métrica está no vermelho, em quais páginas e dispositivos.
  2. Diagnostique no laboratório (Lighthouse / DevTools) para achar a causa raiz.
  3. Corrija uma alavanca por vez e implemente um orçamento de performance (limites de peso de JS e imagem) no CI para não regredir.
  4. Verifique no campo depois do deploy, comparando o percentil 75 antes e depois.

Sem o passo 1 e o passo 4, você otimiza o que é fácil de medir, não o que dói no usuário.

Performance é engenharia, não sorte

Os Core Web Vitals traduzem, em três números auditáveis, algo que sempre foi difícil de defender: a diferença entre uma página que respeita o tempo do usuário e uma que o desperdiça. LCP, INP e CLS não são metas do Google: são a experiência real de quem tenta usar o seu produto num celular mediano, numa conexão instável, com pressa.

Na ConstructorTI, tratamos performance como requisito de engenharia desde o primeiro commit: orçamento de performance no CI, RUM medindo usuários reais e otimização guiada por dados de campo, não por palpite. Se a sua página está travando no INP, perdendo posição por LCP alto ou espantando visitantes com layout instável, fale com o nosso time e saia da conversa com um diagnóstico claro e um plano de otimização orientado a métricas.