O que são os Core Web Vitals e por que afetam seu ranqueamento
Core Web Vitals são três métricas definidas pelo Google para medir a experiência de carregamento, interatividade e estabilidade visual de uma página. Cada uma captura um aspecto diferente do que o usuário percebe ao navegar.
LCP (Largest Contentful Paint) mede o tempo até o maior elemento visível da página ser renderizado, geralmente uma imagem hero ou um bloco de texto principal. INP (Interaction to Next Paint) substitui o FID desde março de 2024 e registra a latência da pior interação do usuário durante toda a visita, não apenas o primeiro clique. CLS (Cumulative Layout Shift) quantifica o quanto os elementos da página se deslocam de forma inesperada durante o carregamento.
O Google incorporou os CWV como sinal de ranqueamento em junho de 2021, dentro do conjunto de sinais chamado Page Experience. O peso isolado no algoritmo não é divulgado, mas o Google confirma que, em empate de relevância entre duas páginas, a com melhor experiência leva vantagem. Para nichos competitivos com conteúdo muito similar entre concorrentes, isso pode ser decisivo.
Há uma distinção crítica entre dados de campo e dados de laboratório. Dados de campo vêm do Chrome UX Report (CrUX), que coleta métricas reais de usuários Chrome durante 28 dias. Dados de laboratório são gerados por ferramentas como Lighthouse em condições simuladas e controladas. O Google usa os dados de campo (CrUX) para ranqueamento, não os dados do Lighthouse. O Lighthouse é útil para diagnóstico, mas um bom score nele não garante aprovação nos CWV reais.
Os limites de aprovação por métrica são:
- LCP: bom ≤ 2,5s / precisa melhorar até 4,0s / ruim > 4,0s
- INP: bom ≤ 200ms / precisa melhorar até 500ms / ruim > 500ms
- CLS: bom ≤ 0,1 / precisa melhorar até 0,25 / ruim > 0,25
Para que uma URL seja classificada como “boa” no relatório do Search Console, ela precisa passar nas três métricas simultaneamente, medidas no percentil 75 dos usuários reais.
Como medir os Core Web Vitals do seu site
Google Search Console
O relatório de Core Web Vitals no Search Console agrupa URLs por template, não por URL individual. Se um tipo de página, como páginas de produto, tiver problema no LCP, todas as PDPs aparecem agrupadas como “URLs ruins”. Isso é útil para priorizar: em vez de corrigir página por página, você corrige o template inteiro.
Ao clicar em um grupo problemático, o Search Console exibe quais métricas falharam e um exemplo de URL. Use essa URL de exemplo como ponto de partida no PageSpeed Insights para entender o diagnóstico.
PageSpeed Insights
O PageSpeed Insights combina dados de campo do CrUX (quando há volume suficiente) com a auditoria de laboratório do Lighthouse. Olhe primeiro a seção de dados de campo, pois ela reflete o que o Google de fato considera. A seção de auditoria abaixo serve para identificar as causas técnicas.
Se a URL não tiver dados de campo por baixo tráfego, o PSI mostra apenas os dados de laboratório. Nesse caso, você não tem visibilidade real da métrica, e o Search Console provavelmente também não tem dados suficientes para classificar essa URL.
Chrome DevTools e extensão Web Vitals
Para diagnóstico em tempo real durante o desenvolvimento, o Chrome DevTools oferece duas ferramentas principais. A aba Performance grava uma sessão de carregamento e mostra Long Tasks, frames de layout shift e o momento exato em que o LCP é disparado. A aba Lighthouse roda a auditoria de laboratório localmente.
A extensão Web Vitals (disponível na Chrome Web Store) exibe os valores de LCP, INP e CLS diretamente na barra do navegador enquanto você navega, usando dados reais da sessão atual. É a forma mais rápida de replicar a experiência do usuário sem precisar abrir o DevTools.
Páginas com poucos dados de campo no CrUX
Sites com baixo tráfego ou páginas muito específicas frequentemente não têm dados suficientes no CrUX para aparecer no Search Console. A estratégia nesses casos é focar nas páginas de maior volume, como home e categorias principais, para garantir que pelo menos essas URLs sejam classificadas. Para as demais, o Lighthouse e o DevTools são os únicos instrumentos disponíveis.
Como melhorar o LCP
Identificar o elemento LCP
Antes de otimizar, você precisa saber o que está sendo medido. Abra o Chrome DevTools, vá até a aba Performance, grave o carregamento da página e localize o marcador “LCP” na linha de tempo. Clique nele para ver qual elemento foi identificado: pode ser uma imagem hero, um bloco de texto com fundo, um vídeo ou até um elemento com background-image via CSS.
Imagens são o elemento LCP mais comum e também o mais fácil de otimizar. Textos como elemento LCP geralmente indicam que a fonte está atrasando a renderização.
Pré-carregar o recurso LCP
Se o elemento LCP for uma imagem, adicione uma tag <link rel="preload"> no <head> da página para que o browser comece o download antes mesmo de processar o HTML completo:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">Evite aplicar loading="lazy" no elemento LCP. O lazy loading instrui o browser a postergar o download, o que é o oposto do que você quer para o elemento mais importante da página. Use lazy loading apenas em imagens abaixo do fold.
Otimizar imagens
Converta imagens para WebP ou AVIF. AVIF oferece compressão superior ao WebP, mas tem suporte ligeiramente menor em browsers mais antigos — use o elemento <picture> com fallback se necessário. Garanta que as dimensões da imagem no HTML correspondam ao tamanho real de exibição; servir uma imagem de 2000px para um slot de 800px desperdiça banda sem nenhum benefício visual.
Ferramentas como Squoosh, Sharp ou pipelines de build com imagemin permitem automatizar a compressão sem perda perceptível de qualidade.
Reduzir o TTFB
O LCP não pode ser bom se o servidor demora para responder. Um TTFB acima de 800ms já compromete o LCP mesmo que tudo mais esteja otimizado. As alavancas principais são: cache de página no servidor (full-page cache para conteúdo estático), uso de CDN com PoP geograficamente próximo dos usuários e otimização de queries de banco de dados que bloqueiam a geração do HTML.
Eliminar recursos render-blocking
CSS carregado no <head> bloqueia a renderização até ser completamente processado. Scripts síncronos têm o mesmo efeito; JavaScript com defer ou async não bloqueia. Audite o relatório “Eliminate render-blocking resources” no Lighthouse e mova CSS não-crítico para carregamento assíncrono ou inline apenas o CSS acima do fold.
Como melhorar o INP
O que o INP realmente mede
O INP captura a latência entre uma interação do usuário (clique, toque, teclado) e o próximo frame pintado na tela que reflete essa interação. O que torna o INP diferente do FID é que ele considera todas as interações durante a visita, não apenas a primeira. A métrica reportada é o valor do percentil 98 das interações, ou seja, a quase-pior interação registrada.
Uma página pode ter INP ruim mesmo com carregamento rápido se houver scripts pesados executando após o carregamento inicial, bloqueando a thread principal durante a navegação.
Quebrar Long Tasks
Long Tasks são blocos de JavaScript que ocupam a thread principal por mais de 50ms sem pausas. Durante esse tempo, o browser não consegue processar interações do usuário, gerando latência perceptível. A solução é dividir o trabalho em partes menores, cedendo controle ao browser entre cada chunk.
A forma mais compatível é usar setTimeout(fn, 0) para quebrar tarefas em microtarefas separadas. A API scheduler.yield(), disponível no Chrome 115+, oferece uma forma mais explícita e semântica de fazer isso:
async function processItems(items) {
for (const item of items) {
processItem(item);
await scheduler.yield(); // cede controle ao browser
}
}Auditar scripts de terceiros
Tag managers, widgets de chat, pixels de rastreamento e scripts de A/B testing são as fontes mais comuns de Long Tasks em sites de e-commerce e marketing. Cada script adicional que executa no main thread compete com as interações do usuário.
Use a aba Performance do DevTools com a opção “Third-party badges” ativada para identificar quais scripts de terceiros geram mais Long Tasks. Avalie se cada script é realmente necessário e se pode ser carregado de forma diferida ou movido para um Web Worker.
Web Workers para lógica pesada
Web Workers executam JavaScript em uma thread separada, sem bloquear a thread principal. São ideais para processamento de dados, cálculos complexos e parsing de grandes payloads JSON. A limitação é que Workers não têm acesso ao DOM: a comunicação com a thread principal acontece via mensagens assíncronas.
Evitar forced reflow em event handlers
Forced reflow ocorre quando JavaScript lê propriedades de layout (como offsetHeight, getBoundingClientRect()) após ter modificado o DOM, forçando o browser a recalcular o layout de forma síncrona. Dentro de event handlers isso pode ser devastador para o INP. O padrão correto é fazer todas as leituras de layout antes de qualquer escrita no DOM, nunca intercalando leitura e escrita em loop.
Como melhorar o CLS
Reservar espaço para imagens e iframes
A causa mais comum de CLS é imagens e iframes sem dimensões explícitas. Quando o browser não sabe o tamanho de um elemento antes de carregá-lo, ele redimensiona o layout ao receber o recurso, deslocando o conteúdo abaixo. A correção é simples: sempre defina width e height no HTML ou use aspect-ratio no CSS.
img {
width: 100%;
aspect-ratio: 16 / 9;
height: auto;
}Evitar inserção dinâmica de conteúdo acima do fold
Banners de cookies, notificações de push, barras de promoção e anúncios inseridos dinamicamente no topo da página são vilões frequentes do CLS. Se o espaço não for reservado antes do carregamento, qualquer inserção empurra o conteúdo existente para baixo.
A solução é reservar o espaço no layout antes mesmo de o conteúdo dinâmico ser carregado. Para anúncios, use dimensões fixas no container. Para banners opcionais, considere sobrepor o conteúdo (posição fixa ou sticky) em vez de empurrar o fluxo.
Fontes web e FOUT
Quando uma fonte web demora para carregar, o browser exibe o texto com uma fonte de fallback e depois troca para a fonte correta. Esse evento de troca causa layout shift se as fontes tiverem métricas diferentes. Use font-display: optional para que o browser use apenas a fonte se ela já estiver em cache, evitando a troca. Se a fonte precisa sempre aparecer, font-display: swap minimiza o tempo de invisibilidade, mas ainda pode gerar shift.
Para fontes críticas, adicione <link rel="preload"> no <head> para reduzir a probabilidade de troca tardia. Ajuste também as métricas de fallback com as propriedades CSS size-adjust, ascent-override e descent-override para que a fonte de fallback ocupe o mesmo espaço visual que a fonte final.
Diagnosticar shifts com DevTools
Na aba Performance do DevTools, grave o carregamento da página e filtre por “Layout Shift” na linha de tempo. Clique em um evento de shift para ver qual elemento se moveu, de onde para onde e qual foi o gatilho, geralmente uma imagem carregando, um script inserindo DOM ou uma fonte sendo trocada. Essa informação é suficiente para direcionar a correção sem precisar fazer suposições.
Priorizando melhorias: por onde começar no contexto brasileiro
Ordenar por impacto de tráfego
Comece pelas páginas com maior volume de visitas, pois são exatamente as que alimentam o CrUX com mais dados. Para e-commerces, a ordem típica é: página de categoria, página de produto (PDP), home e busca. Para portais de conteúdo, artigos de alto tráfego orgânico vêm primeiro. O Search Console agrupa por template, o que facilita essa priorização: um template de PDP corrigido resolve centenas ou milhares de URLs de uma vez.
Infraestrutura no Brasil
Hospedagens compartilhadas populares no Brasil frequentemente têm TTFB elevado (acima de 1s), o que sozinho já inviabiliza um LCP bom. A prioridade nesses casos é avaliar a migração para VPS, cloud ou plataformas com CDN integrada que tenham PoPs no Brasil. São Paulo costuma ser o PoP mais relevante para a maioria do tráfego nacional.
CDNs como Cloudflare, Fastly e Amazon CloudFront possuem presença no Brasil. Mesmo sem trocar a hospedagem de origem, colocar uma CDN na frente pode reduzir o TTFB para usuários brasileiros de forma significativa, especialmente para ativos estáticos.
CWV é um esforço multidisciplinar
Melhorar Core Web Vitals raramente é tarefa exclusiva do time de SEO. LCP envolve back-end (TTFB, cache), front-end (imagens, preload, render-blocking) e infraestrutura (CDN, servidor). INP envolve desenvolvimento JavaScript e revisão de scripts de terceiros com impacto direto em produto e marketing. CLS envolve design (definição de dimensões de componentes) e conteúdo (inserção de banners e elementos dinâmicos).
Estruture um backlog técnico de CWV com tickets claros por área de responsabilidade. Cada melhoria deve ter a métrica afetada, a página alvo, a estimativa de impacto e o responsável técnico definidos.
Monitoramento contínuo
Core Web Vitals não são uma otimização pontual. Novos deploys, adição de scripts de terceiros, mudanças de layout e atualizações de plugins podem regredir métricas que estavam aprovadas. Configure alertas no Search Console para ser notificado quando URLs passam para o status “precisa melhorar” ou “ruim”.
Estabeleça uma rotina de revisão mensal: verifique o relatório de CWV no Search Console, correlacione com deploys recentes usando o histórico de versões e priorize correções antes que a regressão acumule 28 dias de dados negativos no CrUX.
Como avaliar seu ponto de partida
Antes de executar qualquer otimização, faça um diagnóstico estruturado seguindo esta sequência:
- Acesse o relatório de Core Web Vitals no Google Search Console e identifique os grupos de URLs com status “ruim” e “precisa melhorar”.
- Pegue a URL de exemplo de cada grupo problemático e analise no PageSpeed Insights: olhe primeiro os dados de campo, depois as auditorias de laboratório.
- Para cada métrica com problema, use o Chrome DevTools (aba Performance) para identificar o elemento ou script responsável.
- Classifique os problemas encontrados por tipo (LCP, INP, CLS), por template afetado e por volume de tráfego impactado.
- Monte um backlog priorizado com os responsáveis técnicos de cada área (back-end, front-end, infra, design) e defina revisões mensais após cada ciclo de correções.
Com esse processo, você transforma dados fragmentados em ações específicas com dono definido, que é o que separa sites que melhoram seus CWV daqueles que ficam rodando testes de Lighthouse sem sair do lugar.
