Core Web Vitals: guia completo 2026

Core Web Vitals (CWV) são o conjunto de métricas do Google que medem a experiência real do usuário: velocidade de carregamento, capacidade de resposta da interface e estabilidade visual. Desde maio de 2021 fazem parte da Experiência da Página e entram no ranqueamento.

As três métricas são avaliadas por URL: ótimos resultados na home não ajudam as páginas de produto. O Google obtém os dados do Chrome UX Report (usuários reais), e não de simulações de laboratório.

zoom_in

O que são Core Web Vitals

História: do FID ao INP

O Google apresentou os Core Web Vitals em 2020 com três métricas: LCP, FID (First Input Delay) e CLS. O FID media o atraso do primeiro toque. Era útil, mas cobria apenas uma fração da interatividade da página.

LCP — Largest Contentful Paint

O LCP registra o momento em que o maior bloco visível com conteúdo da página termina de ser pintado. Normalmente é uma imagem de destaque, a capa de um artigo ou um H1 grande.

Causas comuns de LCP lento

• TTFB lento (servidor, CDN, sem cache) — responde por até 40% do tempo do LCP
• Imagem de destaque sem prioridade: falta fetchpriority="high"
• Imagem de destaque sem preload (<link rel="preload">)
• CSS e JS que bloqueiam a renderização atrasam a primeira pintura
• Imagens grandes demais: sem WebP/AVIF e sem srcset
• Elemento LCP depende de renderização via JS (SSR do React ainda não concluído no momento do LCP)

<!-- Prioritise the LCP image -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

<img
  src="/hero.webp"
  alt="Hero"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  width="1280"
  height="720"
/>

INP — Interaction to Next Paint

O INP mede o atraso entre qualquer interação do usuário (clique, tecla, toque) e a próxima pintura visual da página. Diferente do FID, o INP acompanha todas as interações da sessão e usa o pior caso, com remoção de outliers.

O que prejudica o INP

• Long Tasks acima de 50 ms bloqueiam a thread principal: o navegador não consegue processar a entrada
• Handlers de evento pesados: setState síncrono no React e atualizações maciças do DOM
• Falta de scheduler.yield() ou setTimeout(0) para quebrar as Long Tasks
• Scripts de terceiros (chat, anúncios, analytics) ocupam a thread principal
• Animações feitas em JavaScript em vez de transform/opacity em CSS

// Breaking up a Long Task with scheduler.yield()
async function processLargeList(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    // Yield to the main thread every 50 items
    if (i % 50 === 0) {
      await scheduler.yield();
    }
  }
}

CLS — Cumulative Layout Shift

O CLS é uma métrica sem unidade que descreve o deslocamento inesperado total dos elementos da página. Fórmula: fração de impacto × fração de distância. Deslocar um botão que foi pressionado não conta: só entram na conta os elementos que se movem sem ação do usuário.

Causas comuns de CLS

• Imagens sem os atributos width e height: o navegador não sabe o tamanho antes do carregamento
• Fontes web sem font-display: optional ou swap: o FOUT desloca o texto
• Banners e avisos de cookies inseridos dinamicamente no topo da página
• Animações CSS que alteram top/left/margin em vez de transform
• Anúncios sem espaço reservado (min-height no contêiner)

/* Reserve space for an ad slot */
.ad-container {
  min-height: 250px;
  width: 100%;
}

/* Animation without CLS: transform and opacity only */
.card:hover {
  transform: translateY(-4px);
  /* Wrong: margin-top: -4px — this shifts layout */
}

Impacto no ranqueamento

O Google confirmou: os CWV são um dos sinais da Experiência da Página que participam do ranqueamento. Mas funcionam como desempate, não como fator principal. Uma página com ótimo conteúdo e CWV ruins supera uma página com CWV ótimos e conteúdo fraco.

O efeito indireto pesa mais: páginas rápidas reduzem a taxa de rejeição e aumentam a profundidade de sessão e a conversão. O argumento de negócio para os CWV é mais forte que o argumento de SEO. A Amazon constatou que +100 ms no LCP equivalem a -1% de receita.

Como medir os Core Web Vitals

Há dois tipos de dados: dados de laboratório (simulação — Lighthouse, WebPageTest) e dados de campo (usuários reais — CrUX, GSC). O Google ranqueia com base nos dados de campo. O laboratório serve para o diagnóstico.

Ferramentas de diagnóstico

// web-vitals v4 — collect real CWV
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics({ name, value, id }) {
  // Send to GA4
  gtag('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_id: id,
    metric_delta: value,
  });
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Checklist de otimização

zoom_in

LCP

• Adicione fetchpriority="high" e remova loading="lazy" da imagem de destaque
• Adicione <link rel="preload" as="image"> para a imagem de destaque no <head>
• Converta as imagens para WebP ou AVIF e configure o srcset
• Reduza o TTFB para ≤ 800 ms: CDN, cache e SSR na edge
• Remova do <head> os scripts que bloqueiam a renderização (async/defer/module)
• Defina Cache-Control: max-age=31536000 para os recursos estáticos

INP

• Analise as Long Tasks em Chrome DevTools → Performance → Main Thread
• Quebre as tarefas acima de 50 ms com scheduler.yield() ou setTimeout(0)
• Aplique debounce nos handlers de input / scroll (16–100 ms)
• Otimize o React: useMemo, useCallback, React.memo e virtualização de listas
• Mova os scripts de terceiros para Web Workers ou carregue-os depois do LCP
• Use animações CSS somente com transform e opacity

CLS

• Defina width e height em todos os elementos <img>: o navegador reserva o espaço
• Use aspect-ratio em contêineres com dimensões desconhecidas
• Configure font-display: optional nas fontes críticas
• Reserve min-height para espaços de anúncios e conteúdo dinâmico
• Posicione avisos (cookies, banners) na parte inferior da página, e não no topo
• Verifique o FOUT: fontes sem fallback deslocam o texto no carregamento