"Core Web Vitals: meça e melhore a experiência do usuário"

Core Web Vitals são as três métricas com que o Google traduz "experiência do usuário" em números mensuráveis. Elas medem velocidade de carregamento, responsividade e estabilidade visual — exatamente as coisas que fazem um site parecer rápido ou frustrante. Para devs, dominá-las significa entregar páginas melhores e, de quebra, ganhar pontos de ranqueamento. Este guia explica LCP, INP e CLS e mostra como otimizar cada uma, do diagnóstico à correção.

A boa notícia é que as três métricas têm causas conhecidas e correções conhecidas. Não é magia: por trás de um LCP ruim há quase sempre um servidor lento ou uma imagem pesada; por trás de um INP ruim há JavaScript demais bloqueando a thread; por trás de um CLS ruim há espaço que não foi reservado. Entender essas relações de causa e efeito é o que transforma "meu site está lento" num plano de ação concreto.

O que são os Core Web Vitals

Os Core Web Vitals são um subconjunto das Web Vitals, a iniciativa do Google para padronizar sinais de qualidade de experiência (Google Web.dev, 2020). A ideia é simples: em vez de dezenas de métricas confusas, focar em poucas que realmente refletem o que o usuário sente.

São três, hoje:

Essas métricas se conectam a um princípio antigo de usabilidade: a percepção de tempo de resposta do sistema molda a satisfação do usuário (Nielsen, 1993). Os Core Web Vitals são, em essência, a aplicação web desse princípio com limiares concretos. Eles também são parte central do SEO técnico, já que entram como sinal no ranqueamento.

Por que o Google escolheu justamente essas três

Cada métrica cobre um momento distinto da jornada na página, e juntas elas formam um retrato completo. O LCP responde "a página carregou rápido?". O INP responde "ela reage quando eu interajo?". O CLS responde "ela fica parada enquanto eu uso?". Um site pode ser rápido para carregar e ainda assim frustrante se trava ao clicar (INP ruim) ou se os botões pulam de lugar (CLS ruim). Por isso as três precisam estar no verde — não basta acertar uma.

Vale lembrar que o Google aplica os limiares sobre o percentil 75 dos seus usuários. Ou seja, não basta a mediana estar boa: 75% das visitas precisam atingir o limiar "Bom". Isso pune caudas longas — aquele subconjunto de usuários em dispositivos fracos ou redes ruins que muitas vezes é ignorado.

LCP: Largest Contentful Paint

O LCP marca o instante em que o maior elemento visível na viewport termina de renderizar — geralmente uma imagem de destaque, um vídeo ou um bloco grande de texto. É a métrica que melhor responde à pergunta "quando a página parece carregada?".

Os limiares de referência:

As causas mais comuns de LCP ruim são tempo de resposta lento do servidor, recursos que bloqueiam a renderização (CSS e JS), e imagens pesadas ou sem prioridade.

Para otimizar:

<!-- Pré-carregue o recurso LCP crítico -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<!-- Imagens responsivas e em formato moderno -->
<img src="/hero.webp" width="1200" height="600" alt="Produto em destaque">

Outras táticas: usar CDN, aplicar cache, comprimir imagens (WebP/AVIF), e adotar SSR ou SSG para entregar o conteúdo crítico já no HTML. A escolha entre essas estratégias é discutida em SSR, SSG e CSR.

As quatro fases do LCP

Uma forma poderosa de diagnosticar LCP ruim é quebrá-lo em quatro fases e descobrir onde o tempo está sendo gasto:

Saber em qual fase está o gargalo evita otimização no escuro. Não adianta comprimir a imagem se o problema é um TTFB de 1,5s.

O preload scanner e por que ele importa

Navegadores têm um "preload scanner" que varre o HTML buscando recursos para baixar adiantado. Se a sua imagem de LCP vem de um CSS background-image ou é injetada por JavaScript, o scanner não a enxerga e o download começa tarde. Sempre que possível, sirva a imagem de LCP como uma tag <img> no HTML inicial, para o scanner achá-la imediatamente.

INP: Interaction to Next Paint

O INP mede a responsividade: o tempo entre o usuário interagir (clique, toque, tecla) e a próxima atualização visual da tela. Ele substituiu o antigo FID (First Input Delay) por ser mais completo — observa todas as interações, não apenas a primeira.

Os limiares:

O grande vilão do INP é o JavaScript que ocupa a thread principal. Quando o navegador está ocupado executando scripts, ele não consegue responder às interações.

Estratégias de otimização:

// Cede ao navegador para manter a UI responsiva
async function processarLote(itens) {
  for (const item of itens) {
    fazerTrabalho(item);
    // Permite que o navegador renderize e responda a inputs
    await new Promise((r) => setTimeout(r, 0));
  }
}

As três partes de uma interação

Como o LCP, o INP se decompõe e isso ajuda a achar a causa:

Se o gargalo é o input delay, o problema é outro script roubando a thread; quebre tarefas longas. Se é o processing time, simplifique o handler ou empurre o trabalho pesado para depois do próximo paint.

// Atualize a UI primeiro, faça o trabalho pesado depois de ceder
botao.addEventListener('click', async () => {
  mostrarFeedbackImediato();         // pinta já
  await new Promise(r => setTimeout(r, 0)); // cede
  trabalhoPesado();                  // não bloqueia o paint da resposta
});

Uma API moderna que ajuda é scheduler.yield(), feita justamente para ceder a thread no meio de uma tarefa longa mantendo a prioridade. Onde disponível, ela é mais limpa do que o truque do setTimeout(0).

CLS: Cumulative Layout Shift

O CLS quantifica quanto o layout "pula" durante o carregamento. Aquele momento em que você vai clicar num botão e um banner empurra tudo para baixo? É CLS ruim — e Nielsen (1993) já apontava que imprevisibilidade visual destrói a confiança do usuário na interface.

Por ser um índice de deslocamento (não tempo), os limiares são adimensionais:

As causas clássicas e suas soluções:

Reservando espaço na prática

A correção mais comum é informar ao navegador o espaço que um elemento vai ocupar antes de ele chegar. Para imagens, os atributos width/height permitem ao navegador calcular o aspect-ratio e reservar a caixa. Para áreas dinâmicas (um banner de cookies, um slot de anúncio, um skeleton de carregamento), reserve a altura via CSS:

/* Reserva proporção da imagem mesmo antes de carregar */
img { aspect-ratio: 16 / 9; width: 100%; height: auto; }

/* Reserva altura fixa para um slot que carrega depois */
.slot-anuncio { min-height: 250px; }

O detalhe do font swap

O font-display: swap evita texto invisível, mas pode causar um "salto" quando a fonte web substitui a de fallback com métricas diferentes. Para reduzir isso, pré-carregue a fonte crítica e ajuste as métricas de fallback com size-adjust, ascent-override e descendentes na @font-face, de modo que a fonte de sistema ocupe quase o mesmo espaço da web font. Assim a troca quase não desloca nada.

Medindo: dados de laboratório vs. de campo

Existe uma distinção crucial. Dados de laboratório vêm de testes controlados (como o Lighthouse) e são ótimos para depurar. Dados de campo vêm de usuários reais (Real User Monitoring) e são o que o Google de fato usa para ranqueamento.

Ferramentas úteis:

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

onLCP(console.log);
onINP(console.log);
onCLS(console.log);

A diferença entre laboratório e campo explica por que um site pode pontuar 100 no Lighthouse e ainda falhar no Search Console: a percepção real de usuários, em redes e dispositivos variados, é o que conta.

Por que laboratório e campo divergem

As divergências têm causas concretas, e entendê-las evita perseguir números errados:

Enviar suas métricas de campo para um endpoint próprio (com web-vitals + navigator.sendBeacon) permite segmentar por página, dispositivo e rota, algo que o CrUX agregado não dá.

Um diagnóstico passo a passo no DevTools

Quando uma métrica está vermelha, a investigação no Chrome DevTools segue um roteiro previsível. Vale internalizá-lo:

Esse roteiro transforma uma reclamação genérica ("o site está lento") em uma causa específica ("o LCP é a imagem do banner, que só começa a baixar depois de 1,8s porque é injetada por JS"). Com a causa nomeada, a correção vem sozinha.

O caso comum: terceiros pesados

Uma fonte frequente e subestimada de problemas são os scripts de terceiros — analytics, chats de suporte, pixels de anúncios, widgets sociais. Eles competem pela thread principal (prejudicando o INP) e às vezes injetam conteúdo que desloca o layout (prejudicando o CLS). Estratégias:

Como a rede e o protocolo afetam tudo

Muitos problemas de LCP nascem antes mesmo do navegador renderizar — no transporte dos bytes. Entender o que é HTTP, incluindo conexões persistentes e multiplexação do HTTP/2, ajuda a explicar por que reduzir o número de requisições e usar conexões eficientes melhora o carregamento.

Da mesma forma, o caminho que o Google percorre — crawling, indexação e ranking — usa o desempenho como sinal. Páginas rápidas são rastreadas com mais frequência e oferecem melhor experiência, reforçando o ciclo positivo.

Plano de ação para Core Web Vitals

Um roteiro prático para colocar suas três métricas no verde:

Para técnicas avançadas que vão além das três métricas, consulte o guia de performance web.

Integrando ao fluxo de desenvolvimento

Otimizar uma vez não basta; performance é uma propriedade que regride a cada feature nova. Para que não regrida silenciosamente:

Perguntas frequentes

Core Web Vitals realmente afetam o ranqueamento? Sim, são um sinal confirmado de experiência de página, mas um entre muitos. Relevância e qualidade do conteúdo pesam mais. Pense neles como desempate e como benefício direto de UX, não como atalho mágico de SEO.

Por que meu Lighthouse dá 100 mas o Search Console reprova? Porque o Search Console usa dados de campo (usuários reais, dispositivos e redes variados) e o Lighthouse é laboratório. INP e CLS, em especial, só aparecem direito no campo. Confie no campo para o veredito.

Qual métrica priorizar? A que estiver mais distante do verde no seu p75 de campo. Não otimize a métrica que já está boa. Comece pelo gargalo real.

O CLS conta deslocamentos causados por mim, o usuário? Não. Deslocamentos dentro de 500ms de uma interação do usuário são considerados esperados e não contam. O CLS pune o que se move sem o usuário ter pedido.

Conclusão

Core Web Vitals transformam a vaga ideia de "boa experiência" em três números acionáveis: LCP para carregamento, INP para responsividade e CLS para estabilidade. Otimizá-los exige atenção ao servidor, ao JavaScript e ao layout — mas o retorno é duplo: usuários mais satisfeitos e melhor ranqueamento. Decomponha cada métrica em suas fases para achar o gargalo real, comece medindo com dados de campo no percentil 75, priorize a métrica mais fraca e integre essas verificações ao seu fluxo de SEO técnico com orçamento de performance e CI. Velocidade percebida, como Nielsen (1993) já ensinava, é uma das bases da usabilidade — e hoje o Google a recompensa explicitamente (Google Web.dev, 2020).

Referências