Core Web Vitals: Guia Completo de Otimização para LCP, INP e CLS em 2026

A velocidade de carregamento deixou de ser apenas uma questão de experiência do usuário para se tornar um fator de ranqueamento oficial do Google. Desde 2021, os Core Web Vitals são parte do algoritmo, e em março de 2024 o Google substituiu o FID (First Input Delay) pela INP (Interaction to Next Paint). Em 2026, essas três métricas — LCP, INP e CLS — definem, na prática, a qualidade percebida da sua página, tanto para o ranking quanto para a conversão.

Se a sua página demora mais de 2,5 segundos para carregar o conteúdo principal, trava ao receber cliques ou "pula" enquanto o usuário lê, você está perdendo posições e vendas. Este guia mostra exatamente como medir, diagnosticar e corrigir cada uma das três métricas, com exemplos de código HTML, CSS e JavaScript aplicáveis na prática.

O que são os Core Web Vitals

Os Core Web Vitals são um conjunto de métricas definidas pelo Google para medir a experiência real de carregamento, interatividade e estabilidade visual das páginas. São três, e cada uma mede um aspecto diferente:

<script src="https://unpkg.com/web-vitals@4/dist/web-vitals.iife.js"></script>
<script>
  const vitals = {};

  function reportVital(metric) {
    vitals[metric.name] = metric.value;
    console.log(`${metric.name}: ${metric.value}`);
  }

  webVitals.onCLS(reportVital);
  webVitals.onLCP(reportVital);
  webVitals.onINP(reportVital);
</script>

Em produção, você enviaria esses valores para sua ferramenta de analytics para construir um dashboard de performance real.

LCP: otimizando o Largest Contentful Paint

O LCP mede o tempo até o maior elemento visível da viewport ser renderizado. Na maioria das vezes, esse elemento é uma imagem de herói, um vídeo ou um bloco grande de texto. Um LCP ruim significa que o usuário está olhando para uma tela em branco ou parcialmente carregada.

Principais causas de LCP ruim

• Servidor lento — TTFB alto (acima de 800ms)
• Imagem de herói pesada — não otimizada, em formato antigo
• Renderização bloqueada por CSS — folhas de estilo grandes e não críticas
• JavaScript que bloqueia a renderização — scripts no cabeçalho que impedem o navegador de pintar
• Prefetch/render sem priorização — o navegador baixa elementos sem importância antes do conteúdo principal

Como corrigir: HTML e CSS

1. Otimize e priorize a imagem de herói

<!-- Antes: JPEG pesado, sem dimensões, carregado por último -->
<img src="hero.jpg" alt="Banner">

<!-- Depois: WebP, com dimensões e preload -->
<link rel="preload" as="image" href="/img/hero-1200.webp">
<img
  src="/img/hero-1200.webp"
  alt="Banner principal"
  width="1200"
  height="675"
  fetchpriority="high"
>

O atributo fetchpriority="high" diz ao navegador para priorizar o download dessa imagem. O width e height previnem CLS. O preload dispara o download o quanto antes.

2. Carregue CSS crítico inline

Em vez de bloquear a renderização com um CSS inteiro, entregue apenas o CSS essencial para a primeira pintura:

<style>
  /* CSS crítico: header, hero, primeira dobra */
  .hero { display: grid; place-items: center; min-height: 60vh; }
  .hero-title { font-size: clamp(1.8rem, 4vw, 3.5rem); }
</style>
<!-- Restante do CSS carregado de forma assíncrona -->
<link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/main.css"></noscript>

Esse padrão (CSS crítico inline + CSS assíncrono) reduz drasticamente o tempo de primeira pintura sem sacrificar o design completo.

3. Melhore o TTFB no servidor

• Ative cache nas respostas HTTP.
• Use CDN para servir conteúdo estático de pontos próximos ao usuário.
• No Node.js/Next.js, considere edge rendering e streaming.
• No Apache ou Nginx, ative gzip ou Brotli:

# Nginx: compressão Brotli
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

4. Lazy load apenas o que está abaixo da dobra

<img
  src="produto-a.jpg"
  alt="Produto A"
  loading="lazy"
  decoding="async"
  width="600"
  height="400"
>

Atenção: nunca use loading="lazy" na imagem de herói. Ela precisa carregar primeiro.

INP: deixando a página responsiva a interações

A INP mede a latência de todas as interações: quanto tempo entre o usuário clicar e a página responder visualmente. O vilão da INP é quase sempre o JavaScript longo e bloqueante na thread principal — o main thread.

Causas comuns de INP ruim

• JavaScript pesado no load que continua executando e "rouba" a thread
• Listeners de eventos lentos que executam trabalho síncrono pesado
• Renderizações (reflow) desnecessárias disparadas em cada interação
• Animações que travam a thread principal em vez de usar CSS ou Web Workers
• Third-party scripts (análise, chat, pixel) executando trabalho intenso

Como corrigir: JavaScript

1. Divida tarefas longas com `setTimeout` ou `scheduler.yield()`

Se você processa muitos itens de uma vez, o navegador fica bloqueado:

// Antes: bloqueia a thread por centenas de ms
const itens = await buscarDados();
for (const item of itens) {
  renderizarItem(item);
}

// Depois: divide o trabalho em microtarefas
const itens = await buscarDados();
for (const item of itens) {
  setTimeout(() => renderizarItem(item), 0);
}

Melhor ainda, use a nova API do navegador:

for (const item of itens) {
  if (typeof scheduler !== 'undefined' && scheduler.yield) {
    await scheduler.yield();
  }
  renderizarItem(item);
}

2. Debounce e throttle em listeners

let timeoutId;
input.addEventListener('input', () => {
  clearTimeout(timeoutId);
  timeoutId = setTimeout(() => filtrarResultados(input.value), 300);
});

3. Evite reflows no meio da leitura do layout

// Ruim: lê e escreve no DOM alternadamente, causando reflow a cada ciclo
for (const el of lista) {
  const altura = el.offsetHeight;   // leitura
  el.style.height = altura + 10 + 'px';  // escrita
}

// Bom: lê tudo primeiro, escreve depois
const alturas = lista.map(el => el.offsetHeight);
lista.forEach((el, i) => { el.style.height = alturas[i] + 10 + 'px'; });

4. Use Web Workers para processamento pesado

Processamento de dados, parsing e cálculos complexos não devem rodar no main thread:

// main.js
const worker = new Worker('/js/processador.js');
worker.postMessage({ dados: dadosBrutos });
worker.onmessage = (evento) => { exibirResultado(evento.data); };

// processador.js
self.onmessage = (evento) => {
  const resultado = processarPesado(evento.data.dados);
  self.postMessage(resultado);
};

5. Carregue scripts third-party com cuidado

Chat, pixels e ferramentas de analytics são responsáveis por boa parte da INP ruim. Carregue-os de forma assíncrona e somente quando necessário:

<script async src="https://cdn.chat.com/widget.js"></script>

Considere ainda adiar a inicialização desses widgets até a interação do usuário:

document.addEventListener('scroll', () => { carregarChatWidget(); }, { once: true });

O caso especial dos frameworks JavaScript

Em React, Vue ou Next.js, a INP costuma ser afetada por:

• Muitos componentes hidratando de uma vez — considere Server Components ou partial hydration.
• Estado global mal dividido — cada mudança re-renderiza componentes desnecessários.
• Listas grandes — use virtualização (react-window, virtual) em vez de renderizar 1000 itens.

CLS: estabilidade visual sem surpresas

O CLS (Cumulative Layout Shift) mede o quanto os elementos "pulam" na tela durante o carregamento. Sessão de leitura que desloca, botão que move de lugar no momento do clique e imagens que aparecem só depois do texto são todos CLS.

Causas comuns de CLS

• Imagens sem `width` e `height`
• Iframes, embeds de vídeo e anúncios sem espaço reservado
• Fontes que carregam tarde e trocam o layout (FOUT)
• Inserção dinâmica de conteúdo no meio da página
• Animações que alteram propriedades de layout (height, width, top)

Como corrigir: HTML e CSS

1. Reserve espaço para imagens e vídeos

<!-- Antes: sem dimensões, causa CLS ao carregar -->
<img src="foto.jpg" alt="Foto">

<!-- Depois: com dimensões, navegador reserva o espaço -->
<img
  src="foto.jpg"
  alt="Foto"
  width="1200"
  height="800"
  style="width: 100%; height: auto;"
>

2. Use `aspect-ratio` no CSS para layouts responsivos

.video-container {
  aspect-ratio: 16 / 9;
  width: 100%;
}

.card-img {
  aspect-ratio: 4 / 3;
  object-fit: cover;
  width: 100%;
}

3. Reserve espaço para conteúdo dinâmico e anúncios

/* Em vez de injetar um banner que empurra o conteúdo, reserve o espaço */
.ad-slot {
  width: 300px;
  height: 250px;  /* espaço reservado */
  background: #f0f0f0;
}

4. Carregue fontes com `font-display: swap` e `size-adjust`

@font-face {
  font-family: 'MinhaFonte';
  src: url('/fonts/minhafonte.woff2') format('woff2');
  font-display: swap;
}

/* Corrige o deslocamento causado pela troca de fonte */
h1 {
  font-family: 'MinhaFonte', sans-serif;
  font-size-adjust: 0.5;
}

O font-display: swap mostra a fonte de fallback imediatamente e troca depois; combinado com size-adjust ou font-size-adjust, a troca não causa salto perceptível.

5. Animações seguras que não causam layout shift

Anime apenas propriedades transform e opacity — elas não provocam reflow:

/* Ruim: mexe no layout, causa CLS e jank */
.popup { top: 0; transition: top 0.3s; }

/* Bom: usa transform, sem impacto no layout */
.popup { transform: translateY(100%); transition: transform 0.3s; }
.popup.open { transform: translateY(0); }

Priorização de carregamento com o browser

Uma técnica que otimiza LCP, INP e CLS ao mesmo tempo é a priorização correta de recursos. O navegador baixa os recursos em uma ordem que você pode influenciar:

<!-- 1. CSS crítico (bloqueia pintura, deve ser o primeiro) -->
<link rel="preload" as="style" href="/css/critico.css">

<!-- 2. Imagem de herói -->
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

<!-- 3. Fontes usadas acima da dobra -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/heading.woff2" crossorigin>

<!-- 4. JavaScript essencial, sem bloquear render -->
<script src="/js/app.js" defer></script>

O impacto dos Core Web Vitals no SEO e nas conversões

O Google anunciou oficialmente que as páginas com Core Web Vitals "bons" têm prioridade de ranqueamento em comparação a páginas equivalentes com métricas ruins. Em 2026, com a INP consolidada, o impacto prático é claro:

• Páginas lentas perdem posições para páginas equivalentes mais rápidas.
• A INP afeta diretamente a conversão: sites com resposta instantânea convertem mais.
• O Google separa as URLs em grupos no Search Console: aquelas com vitals "ruins" são sinalizadas para correção.
• Crawling budget: sites mais rápidos são rastreados com maior frequência, indexando mais páginas.

Dados internos de agências (como a TS Digitais, que audita performance de dezenas de sites) mostram um padrão consistente: a correção de Core Web Vitals costuma vir acompanhada de aumento nas posições e, principalmente, de melhora na taxa de conversão — usuários não compram em sites que travam.

Fluxo de trabalho de otimização passo a passo

Siga esta sequência para otimizar qualquer site:

1. Meça — rode o PageSpeed Insights na URL principal e nas páginas de venda.
2. Priorize — trate primeiro a pior métrica da página mais importante.
3. Diagnostique — abra o Chrome DevTools > Performance e grave uma sessão real.
4. Corrija — aplique as correções de HTML/CSS/JS deste guia.
5. Valide — reexecute o PSI e compare o score de laboratório.
6. Acompanhe — confirme a melhora nos dados de campo do Search Console em até 28 dias.

Checklist de Core Web Vitals

FAQ

O que é INP e por que substituiu o FID?

A INP (Interaction to Next Paint) mede o tempo de resposta do navegador a todas as interações do usuário — cliques, toques e digitação — e reporta a pior latência. O FID media apenas o atraso da primeira interação. Como uma página pode ter boa primeira resposta e travar depois, o Google substituiu o FID em março de 2024 para ter uma visão mais completa da responsividade real da página. O valor "bom" é até 200ms.

Qual é o bom valor para cada Core Web Vital em 2026?

LCP até 2,5 segundos, INP até 200ms e CLS até 0,1. Para passar na avaliação do Google, sua página precisa atingir esses valores em pelo menos 75% das visitas, medido em dados de campo de 28 dias. Valores intermediários são classificados como "precisa melhorar" e valores acima como "ruim".

Como otimizar o LCP quando a imagem de herói é o problema?

Converta a imagem para WebP ou AVIF, redimensione para o tamanho real de exibição, adicione preload e fetchpriority="high", e considere um CDN com cache em edge. Se a imagem for ilustrativa, outra opção é substituí-la por CSS puro ou gradiente. Também vale medir o TTFB — se o servidor demora mais de 800ms para responder, nenhuma otimização de imagem resolve sozinha.

O CLS ainda é relevante depois que a página carrega?

Sim. O CLS mede shifts ao longo de toda a vida da página, não apenas no carregamento. Botões que aparecem no meio do texto, pop-ups que empurram o layout e imagens carregadas via lazy que não têm espaço reservado causam CLS mesmo minutos após o load. A boa notícia é que 75% dos shifts de uma página típica acontecem nos primeiros 5 segundos.

Vale a pena otimizar Core Web Vitals em um site pequeno com pouco tráfego?

Sim. Além do impacto direto em ranqueamento, os Core Web Vitals são um proxy da experiência do usuário — e essa experiência influencia conversão, taxa de rejeição e confiança na marca. Um site rápido transmite profissionalismo. E como o Google prioriza páginas rápidas entre páginas equivalentes, otimizar a performance é uma das poucas vantagens de SEO que você controla 100%, sem depender de links ou autoridade.

Artigo escrito por Tiago Silva Dal Bosco, fundador da TS Digitais.