Core Web Vitals: LCP, INP e CLS explicados

O PageSpeed Insights bateu 47/100 em Performance no site do cliente, e o relatório apontava três siglas em vermelho: LCP, INP, CLS. O cliente queria saber o que consertar. O time de desenvolvimento queria saber por onde começar. Ninguém tinha certeza do que as três métricas mediam de fato — só que estavam vermelhas e que isso afetava o ranking.

Esse post existe para resolver esse problema de uma vez.

O que são Core Web Vitals

Core Web Vitals é o conjunto de métricas que o Google usa para avaliar a experiência real do usuário em uma página. Não são métricas sintéticas de laboratório — são calculadas a partir de dados reais de usuários coletados pelo Chrome, armazenados no CrUX (Chrome User Experience Report).

Hoje, em 2026, o conjunto é composto por três métricas:

• LCP — Largest Contentful Paint
• INP — Interaction to Next Paint
• CLS — Cumulative Layout Shift

Cada uma mede um aspecto diferente da experiência: carregamento, interatividade e estabilidade visual, respectivamente.

O Google avalia cada métrica no percentil 75 das sessões reais. Isso significa que 75% dos seus visitantes precisam ter uma experiência "boa" para a página passar. Não é a média — é o percentil 75. Um site rápido para a maioria mas lento para usuários em conexão móvel pode reprovar mesmo assim.

LCP: Largest Contentful Paint

LCP mede quanto tempo leva para o maior elemento visível da viewport ser renderizado.

Threshold:

• Bom: ≤ 2.5 segundos
• Precisa melhorar: 2.5 s – 4.0 s
• Ruim: > 4.0 segundos

O "maior elemento" é geralmente a imagem principal (hero image), um bloco de texto grande ou o thumbnail de um vídeo. O browser identifica automaticamente qual elemento é o maior no viewport no momento do carregamento.

O que afeta o LCP

O LCP tem quatro causas principais:

1. Tempo de resposta do servidor (TTFB alto) — antes de renderizar qualquer coisa, o browser precisa receber o HTML. Um TTFB acima de 600 ms já compromete o LCP.

2. CSS e JS bloqueando a renderização — recursos com render-blocking no critical path atrasam o primeiro paint.

3. Imagem sem prioridade de fetch — se o elemento LCP é uma imagem, o browser geralmente a descobre tarde (só após parsear o HTML e o CSS). Sem fetchpriority="high", ela compete com outros recursos.

4. Imagem não otimizada — arquivo grande + formato ruim = download lento.

Como melhorar o LCP

<!-- adiciona fetchpriority na imagem LCP -->
<img
  src="/hero.webp"
  fetchpriority="high"
  loading="eager"
  alt="Descrição"
/>

Além disso: servir imagens em WebP ou AVIF, usar CDN com cache agressivo, e evitar redirect chains no carregamento inicial. Se o LCP for texto, garantir que a fonte esteja com font-display: swap e, de preferência, pré-carregada:

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

INP: Interaction to Next Paint

INP é a métrica mais nova — e a mais frequentemente reprovada. Em março de 2024, o Google substituiu o FID (First Input Delay) pelo INP como Core Web Vital oficial.

Por que trocar o FID? O FID media apenas o delay até o primeiro input do usuário ser processado. INP é mais abrangente: mede a latência de todas as interações da sessão (cliques, taps, pressionamentos de tecla), e reporta o pior caso (com uma pequena margem de tolerância para outliers).

Threshold:

• Bom: ≤ 200 ms
• Precisa melhorar: 200 ms – 500 ms
• Ruim: > 500 ms

Em 2026, o INP é a métrica com maior taxa de reprovação: 43% dos sites ainda ficam acima dos 200 ms. Não por acaso — ela expõe trabalho real no main thread que o FID escondia.

Como o INP é calculado

Uma interação no INP tem três fases:

1. Input delay — tempo entre o evento do usuário e o início do event handler
2. Processing time — tempo de execução do handler
3. Presentation delay — tempo até o próximo frame ser pintado pelo browser

O INP é o pior percentil dessas interações durante toda a sessão, ignorando apenas os outliers mais extremos (para sessões com muitas interações, descarta-se os piores).

O que causa INP alto

• Long tasks no main thread — qualquer task acima de 50 ms bloqueia o browser. Se um evento de clique dispara uma long task, o INP explode.
• Hydration pesada em frameworks — React, Vue, Angular: o processo de hydration pode bloquear o main thread por centenas de milissegundos em páginas complexas.
• Event handlers síncronos fazendo trabalho pesado — parsing de dados, manipulação do DOM, loops sobre listas grandes.

Como melhorar o INP

A abordagem principal é quebrar long tasks com scheduler.yield() ou setTimeout(0):

button.addEventListener('click', async () => {
  // trabalho urgente — precisa responder ao usuário
  updateUI();

  // cede o main thread antes de continuar
  await scheduler.yield();

  // trabalho pesado que pode esperar
  processLargeDataset();
});

Outra técnica é mover trabalho pesado para um Web Worker, tirando do main thread completamente. Qualquer coisa que não precise tocar o DOM é candidata.

Para frameworks, o ponto de atenção é não fazer trabalho desnecessário no event handler — defer cálculos que não impactam o visual imediato.

CLS: Cumulative Layout Shift

CLS mede instabilidade visual — o quanto os elementos da página se movem de forma inesperada enquanto o usuário está interagindo.

Threshold:

• Bom: ≤ 0.1
• Precisa melhorar: 0.1 – 0.25
• Ruim: > 0.25

O valor do CLS é adimensional — é a soma de todos os "layout shift scores" durante a sessão. Cada shift é calculado como impact fraction × distance fraction, onde impact fraction é a área afetada e distance fraction é a distância que o elemento percorreu (como fração da viewport).

Causas comuns de CLS

• Imagens sem dimensões declaradas — o browser não reserva espaço antes de carregar a imagem, e o layout se ajusta quando ela chega.
• Anúncios e embeds injetados dinamicamente — banners de ad networks que aparecem no topo empurram todo o conteúdo para baixo.
• Fontes web causando FOUT — quando a fonte carrega e substitui a fallback, o tamanho dos textos pode mudar e deslocar elementos.
• Elementos injetados acima de conteúdo existente — toasts, banners de cookies, overlays que reflow o layout.

Como corrigir CLS

/* sempre declare width e height em imagens */
img {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9; /* reserve o espaço */
}

Para anúncios, reservar o espaço com min-height antes de o ad carregar. Para fontes, font-display: optional elimina o FOUT completamente (mas a fonte pode não aparecer se o carregamento for lento). font-display: swap é o meio-termo — fonte substituta visível, mas troca quando a web font chega.

@font-face {
  font-family: 'Inter';
  font-display: swap; /* ou optional, dependendo da tolerância ao FOUT */
}

Como medir Core Web Vitals

Tem dois contextos distintos: lab data (sintético) e field data (real).

Lab data (simulação):

• Lighthouse (DevTools, CLI, ou PageSpeed Insights)
• WebPageTest

Field data (usuários reais):

• PageSpeed Insights → aba "Field Data" (puxa do CrUX)
• Google Search Console → relatório "Core Web Vitals"
• web-vitals library diretamente no código

# auditar uma URL via CLI
npx lighthouse https://exemplo.com --output html --output-path report.html

A diferença importa: lab data usa uma conexão e hardware simulados, em condições controláveis. Field data reflete o que seus usuários reais experimentam. É possível passar no Lighthouse de laboratório e reprovar no CrUX — geralmente por usuários em dispositivos lentos ou redes móveis piores do que o simulado.

Para monitorar produção, a biblioteca oficial web-vitals do Google envia as métricas para qualquer endpoint analytics:

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

onLCP(metric => sendToAnalytics(metric));
onINP(metric => sendToAnalytics(metric));
onCLS(metric => sendToAnalytics(metric));

Core Web Vitals afetam de fato o ranking?

Sim — mas com nuances. O Google confirmou que Core Web Vitals são um fator de ranking desde 2021, e o INP entrou como fator oficial junto com a substituição do FID em março de 2024.

A palavra-chave é "tiebreaker". Para duas páginas com conteúdo, autoridade e relevância semelhantes, aquela que passa nos Core Web Vitals leva vantagem. Não é como backlinks ou relevância de conteúdo — não vai compensar uma página de baixa qualidade. Mas num nicho competitivo onde os primeiros resultados têm qualidade parecida, pode ser o fator que diferencia a posição 3 da posição 1.

O impacto mais direto é na taxa de rejeição. Um site que leva 4 segundos para o LCP ou tem layout pulando perde usuário antes de qualquer consideração de ranking.

Perguntas frequentes

O CrUX não tem dados suficientes para o meu site. O que acontece?

O Google usa um fallback hierárquico: URL → grupo de URLs similar → domínio inteiro. Se seu site tem pouco tráfego e os dados por URL não são suficientes, o Google usa os dados do domínio. Para sites muito pequenos, os Core Web Vitals podem não afetar o ranking diretamente por falta de dados.

Meu site passa no Lighthouse local mas reprova no Search Console. Por quê?

Lab data e field data são contextos diferentes. O Lighthouse simula um Moto G Power em conexão 4G lenta — uma condição específica. Seus usuários reais podem estar em dispositivos ainda mais lentos, em conexões piores, com outras abas abertas. O percentil 75 do CrUX captura esses casos. Confie mais no field data para decisões de produto.

INP e FID medem a mesma coisa?

Não. FID media apenas o delay até o primeiro input ser processado — e só o delay inicial, não o tempo de execução. INP mede todas as interações da sessão, incluindo o tempo de execução do handler e o tempo até o próximo paint. Um site podia ter FID excelente mas main thread travado em interações subsequentes. INP expõe isso.

Tem como melhorar o INP sem mudar o framework?

Sim. O ganho mais rápido geralmente está em event handlers — identificar quais estão fazendo trabalho pesado com o DevTools Performance panel (procurar por "Long Animation Frame" ou "Long Task" disparados por interação), e mover o trabalho pesado para depois do yield ou para um Worker.

O percentil 75 é o número que você precisa monitorar

Core Web Vitals não são uma auditoria única — são um sinal contínuo. Um deploy que introduz uma imagem LCP sem fetchpriority, um componente que faz trabalho pesado em evento de clique, um banner de cookie mal implementado — qualquer um desses pode reprovar uma métrica que estava passando.

O caminho prático é instrumentar web-vitals em produção, mandar os dados para um analytics, e criar alertas quando o percentil 75 sobe acima do threshold. Lighthouse ocasional ajuda a identificar regressões antes do deploy — mas é o field data que diz o que está acontecendo de verdade com os seus usuários.

Para auditar o <meta> e og:image do seu site enquanto otimiza para LCP, uso o Quick Tools Meta Tag Generator — é mais rápido do que escrever as tags na mão e verificar o preview de compartilhamento social.

Nota: o conteúdo editorial acabou aqui. O que vem abaixo é uma indicação do projeto descrito no post.

Sobre o Quick Tools

O Quick Tools é uma plataforma de ferramentas para devs e produtividade, rodando como site estático. Acesse em quickeasy.tools.