Core Web Vitals: o que são e como melhorar em 2026
Em maio de 2021, o Google oficializou o que muitos já suspeitavam: a experiência técnica da página passou a ser fator de ranqueamento. Os Core Web Vitals — três métricas específicas de performance — se tornaram sinais oficiais do algoritmo, ao lado de HTTPS, mobile-friendliness e ausência de intersticiais intrusivos.
A boa notícia é que a maioria dos sites tem problemas identificáveis e solucionáveis. A má notícia é que poucos sabem exatamente o que cada métrica significa e o que fazer para melhorá-la. Este guia resolve isso com precisão técnica e exemplos práticos.
Em 25 anos de SEO, vi projetos estagnados em posições medíocres não por falta de conteúdo ou backlinks, mas por problemas técnicos de performance que ninguém havia diagnosticado. Core Web Vitals são a forma que o Google encontrou de quantificar e cobrar por esses problemas de forma sistemática.
O que são Core Web Vitals
Core Web Vitals são um conjunto de métricas definidas pelo Google para medir a experiência real do usuário ao carregar e interagir com uma página web. Não são métricas de laboratório — são baseadas em dados reais coletados pelo Chrome dos usuários reais que visitam os sites.
São três métricas, cada uma medindo uma dimensão diferente da experiência:
LCP — Largest Contentful Paint (Renderização do Maior Conteúdo)

Mede o tempo até o maior elemento visível da página — normalmente a imagem hero, um vídeo ou um bloco de texto grande — ser totalmente carregado e exibido na tela. É a métrica que mais se aproxima do que o usuário percebe como “a página carregou”.
- ✅ Bom: abaixo de 2,5 segundos
- ⚠️ Precisa melhorar: entre 2,5 e 4 segundos
- ❌ Ruim: acima de 4 segundos
O elemento LCP mais comum em blogs e sites de conteúdo é a imagem hero do artigo. Em e-commerces, costuma ser a imagem principal do produto ou um banner de destaque.
CLS — Cumulative Layout Shift (Mudança Cumulativa de Layout)
Mede a estabilidade visual da página — quantas vezes e com que intensidade os elementos se movem de posição enquanto a página carrega. Aquele anúncio que aparece do nada e empurra o texto que você estava lendo é CLS alto. Aquela imagem que carrega depois e desloca o botão que você ia clicar é CLS alto.
- ✅ Bom: abaixo de 0,1
- ⚠️ Precisa melhorar: entre 0,1 e 0,25
- ❌ Ruim: acima de 0,25
CLS é calculado como a soma de todos os “layout shift scores” inesperados durante a vida da página. Cada deslocamento de elemento é multiplicado pela fração da viewport afetada e pela distância percorrida.
INP — Interaction to Next Paint (Interação até a Próxima Renderização)

Substituiu o FID (First Input Delay) em março de 2024. Mede quanto tempo a página leva para responder visualmente a qualquer interação do usuário — clique, toque ou pressionamento de tecla — durante toda a visita, não apenas a primeira interação.
- ✅ Bom: abaixo de 200 milissegundos
- ⚠️ Precisa melhorar: entre 200 e 500 ms
- ❌ Ruim: acima de 500 ms
A diferença crítica do INP em relação ao FID: o FID media apenas o atraso do primeiro clique. O INP mede todas as interações ao longo da visita — o que torna muito mais difícil de mascarar com otimizações pontuais.
Por que os Core Web Vitals importam para o SEO
O Google usa dados do Chrome User Experience Report (CrUX) — que coleta métricas reais de usuários reais — para avaliar Core Web Vitals de cada URL. Não é uma avaliação em laboratório. É como seus visitantes reais estão experienciando seu site.
O peso dos Core Web Vitals no algoritmo é real mas não dominante. O Google próprio declarou que conteúdo ótimo com CWV ruins ainda vai superar conteúdo ruim com CWV perfeitos. Mas em nichos competitivos onde conteúdo e autoridade estão equilibrados entre os primeiros resultados, Core Web Vitals é o fator de desempate.
Além do impacto direto no ranqueamento, há o impacto indireto via comportamento do usuário: sites lentos têm taxa de rejeição mais alta, menor tempo de permanência e menor taxa de conversão. Esses sinais de engajamento, por sua vez, influenciam o ranqueamento ao longo do tempo.
Como verificar os Core Web Vitals do seu site
Google PageSpeed Insights
Acesse pagespeed.web.dev, insira a URL e veja os resultados separados para mobile e desktop. O PageSpeed mostra dois conjuntos de dados:
- Field Data (dados de campo): experiência real dos usuários nos últimos 28 dias, coletada pelo Chrome. É o dado que o Google usa para ranqueamento.
- Lab Data (dados de laboratório): simulação em ambiente controlado. Útil para diagnóstico mas não reflete necessariamente a experiência real.
Priorize sempre os Field Data. Se não houver dados de campo suficientes (site com pouco tráfego), o PageSpeed usa dados de sites similares ou apenas os dados de laboratório.
Google Search Console
Em Experiência → Core Web Vitals, você vê o status de todas as páginas do site agrupadas por problema e classificadas como “Boas”, “Precisam melhorar” ou “Ruins”. É a visão mais completa para identificar quais URLs precisam de atenção prioritária e qual métrica específica está com problema.
O Search Console agrupa URLs com problemas similares — então se várias páginas têm o mesmo problema de LCP causado pela mesma imagem hero, aparecem juntas como um grupo para resolver de uma vez.
Chrome DevTools — Lighthouse
Para análise técnica detalhada, o Lighthouse no Chrome DevTools permite diagnosticar exatamente qual elemento está causando o problema, qual script está travando a thread principal e quais recursos estão bloqueando a renderização. Acesse com F12 → aba Lighthouse → Generate report.
Web Vitals Extension
A extensão oficial do Google para Chrome (Web Vitals) mostra as métricas em tempo real enquanto você navega pelo site. Útil para diagnóstico rápido em múltiplas páginas sem precisar abrir o PageSpeed para cada URL.
Como melhorar o LCP — passo a passo
O LCP ruim tem causas bem identificadas e soluções diretas. A sequência de diagnóstico e correção:
1. Otimize a imagem hero
A imagem hero (imagem principal acima da dobra) é a causa número 1 de LCP ruim. O processo correto:
- Formato WebP: 30–50% menor que JPEG/PNG com qualidade equivalente. Use Imagify, ShortPixel ou Squoosh.app para converter
- Dimensões explícitas: defina
widtheheightno atributo HTML da imagem — o navegador reserva o espaço antes de carregar (também evita CLS) - Preload: adicione
<link rel="preload" as="image" href="imagem-hero.webp">no<head>para a imagem da dobra. Instrui o navegador a carregar com prioridade máxima - fetchpriority=”high”: adicione o atributo
fetchpriority="high"diretamente na tag<img>da imagem hero
2. Reduza o TTFB (Time to First Byte)
TTFB alto significa servidor lento — e servidor lento é a raiz de muitos problemas de LCP. Um TTFB acima de 600ms é sinal de hospedagem inadequada.
- CDN: Cloudflare gratuito reduz dramaticamente o TTFB ao servir conteúdo do servidor mais próximo do usuário
- Cache de servidor: WP Rocket, LiteSpeed Cache ou W3 Total Cache no WordPress eliminam o processamento PHP repetido
- Hospedagem adequada: nenhum plugin resolve um servidor fundamentalmente lento. Para TTFB consistentemente abaixo de 200ms, use hospedagem gerenciada (Kinsta, WPEngine, Cloudways) ou VPS bem configurado
3. Elimine CSS que bloqueia renderização
- Inline o CSS crítico (above-the-fold) diretamente no
<head> - Carregue o CSS não-crítico de forma assíncrona com
media="print" onload="this.media='all'" - WP Rocket tem funcionalidade de “Critical Path CSS” que automatiza isso no WordPress
Como melhorar o CLS — passo a passo
1. Defina dimensões em todas as imagens e vídeos
Esta é a correção com maior impacto no CLS. Sem width e height definidos, o navegador não sabe o espaço a reservar antes de carregar — e quando a imagem chega, empurra tudo abaixo. Solução: sempre use width="800" height="450" (ou as dimensões corretas) em cada <img>.
2. Reserve espaço para anúncios e embeds
Anúncios carregados dinamicamente são a segunda maior causa de CLS. Sempre defina um container com altura fixa para onde o anúncio vai aparecer — mesmo antes de carregar. O mesmo vale para iframes de YouTube, Spotify e similares: use o padrão de aspect-ratio no CSS.
3. Pré-carregue fontes web
Fontes que chegam tarde causam FOIT (Flash of Invisible Text) e FOUT (Flash of Unstyled Text) — o texto aparece em fonte fallback e depois muda para a fonte correta, causando deslocamento visual. Use font-display: swap no CSS e adicione preload para as fontes críticas.
4. Evite injetar conteúdo acima do fold dinamicamente
Banners de cookie, notificações e outros elementos inseridos via JavaScript após o carregamento inicial empurram o conteúdo para baixo. Se precisam aparecer, use posição fixa (position: fixed) para que não causem reflow no layout.
Como melhorar o INP — passo a passo
O INP é a métrica mais complexa de corrigir porque depende de como o JavaScript executa em resposta a interações do usuário. Os culpados mais comuns:
1. Identifique os scripts problemáticos
Chrome DevTools → Performance tab → grave uma interação (clique em um botão ou link). Observe as “long tasks” (tarefas acima de 50ms) que aparecem em vermelho. Cada long task bloqueia a thread principal e atrasa a resposta visual.
2. Adie scripts de terceiros não críticos
Scripts de chat ao vivo, pixels de remarketing, widgets de redes sociais e analytics carregando de forma síncrona são os maiores vilões do INP. Use o atributo defer ou async em todos os scripts não críticos. No WordPress, o plugin Perfmatters permite desabilitar scripts específicos por página.
3. Divida tarefas longas em chunks menores
Use setTimeout() ou scheduler.postTask() para quebrar tarefas longas de JavaScript em pedaços menores, liberando a thread principal entre eles para responder a interações do usuário.
4. Use o Google Tag Manager com lazy loading
Centralize todos os scripts de terceiros no GTM e configure triggers de lazy loading — carregue scripts de marketing e analytics apenas quando o usuário scrollar para além da dobra ou após um tempo de inatividade.
Core Web Vitals no WordPress: soluções práticas por problema
WordPress é responsável por grande parte dos sites com CWV ruins — mas também tem as melhores ferramentas disponíveis para corrigi-los sem precisar de código personalizado:
- WP Rocket: melhor plugin all-in-one de performance. Cache de página, minificação de CSS/JS, lazy load de imagens, preload de páginas, delay de JavaScript. Resolve a maioria dos problemas de LCP e INP. ~R$350/ano.
- LiteSpeed Cache: gratuito e excelente para hospedagens com servidor LiteSpeed (Hostinger, por exemplo). Funcionalidades equivalentes ao WP Rocket.
- Imagify ou ShortPixel: compressão e conversão automática para WebP no upload. Imagify tem plano gratuito generoso. Resolve grande parte dos problemas de LCP.
- Cloudflare (gratuito): CDN global que reduz TTFB. A versão gratuita é suficiente para a maioria dos sites.
- GeneratePress ou Astra: temas leves com código limpo. Se o tema atual é pesado, migrar para um desses pode resolver múltiplos problemas de CWV de uma vez.
- Perfmatters: plugin para remover scripts desnecessários página por página. Ideal para resolver INP causado por scripts de terceiros.
Interpretando os dados do PageSpeed Insights corretamente
Um erro comum: ver nota 90+ no desktop e ignorar o mobile. O Google usa mobile-first indexing — o ranqueamento é baseado na versão mobile. Muitos sites têm nota excelente no desktop e nota crítica no mobile. Sempre priorize os dados mobile.
Outro erro: focar no score geral (0-100) em vez das métricas individuais. Um score de 75 pode significar que o LCP está ótimo mas o INP está crítico — e o score agregado esconde esse diagnóstico. Veja sempre as métricas individuais.
E o mais importante: Field Data tem prioridade sobre Lab Data. Se o PageSpeed mostra Lab Data verde mas Field Data vermelho, o Google está vendo vermelho — porque é o Field Data que ele usa para ranqueamento.
Priorização: por onde começar quando tudo está ruim
Se o site tem os três indicadores em vermelho e recursos limitados, esta é a ordem de prioridade por impacto:
- LCP primeiro: é o que o usuário percebe mais imediatamente e tem as correções com maior impacto. Comece pela imagem hero + cache + CDN.
- INP segundo: especialmente se o site tem muitos scripts de terceiros. Um script de chat ou pixel de remarketing carregando de forma inadequada pode estar destruindo o INP sozinho.
- CLS por último: geralmente tem a correção mais simples (dimensões de imagem) mas impacto mais sutil na experiência percebida.
Quer um diagnóstico completo dos Core Web Vitals do seu site? Conheça o serviço de SEO Técnico da AgênciaSEO.

Veja também
- 📖 SEO Técnico: guia completo para iniciantes e avançados (2026)
- 📖 SEO para WordPress: guia completo passo a passo (2026)
- 📖 Os 10 principais fatores de ranqueamento do Google em 2026
Seu site tem problemas de Core Web Vitals? Solicite um diagnóstico técnico gratuito.