Core Web Vitals: Guia Prático Para Desenvolvedores em 2024

· 20 min de leitura · Por Fabio Santiago

O que são Core Web Vitals

Core Web Vitals (CWV) são três métricas que o Google usa para avaliar a experiência do usuário na página:

MétricaO que medeBomPrecisa melhorarRuim
LCPCarregamento do maior elemento≤ 2.5s≤ 4.0s> 4.0s
INPResponsividade a interações≤ 200ms≤ 500ms> 500ms
CLSEstabilidade visual≤ 0.1≤ 0.25> 0.25

Nota: INP (Interaction to Next Paint) substituiu o FID (First Input Delay) em março de 2024.

LCP — Largest Contentful Paint

O que conta como LCP

  • Imagens (<img>, <image> dentro de SVG)
  • Backgrounds via CSS (background-image)
  • Elementos de texto (<h1>, <p>, etc.)
  • Vídeos com poster (<video poster="...">)

Diagnóstico

# No Chrome DevTools → Performance → gravar carregamento
# Ou via Lighthouse:
npx lighthouse https://seusite.com --only-categories=performance

Correções mais comuns

1. Preload da imagem hero

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

2. Otimizar imagens

# Converter para WebP com qualidade 80%
cwebp -q 80 input.png -o output.webp

# Ou usar sharp no build (Astro/Next.js fazem isso nativamente)

3. Eliminar render-blocking CSS

<!-- Inline critical CSS -->
<style>
  /* CSS crítico acima do fold */
  .hero { min-height: 60vh; }
</style>

<!-- Carregar o resto de forma assíncrona -->
<link rel="preload" href="/styles.css" as="style" onload="this.rel='stylesheet'">

4. Font display swap

@font-face {
  font-family: 'Inter';
  font-display: swap; /* Mostra texto com fonte do sistema enquanto carrega */
  src: url('/fonts/inter.woff2') format('woff2');
}

INP — Interaction to Next Paint

O que é

INP mede o tempo entre a interação do usuário (clique, toque, tecla) e a próxima renderização visual. Diferente do FID (que media apenas a primeira interação), o INP considera todas as interações e reporta o p75.

Diagnóstico

// Usar a Web Vitals library
import { onINP } from 'web-vitals';

onINP(console.log);
// Resultado: { name: "INP", value: 156, entries: [...] }

Correções mais comuns

1. Quebrar tarefas longas

// Ruim: bloqueia a thread por 300ms
function processarDados(items) {
  items.forEach(item => { /* cálculo pesado */ });
}

// Bom: quebrar em chunks usando scheduler.yield()
async function processarDados(items) {
  for (let i = 0; i < items.length; i += 50) {
    const chunk = items.slice(i, i + 50);
    chunk.forEach(item => { /* cálculo */ });
    await scheduler.yield(); // devolve controle ao browser
  }
}

2. Debounce em inputs

let timer;
input.addEventListener('input', (e) => {
  clearTimeout(timer);
  timer = setTimeout(() => {
    filtrarResultados(e.target.value);
  }, 150);
});

3. Reduzir JavaScript no carregamento

  • Lazy-load scripts não essenciais
  • Code splitting por rota
  • Evitar third-party scripts bloqueantes

CLS — Cumulative Layout Shift

O que causa CLS alto

  1. Imagens sem dimensões (width/height)
  2. Fontes que causam FOUT (Flash of Unstyled Text)
  3. Conteúdo injetado dinamicamente acima do viewport
  4. Anúncios sem espaço reservado

Correções

1. Sempre definir dimensões

<!-- Ruim -->
<img src="/foto.jpg" alt="Foto">

<!-- Bom -->
<img src="/foto.jpg" alt="Foto" width="800" height="600">

<!-- Melhor: com aspect-ratio CSS -->
<img src="/foto.jpg" alt="Foto" style="aspect-ratio: 4/3; width: 100%; height: auto;">

2. Reservar espaço para embeds

.video-container {
  aspect-ratio: 16 / 9;
  background: #1a1a2e;
}

3. Fontes com font-display

@font-face {
  font-family: 'MinhaFonte';
  font-display: optional; /* Melhor para CLS que 'swap' */
  src: url('/font.woff2') format('woff2');
}

Ferramentas de diagnóstico

FerramentaDadosGratuita
PageSpeed InsightsLab + FieldSim
Chrome DevToolsLabSim
Web Vitals ExtensionLab em tempo realSim
Search Console (CWV report)Field (28 dias)Sim
CrUX DashboardField históricoSim
Lighthouse CILab em CI/CDSim

Dados de campo vs laboratório

  • Lab data: medidos em ambiente controlado (Lighthouse). Útil para debug.
  • Field data: medidos em usuários reais (CrUX). É o que o Google usa no ranking.

Se o lab está verde mas o field está vermelho, seus usuários reais têm conexões/dispositivos piores do que o ambiente de teste.

Core Web Vitals e ranking

O impacto no ranking é real, mas modesto. O Google confirmou que CWV é um fator, mas o conteúdo relevante continua sendo o mais importante.

Na prática:

  • CWV não vai salvar conteúdo ruim
  • CWV pode ser o desempate entre duas páginas com conteúdo similar
  • Sites com CWV vermelho em todas as páginas perdem visibilidade gradualmente

Checklist rápido

  • LCP element identificado e otimizado
  • Imagens em WebP/AVIF com dimensões definidas
  • Critical CSS inline, resto assíncrono
  • Fontes com font-display: swap ou optional
  • JavaScript não essencial com defer ou lazy-load
  • Sem layout shifts causados por conteúdo dinâmico
  • Monitoramento via Search Console ativado
Web Performance in Action
Dev R$ 195

Web Performance in Action

Guia prático de performance web com foco em métricas reais e otimização de carregamento.

Ver na Amazon

#anúncio · Link de afiliado Amazon. Ao comprar por este link, você apoia o site sem custo adicional.

Conclusão

Core Web Vitals não são complicados de corrigir — o difícil é manter. Integre testes de performance no CI/CD, monitore o relatório do Search Console semanalmente e priorize correções pelo impacto no field data. Comece pelo LCP: é a métrica com maior impacto percebido pelo usuário.

Gratuito

Gostou deste artigo?

Receba dicas exclusivas de SEO, novas ferramentas e guias toda semana. Sem spam — apenas conteúdo útil.

Sem spam. Cancele quando quiser.