Em 2020, o Google anunciou que um conjunto de métricas de experiência do usuário se tornaria fator oficial de ranqueamento em 2021. A decisão gerou mais debate no mercado de SEO do que qualquer atualização de algoritmo da década anterior: afinal, pela primeira vez o Google estava dizendo explicitamente que a qualidade da experiência de carregar uma página seria avaliada e usada para decidir posições.
Essas métricas têm nome: Core Web Vitals.
Trabalho com SEO desde 1997. Vi muitas atualizações de algoritmo e muitas promessas de “o fator de ranqueamento definitivo”. Core Web Vitals é diferente por uma razão simples: não é subjetivo. São métricas objetivas, mensuráveis, com thresholds claros definidos pelo Google. Você pode medir exatamente onde está e quanto precisa melhorar.
Neste guia completo vou explicar o que são Core Web Vitals, como funcionam as três métricas principais, os thresholds que o Google usa, as causas mais comuns de falha e as otimizações com maior impacto.
O que são Core Web Vitals
Core Web Vitals são um conjunto de métricas específicas que o Google usa para avaliar a experiência do usuário ao carregar uma página web. Fazem parte de um conjunto mais amplo de sinais de experiência de página (Page Experience Signals) que incluem também compatibilidade mobile, HTTPS e ausência de interstitials intrusivos.
As três métricas Core Web Vitals são:
- LCP — Largest Contentful Paint: velocidade de carregamento do conteúdo principal
- INP — Interaction to Next Paint: responsividade a interações do usuário
- CLS — Cumulative Layout Shift: estabilidade visual durante o carregamento
Cada métrica tem thresholds que definem três zonas de avaliação:
- 🟢 Bom: A página oferece boa experiência
- 🟡 Precisa melhorar: A experiência pode ser melhorada
- 🔴 Ruim: A experiência é insatisfatória
Para que o Google considere um site com “boa experiência de página”, pelo menos 75% das visitas devem estar na zona “Bom” para cada métrica Core Web Vitals.
LCP — Largest Contentful Paint
O LCP (Largest Contentful Paint) mede o tempo desde que o usuário inicia o carregamento da página até que o maior elemento de conteúdo visível na área visível (viewport) seja completamente renderizado.
Thresholds:
- 🟢 Bom: abaixo de 2,5 segundos
- 🟡 Precisa melhorar: 2,5 a 4,0 segundos
- 🔴 Ruim: acima de 4,0 segundos
O elemento LCP é tipicamente a imagem de destaque (hero image) ou o maior bloco de texto visível na parte superior da página. Identificar qual elemento é o LCP é o primeiro passo — você pode ver isso no relatório do PageSpeed Insights, que destaca o elemento.
Causas comuns de LCP lento
Imagens grandes sem otimização: A causa mais frequente. Uma imagem de 3MB como hero image garante LCP ruim em qualquer dispositivo mobile. Solução: WebP, compressão sem perda de qualidade visual, dimensionamento correto para cada breakpoint via srcset.
TTFB alto (Time to First Byte): Se o servidor demora para começar a responder, o LCP vai ser impactado independentemente de qualquer outra otimização. Causas: hospedagem compartilhada lenta, banco de dados sem cache, ausência de CDN. Solução: cache de servidor (WP Rocket, Redis), CDN (Cloudflare), upgrade de hospedagem.
Render-blocking resources: CSS e JavaScript que bloqueiam a renderização da página antes que o elemento LCP seja exibido. Solução: CSS crítico inline no <head>, scripts não-críticos com defer ou async.
Lazy loading no elemento LCP: Um erro clássico — aplicar lazy loading na imagem que é o elemento LCP. O lazy loading adia o carregamento de imagens abaixo do fold, mas a imagem principal acima do fold deve ser carregada imediatamente. Adicione fetchpriority="high" ao elemento LCP para garantir que seja priorizado.
INP — Interaction to Next Paint
O INP (Interaction to Next Paint) substituiu o FID (First Input Delay) como métrica de responsividade em março de 2024. Enquanto o FID media apenas o primeiro clique na página, o INP mede a latência de todas as interações durante toda a sessão do usuário — toques, cliques e entradas de teclado.
Thresholds:
- 🟢 Bom: abaixo de 200ms
- 🟡 Precisa melhorar: 200ms a 500ms
- 🔴 Ruim: acima de 500ms
Um INP ruim significa que quando o usuário clica em um botão, toca em um link ou digita em um campo, a página demora para responder visualmente. No mobile, essa latência é percebida como a página “travada” — uma das piores experiências possíveis.
Causas comuns de INP ruim
JavaScript pesado na thread principal: A causa raiz mais comum. Scripts que bloqueiam a thread principal do browser impedem que as interações do usuário sejam processadas rapidamente. Solução: quebrar tarefas longas de JavaScript em chunks menores, usar Web Workers para processamento intensivo, diferir scripts não-críticos.
Múltiplos scripts de terceiros: Pixels de rastreamento, scripts de chat, widgets de redes sociais, ferramentas de heatmap — cada um adiciona JavaScript que compete pela thread principal. Audite quais são realmente necessários e carregue os não-críticos de forma assíncrona.
React/Vue/Angular com renderização lenta: Frameworks JavaScript modernos podem causar INP ruim quando a hidratação do componente acontece durante uma interação do usuário. Técnicas como hydration diferida e code splitting ajudam.
CLS — Cumulative Layout Shift
O CLS (Cumulative Layout Shift) mede a estabilidade visual da página durante o carregamento. Um CLS alto significa que elementos na tela estão “pulando” enquanto a página carrega — causando cliques acidentais e experiência frustrante.
Thresholds:
- 🟢 Bom: abaixo de 0,1
- 🟡 Precisa melhorar: 0,1 a 0,25
- 🔴 Ruim: acima de 0,25
O CLS é calculado como o produto da fração de área impactada pelo deslocamento e a distância do deslocamento. Múltiplos shifts pequenos se acumulam no score total.
Causas comuns de CLS alto
Imagens sem dimensões definidas no HTML: A causa mais comum. Quando o browser não sabe o tamanho de uma imagem antes de carregá-la, ele não reserva o espaço — e quando a imagem carrega, empurra todo o conteúdo abaixo. Solução: sempre defina width e height nos elementos <img>, ou use CSS com aspect-ratio.
Anúncios e embeds sem espaço reservado: Banners que aparecem depois do carregamento inicial empurram o conteúdo para baixo. Solução: reserve espaço fixo para anúncios mesmo antes de carregarem, usando um container com dimensões mínimas definidas.
Fontes web que trocam (FOUT/FOIT): Quando uma fonte web carrega e substitui a fonte fallback, o texto pode mudar de tamanho e causar shift. Solução: use font-display: optional ou font-display: swap com fonte fallback de métricas similares, ou pré-carregue as fontes críticas com <link rel="preload">.
Banners de cookies e notificações: Pop-ups que aparecem depois do carregamento inicial e empurram o conteúdo causam CLS. Solução: exiba esses elementos em posição fixa (fixed) que não afeta o layout do documento.
Como Medir Core Web Vitals
Existem duas fontes de dados para Core Web Vitals — e a distinção é crítica:
Dados de Campo (Field Data)
Dados reais coletados de usuários reais visitando o site, via Chrome User Experience Report (CrUX). São os dados que o Google usa efetivamente para ranqueamento. Disponíveis em:
- Google Search Console — Relatório de Experiência na Página: Visão geral de Core Web Vitals por URL e por dispositivo. A forma mais direta de ver quantas URLs estão “Boas”, “Precisam melhorar” ou “Ruins”.
- PageSpeed Insights: Seção “Dados de campo” mostra os valores reais de CrUX para a URL específica.
- Chrome UX Dashboard (Looker Studio): Para análise histórica e por segmento de dispositivo.
Dados de Laboratório (Lab Data)
Simulações em condições controladas. Úteis para diagnóstico e desenvolvimento mas não refletem a experiência real dos usuários. Disponíveis em:
- PageSpeed Insights — Seção de laboratório: Simula o carregamento em condições definidas (mobile 4G, desktop).
- Lighthouse (Chrome DevTools): Análise detalhada com sugestões específicas de otimização.
- WebPageTest: Testes mais avançados com múltiplas localizações, dispositivos e condições de rede.
Um erro comum: focar apenas nos dados de laboratório. Uma URL pode ter ótimos dados de laboratório e dados de campo ruins — porque os laboratórios simulam condições ideais enquanto usuários reais têm dispositivos lentos, conexões instáveis e scripts de terceiros que não aparecem nas simulações.
Core Web Vitals no WordPress: otimizações práticas
Para sites WordPress — a plataforma mais comum nos projetos que gerencio — estas são as configurações com maior impacto nos Core Web Vitals:
Cache e Compressão
WP Rocket é o plugin de cache com maior impacto positivo nos Core Web Vitals que conheço. Oferece: cache de página, minificação de CSS/JS, lazy loading de imagens, carregamento diferido de JavaScript e pré-conexão a domínios críticos. Uma configuração adequada do WP Rocket resolve a maioria dos problemas de LCP e INP em WordPress.
Alternativas gratuitas: W3 Total Cache (mais complexo) e LiteSpeed Cache (apenas para servidores LiteSpeed).
Otimização de Imagens
Plugins como Imagify, ShortPixel ou Smush convertem automaticamente para WebP e comprimem imagens no upload. Configure para comprimir imagens existentes também, não apenas novas uploads.
Para o elemento LCP (geralmente a imagem destaque do post), adicione o atributo fetchpriority="high" no HTML da imagem para garantir que seja priorizada no carregamento.
CDN
Cloudflare (plano gratuito já disponível) reduz o TTFB ao servir assets estáticos de servidores geograficamente próximos ao usuário. Para sites com audiência no Brasil, configurar o Cloudflare com cache agressivo para assets estáticos é uma das otimizações com maior impacto no LCP.
Auditoria de Plugins
Cada plugin ativo em WordPress adiciona JavaScript e CSS. Plugins de construtores de página (Elementor, Divi, WPBakery) são conhecidos por adicionar muito código desnecessário. Use o Query Monitor ou o Chrome DevTools para identificar quais plugins estão adicionando mais JavaScript à thread principal — e questione se cada um é realmente necessário.
Core Web Vitals e o Impacto no Ranqueamento
Uma pergunta recorrente: Core Web Vitals realmente impactam o ranqueamento de forma significativa?
A resposta honesta, baseada em dados e experiência: sim, mas como tiebreaker entre páginas com qualidade de conteúdo similar. O Google deixou claro que conteúdo excelente com Core Web Vitals ruins ainda vai superar conteúdo ruim com Core Web Vitals perfeitos.
O impacto real é maior em dois cenários: keywords muito competitivas onde múltiplas páginas têm conteúdo de alta qualidade similar (aqui os Core Web Vitals podem ser o diferenciador), e em mobile especialmente, onde os thresholds são mais difíceis de atingir e o Google dá mais peso à experiência mobile por causa do mobile-first indexing.
Além do ranqueamento, Core Web Vitals têm impacto direto em métricas de negócio — taxa de rejeição, tempo de sessão, taxa de conversão. Pesquisas do Google mostram correlação entre melhorias de Core Web Vitals e aumento de conversões em e-commerces. Para SEO de e-commerce, otimizar Core Web Vitals é tanto SEO quanto CRO simultaneamente.
Em auditorias de SEO, verificar Core Web Vitals via Search Console é uma das primeiras etapas — antes de recomendar qualquer outra otimização on-page ou off-page.
Perguntas Frequentes sobre Core Web Vitals
O que são Core Web Vitals?
São três métricas de experiência do usuário que o Google usa como fator de ranqueamento: LCP (velocidade de carregamento do conteúdo principal), INP (responsividade a interações) e CLS (estabilidade visual). Cada uma tem thresholds definidos que classificam as páginas em Bom, Precisa melhorar ou Ruim.
Quais são as métricas Core Web Vitals e seus thresholds?
LCP (Largest Contentful Paint): Bom abaixo de 2,5s, Ruim acima de 4,0s. INP (Interaction to Next Paint): Bom abaixo de 200ms, Ruim acima de 500ms. CLS (Cumulative Layout Shift): Bom abaixo de 0,1, Ruim acima de 0,25. Para aprovação, pelo menos 75% das visitas precisam estar na zona Bom para cada métrica.
Core Web Vitals afetam diretamente o ranqueamento?
Sim, são fator oficial de ranqueamento desde 2021. O impacto é maior como tiebreaker entre páginas de qualidade similar. Conteúdo excelente com Core Web Vitals ruins ainda supera conteúdo ruim com métricas perfeitas. Mas em keywords competitivas onde o conteúdo é comparável, Core Web Vitals podem ser o diferenciador.
Qual a diferença entre dados de campo e dados de laboratório?
Dados de campo são coletados de usuários reais via Chrome UX Report e são os usados pelo Google para ranqueamento. Dados de laboratório são simulações em condições controladas, úteis para diagnóstico mas não refletem a experiência real. Uma URL pode ter ótimos dados de laboratório e dados de campo ruins.
Como melhorar o LCP?
As principais ações são: converter imagens para WebP e comprimi-las, reduzir o TTFB com cache de servidor e CDN, eliminar render-blocking resources com CSS inline e scripts com defer, e adicionar fetchpriority=”high” ao elemento LCP para priorizá-lo no carregamento.
Por que o CLS é alto no meu site?
As causas mais comuns são imagens sem dimensões definidas no HTML, anúncios e embeds sem espaço reservado, fontes web que trocam durante o carregamento e banners de cookies que deslocam o conteúdo. Definir width e height em todas as imagens é a correção com maior impacto na maioria dos casos.
Core Web Vitals são medidos no mobile ou no desktop?
Ambos, separadamente. O Google Search Console mostra dados separados para mobile e desktop. Os thresholds são os mesmos, mas atingi-los no mobile é significativamente mais difícil por causa da menor capacidade de processamento e conexões variáveis. Como o Google usa mobile-first indexing, os dados mobile têm maior impacto no ranqueamento.
📚 Veja também
- 📱 Mobile SEO: como otimizar seu site para celular e ranquear no Google — como Core Web Vitals se conectam ao mobile-first indexing e ao ranqueamento mobile
- 🔍 Auditoria de SEO: o que é e como fazer passo a passo — como incluir Core Web Vitals na análise técnica completa do site
- ⚡ Crawl Budget: o que é e como otimizar para o Google — como velocidade e performance técnica impactam o orçamento de rastreamento
