"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:

• LCP (Largest Contentful Paint) — velocidade de carregamento percebida.
• INP (Interaction to Next Paint) — responsividade às interações.
• CLS (Cumulative Layout Shift) — estabilidade visual.

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:

• Bom: até 2,5 segundos
• Precisa melhorar: 2,5 a 4,0 segundos
• Ruim: acima de 4,0 segundos

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:

1. Time to First Byte (TTFB) — quanto o servidor demora para responder. Lento aqui? Otimize backend, banco, cache de borda.
2. Atraso no carregamento do recurso — tempo entre o primeiro byte e o navegador começar a baixar o recurso do LCP. Lento aqui? O recurso foi descoberto tarde; use preload e fetchpriority.
3. Carregamento do recurso — quanto demora para baixar a imagem/fonte do LCP. Lento aqui? A imagem está pesada; comprima e sirva no tamanho certo.
4. Atraso de renderização — tempo entre o recurso pronto e ele aparecer na tela. Lento aqui? CSS ou JS bloqueante está segurando a renderização.

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:

• Bom: até 200 milissegundos
• Precisa melhorar: 200 a 500 milissegundos
• Ruim: acima de 500 milissegundos

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:

• Quebre tarefas longas em pedaços menores, cedendo controle à thread principal.
• Reduza o tamanho do bundle JavaScript com code splitting e tree shaking.
• Adie scripts não críticos com defer ou carregamento sob demanda.
• Use web workers para cálculos pesados fora da thread principal.

// 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:

1. Input delay — o tempo até o navegador conseguir começar a tratar o evento. Alto quando a thread está ocupada com outro script (um analytics pesado carregando, por exemplo).
2. Processing time — quanto o seu manipulador de evento demora para rodar. Alto quando o handler faz trabalho demais de forma síncrona.
3. Presentation delay — o tempo para o navegador desenhar o resultado. Alto quando a mudança causa um layout/paint caro.

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:

• Bom: até 0,1
• Precisa melhorar: 0,1 a 0,25
• Ruim: acima de 0,25

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

• Imagens sem dimensões: sempre defina width e height (ou aspect-ratio no CSS) para o navegador reservar espaço.
• Anúncios e embeds: reserve um contêiner de tamanho fixo antes de carregar.
• Fontes web: use font-display: swap e pré-carregue fontes para reduzir o reflow de texto.
• Conteúdo injetado dinamicamente: evite inserir elementos acima de conteúdo já visível.

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:

• PageSpeed Insights: combina laboratório (Lighthouse) e campo (CrUX).
• Chrome DevTools / Lighthouse: diagnóstico local detalhado.
• Search Console: relatório de Core Web Vitals com dados de campo agregados.
• Biblioteca web-vitals: para coletar suas próprias métricas em produção.

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:

• INP e CLS não se medem bem em laboratório. Ambos dependem de interação real ao longo da visita, algo que um teste sintético de poucos segundos não reproduz. Use o campo como verdade para eles.
• O Lighthouse usa um dispositivo e rede simulados fixos; seus usuários reais variam enormemente. O CrUX captura essa variedade.
• O campo agrega 28 dias. Uma correção que você fez hoje só aparece plenamente no relatório semanas depois. Não conclua que "não funcionou" cedo demais — confirme em laboratório que a causa sumiu e tenha paciência com o campo.

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:

1. Abra a aba Performance e grave o carregamento da página com throttling de CPU e rede (simule um dispositivo mediano, não a sua máquina rápida).
2. Localize o marcador de LCP na timeline para ver qual elemento foi o LCP e em que instante ele pintou.
3. Procure as long tasks — blocos longos na thread principal, marcados com um triângulo vermelho. Eles são os suspeitos do INP.
4. Use a aba Layout Shifts (ou o overlay de CLS) para ver exatamente quais elementos se deslocaram e por quê.

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:

• Carregue com async/defer para não bloquear o parse do HTML.
• Adie os não essenciais para depois da interação ou do carregamento principal.
• Reserve espaço para qualquer widget que insira UI, evitando o salto de layout.
• Audite o custo real de cada script de terceiro; muitos entregam pouco valor por muito peso.

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:

1. Meça primeiro com dados de campo (Search Console + PageSpeed Insights).
2. Ataque o LCP otimizando o servidor, a imagem principal e os recursos que bloqueiam render.
3. Ataque o INP reduzindo e fatiando o JavaScript da thread principal.
4. Ataque o CLS reservando espaço para imagens, fontes e elementos dinâmicos.
5. Monitore continuamente — métricas regridem a cada deploy.

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:

• Orçamento de performance. Defina tetos (tamanho de bundle, número de requisições) e falhe o build quando estourar.
• Lighthouse CI no pipeline. Rode o Lighthouse a cada PR e bloqueie quedas significativas de score.
• Monitoramento de campo com alerta. Se o p75 de uma métrica piorar após um deploy, você quer saber em horas, não no próximo relatório do Search Console.

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

• Google Web.dev (2020). Web Vitals: Essential metrics for a healthy site. Google.
• Jakob Nielsen (1993). Usability Engineering. Morgan Kaufmann.
• Walton, P., & Mihajlija, M. (2023). Interaction to Next Paint (INP). Google web.dev.
• Google (2024). Chrome User Experience Report (CrUX). Google Developers.