Core Web Vitals: O Que São e Como Melhorar

O que são Core Web Vitals e por que você deveria se importar

Core Web Vitals são um conjunto de métricas do Google que medem a experiência real do usuário no seu site. Desde junho de 2021, são fatores diretos de ranking, o que significa que afetam sua posição nos resultados de busca.

Em termos práticos: dois sites com conteúdo de qualidade similar — o que tem Core Web Vitals melhores tende a rankear acima. E não é uma diferença marginal. Análises do Searchmetrics mostram que sites na primeira posição do Google tem, em média, Core Web Vitals 30% melhores que sites na décima posição.

Em 2026, existem 3 Core Web Vitals oficiais. Vou detalhar cada um, incluindo como medir, o que causa problemas e como corrigir.

LCP (Largest Contentful Paint): velocidade percebida

O que é

LCP mede o tempo que o maior elemento visível da viewport leva para renderizar completamente. É a métrica mais próxima de "quanto tempo o usuário sente que a página demorou para carregar".

O elemento LCP pode ser:

• Uma imagem (img, image dentro de svg, poster de vídeo)
• Um bloco de texto (h1, p, div com texto)
• Um background-image carregado via CSS

Metas

• Bom: até 2.5 segundos
• Precisa melhorar: 2.5 a 4 segundos
• Ruim: acima de 4 segundos

Causas mais comuns de LCP alto

1. Imagens grandes não otimizadas: Uma imagem hero de 2MB é o vilão número 1. Solução: converta para WebP, comprima e use srcset para servir tamanhos adequados por device.
2. Servidor lento (TTFB alto): Se o servidor demora para responder, tudo mais atrasa. Solução: use CDN, otimize queries do banco e considere edge computing.
3. CSS render-blocking: Folhas de estilo grandes bloqueiam o render até serem completamente baixadas e parseadas. Solução: inline CSS crítico, carregue o resto de forma assíncrona.
4. JavaScript bloqueando o main thread: Scripts pesados competem com o render. Solução: use defer/async, faça code splitting e elimine JS não utilizado.
5. Fontes web lentas: Fontes customizadas podem bloquear a renderização de texto. Solução: use font-display: swap e preload a fonte principal.

Como melhorar LCP: ações práticas

• Identifique o elemento LCP da sua página (use Chrome DevTools > Performance)
• Se for imagem: converta para WebP, comprima para menos de 200KB, adicione preload
• Se for texto: garanta que a fonte renderize em menos de 100ms (font-display: swap)
• Reduza TTFB para menos de 600ms com CDN e cache
• Inline CSS crítico no head e carregue o resto de forma assíncrona

INP (Interaction to Next Paint): responsividade

O que é

INP substituiu o FID (First Input Delay) em março de 2024 como Core Web Vital oficial. Enquanto o FID media apenas a primeira interação, o INP mede a latência de todas as interações durante toda a visita do usuário.

Para cada interação (clique, tap, tecla pressionada), o INP mede o tempo entre a ação do usuário e a próxima pintura visual na tela. O valor reportado é o pior caso (P98 das interações).

Metas

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

Causas mais comuns de INP alto

1. Long tasks no main thread: Qualquer task de JavaScript que leve mais de 50ms bloqueia o main thread e atrasa a resposta a interações. Solução: quebre tarefas longas com setTimeout, requestIdleCallback ou scheduler.yield().
2. Event handlers pesados: Lógica complexa executada em onclick, onscroll ou onkeydown. Solução: use debounce/throttle, mova lógica pesada para Web Workers.
3. Re-renders excessivos: Em frameworks como React, re-renders desnecessários causam work no main thread. Solução: use React.memo, useMemo, useCallback e evite prop drilling.
4. Layout thrashing: Ler e escrever no DOM alternadamente força recálculos de layout. Solução: batch reads e writes separadamente.

Como melhorar INP: ações práticas

• Use Chrome DevTools > Performance para identificar long tasks
• Quebre tarefas com mais de 50ms usando yield points
• Implemente debounce em scroll handlers e resize handlers
• Mova computações pesadas para Web Workers
• Reduza a complexidade de re-renders no seu framework frontend

CLS (Cumulative Layout Shift): estabilidade visual

O que é

CLS mede a soma de todos os layout shifts inesperados que ocorrem durante a vida útil da página. Um layout shift acontece quando um elemento visível muda de posição de um frame para o próximo sem que o usuário tenha interagido.

Sabe quando você está lendo um texto e de repente ele pula porque um banner carregou acima? Isso é um layout shift. E é uma das experiências mais frustrantes na web.

Metas

• Bom: até 0.1
• Precisa melhorar: 0.1 a 0.25
• Ruim: acima de 0.25

Causas mais comuns de CLS alto

1. Imagens sem dimensões: Quando uma imagem não tem width e height definidos, o navegador não sabe quanto espaço reservar e o conteúdo pula quando a imagem carrega. Solução: sempre defina width e height em <img> tags.
2. Ads e embeds dinâmicos: Banners de ads que carregam tardiamente empurram o conteúdo. Solução: reserve espaço fixo para áreas de ads com CSS (min-height).
3. Fontes web causando FOUT: Quando a fonte web carrega e substitui a fonte fallback, o texto pode mudar de tamanho. Solução: use font-display: optional ou size-adjust para igualar as métricas.
4. Conteúdo injetado dinamicamente: Banners de cookies, notificações e barras de aviso que empurram o conteúdo. Solução: use overlays (position: fixed/absolute) em vez de inserir no fluxo do documento.
5. CSS carregado tardiamente: Estilos que chegam após o render inicial podem reestilizar elementos e causar shifts. Solução: inline CSS crítico e evite importações CSS tardias.

Como melhorar CLS: ações práticas

• Adicione width e height a todas as imagens e vídeos
• Reserve espaço para ads e embeds com containers de tamanho fixo
• Use font-display: swap com size-adjust para minimizar font swap shifts
• Notificações e banners devem ser overlays, não inseridos no fluxo
• Carregue CSS crítico inline e evite @import em folhas de estilo

Como medir Core Web Vitals do seu site

Existem duas categorias de dados:

Dados de lab (sintéticos)

Testes em ambiente controlado. Úteis para debugging, mas não refletem a experiência real dos usuários.

• Lighthouse: Integrado ao Chrome DevTools (F12 > Lighthouse)
• PageSpeed Insights: Versão web do Lighthouse com dados de campo quando disponíveis
• WebPageTest: Testes avançados com diferentes devices e conexões

Dados de campo (reais)

Métricas coletadas de usuários reais do seu site. São os dados que o Google usa para ranking.

• Chrome UX Report (CrUX): Dados agregados de usuários do Chrome (via PageSpeed Insights ou BigQuery)
• Google Search Console: Relatório de Core Web Vitals com dados reais
• web-vitals.js: Biblioteca JavaScript para coletar métricas diretamente no seu site

Diagnóstico rápido com IA

Se você quer um diagnóstico rápido que vá além de números e te diga exatamente o que corrigir e em qual ordem, o EscaneAI tem um agente de Performance Técnica que analisa Core Web Vitals junto com outros fatores de performance, gerando recomendações priorizadas por impacto.

A vantagem é que o EscaneAI correlaciona problemas de performance com impacto em SEO e conversão, mostrando não apenas o número, mas o custo real de cada problema em termos de tráfego e receita perdidos.

Resumo: seu plano de ação para Core Web Vitals

1. Meça: Use PageSpeed Insights para ver seus scores atuais (lab + field)
2. Identifique: Qual métrica está pior? LCP, INP ou CLS?
3. Priorize: Corrija primeiro a métrica que está na faixa "ruim"
4. Implemente: Use as ações práticas listadas acima para cada métrica
5. Monitore: Verifique os resultados semanalmente no Search Console

Analise seus Core Web Vitals gratuitamente e receba um plano de ação personalizado em 30 segundos.