Core Web Vitals: o guia completo para melhorar a experiência do usuário e ranquear melhor no Google

Você pode ter o melhor conteúdo do seu nicho. Pode ter backlinks de portais de altíssima autoridade. Pode ter uma estratégia de palavras-chave impecável. E mesmo assim perder posições para um concorrente tecnicamente superior.

Como?

Porque o Google não avalia apenas o que está na sua página. Ele avalia como a pessoa se sente ao acessá-la.

É exatamente isso que os Core Web Vitals medem. E é por isso que ignorá-los é um dos erros mais caros que uma empresa pode cometer em SEO.

Apenas 36% dos sites do mundo atendem simultaneamente aos padrões ideais das três métricas. Isso significa que 64% dos seus concorrentes estão entregando uma experiência ruim ao usuário — e sendo penalizados por isso, mesmo que não percebam.

Este guia vai te mostrar o que são os Core Web Vitals, como cada métrica funciona, como medi-las e como otimizá-las com metodologia real — não com teoria genérica.

O que são Core Web Vitals?

Core Web Vitals são as três métricas essenciais do Google para mensurar a experiência do usuário em páginas web. Elas fazem parte de um conjunto maior chamado Page Experience Signals e funcionam como fatores de classificação diretos — ou seja, influenciam diretamente o ranqueamento orgânico.

As três métricas são:

• LCP (Largest Contentful Paint): velocidade de carregamento
• INP (Interaction to Next Paint): capacidade de resposta a interações
• CLS (Cumulative Layout Shift): estabilidade visual

O que diferencia os Core Web Vitals das dezenas de outras métricas de performance é que eles foram escolhidos especificamente por representar aspectos da experiência que o usuário realmente percebe. Não são métricas técnicas abstratas — são reflexos diretos de como o usuário se sente na sua página.

Pense assim: um usuário que espera a página carregar, tenta clicar num botão e não recebe resposta, ou vê o conteúdo “pulando” na tela enquanto lê — esse usuário vai embora. E o Google sabe disso.

LCP — Largest Contentful Paint

O que mede?

O LCP mede o tempo que leva para o maior elemento visível da página ser completamente carregado. Esse elemento pode ser uma imagem hero, um banner, um bloco de texto grande ou um vídeo — o que for o maior conteúdo acima da dobra (acima do scroll).

Em termos práticos: é o tempo que o usuário espera para ver “a página principal”. É o primeiro impacto visual real.

Quais são os valores de referência?

Por que o LCP é crítico para SEO?

Porque é a primeira coisa que o usuário julga. Pesquisas do Google mostram que a taxa de rejeição aumenta 32% quando o tempo de carregamento vai de 1 para 3 segundos. Acima de 5 segundos, a probabilidade de abandono é 90% maior do que em páginas que carregam em 1 segundo.

Usuário que abandona antes de consumir o conteúdo = sinal negativo para o Google = queda no ranking.

Quais são as principais causas de LCP ruim?

Imagens hero não otimizadas. A causa número um de LCP lento. Uma imagem de 3MB no banner principal vai destruir o LCP de qualquer página, independente de qualquer outra otimização.

Servidor lento (TTFB alto). Se o servidor demora para responder, tudo demora. O TTFB (Time to First Byte) é o ponto de partida do LCP — um servidor lento invalida qualquer otimização de front-end.

CSS e JavaScript bloqueantes. Arquivos CSS e JS que bloqueiam a renderização da página atrasam o carregamento do conteúdo principal mesmo antes de o usuário ver qualquer coisa.

Falta de preload nos recursos críticos. O navegador precisa saber com antecedência quais recursos são prioritários. Sem diretivas de preload, ele descobre a imagem principal tarde demais.

Como melhorar o LCP?

Otimize imagens de forma agressiva.

• Use formatos modernos: WebP para fotografias, AVIF para imagens com alta compressão
• Nunca suba imagens acima de 100KB para elementos above the fold
• Implemente loading="eager" na imagem LCP (o oposto do lazy loading para o elemento principal)
• Adicione fetchpriority="high" na tag <img> do elemento LCP

Implemente preload para o recurso LCP.

<link rel="preload" as="image" href="imagem-principal.webp" fetchpriority="high">

Esse simples código instrui o navegador a carregar a imagem principal antes de qualquer outra coisa.

Melhore o TTFB.

• Use um CDN (Content Delivery Network) para servir conteúdo do servidor mais próximo do usuário
• Implemente cache no servidor — respostas em cache são entregues em milissegundos
• Revise o plano de hospedagem: servidores compartilhados baratos são a causa silenciosa de LCP ruim em muitos sites

Elimine CSS e JS bloqueantes.

• Mova scripts não críticos para o final do <body> ou use o atributo defer
• Remova CSS não utilizado — ferramentas como PurgeCSS ajudam a identificar regras desnecessárias
• Considere inline CSS crítico para o carregamento inicial e carregue o restante de forma assíncrona

INP — Interaction to Next Paint

O que mede?

O INP (Interaction to Next Paint) substituiu o FID (First Input Delay) em março de 2024 e mede o tempo de resposta da página a qualquer interação do usuário ao longo de toda a visita — cliques, toques na tela e pressionamentos de tecla.

Enquanto o FID media apenas a primeira interação, o INP avalia a responsividade geral da página. Se o usuário clica num menu e a página demora 800ms para reagir, esse tempo é capturado pelo INP.

Quais são os valores de referência?

Por que o INP importa mais do que o FID?

O FID era fácil de “passar no teste”. Bastava garantir que a primeira interação fosse rápida. O INP é muito mais honesto — ele captura a experiência real de uso da página.

Um e-commerce que carrega rápido mas trava quando o usuário tenta filtrar produtos, adicionar ao carrinho ou abrir o menu vai ter INP ruim — mesmo que todos os outros sinais estejam bons.

Quais são as principais causas de INP ruim?

Main Thread sobrecarregado. O navegador usa uma única thread principal (Main Thread) para processar JavaScript, renderizar o DOM e responder a interações do usuário. Quando o Main Thread está ocupado executando JavaScript pesado, as interações do usuário ficam na fila — e o INP explode.

Event handlers lentos. Funções JavaScript associadas a cliques e outras interações que executam lógica complexa bloqueiam a resposta da página.

Excesso de JavaScript de terceiros. Scripts de analytics, chat widgets, pixels de rastreamento e ferramentas de personalização competem pelo Main Thread. Cada script adicionado tem um custo — e o custo acumulado pode ser enorme.

DOM muito grande. Páginas com milhares de elementos no DOM são mais lentas para renderizar atualizações, o que impacta diretamente o INP.

Como melhorar o INP?

Reduza o trabalho da Main Thread.

• Identifique tarefas longas (Long Tasks) no Chrome DevTools — qualquer tarefa acima de 50ms é candidata a otimização
• Quebre tarefas longas em partes menores usando setTimeout ou scheduler.yield()
• Adie trabalho não urgente para depois que a interação for processada

Otimize os event handlers.

• Revise as funções JavaScript acionadas por cliques — elas devem fazer o mínimo possível
• Mova lógica pesada para Web Workers, que executam em segundo plano sem bloquear a Main Thread
• Use debounce e throttle em eventos que disparam com frequência (scroll, resize, input)

Audite e reduza scripts de terceiros.

• Faça um inventário de todos os scripts de terceiros carregados na página
• Elimine o que não é essencial — cada script removido libera capacidade da Main Thread
• Para scripts necessários, use async e defer para evitar bloqueio
• Considere carregar scripts de terceiros não críticos somente após a interação do usuário (lazy loading de scripts)

Otimize o tamanho do DOM. O Google recomenda que páginas tenham menos de 1.400 nós no DOM. Páginas com DOM muito grande — comuns em e-commerces com muitos produtos listados — precisam de estratégias de virtualização ou paginação.

CLS — Cumulative Layout Shift

O que mede?

O CLS mede a estabilidade visual da página — o quanto os elementos “pulam” na tela enquanto o conteúdo carrega. Cada vez que um elemento muda de posição inesperadamente, o CLS aumenta.

É a métrica que captura aquela experiência frustrante de estar lendo um artigo e, de repente, um anúncio carrega e empurra todo o texto para baixo — ou pior, você estava prestes a clicar num botão e ele se movia, fazendo você clicar em outra coisa.

Quais são os valores de referência?

Por que o CLS é crítico para conversão?

Porque instabilidade visual gera desconfiança — e desconfiança destrói conversão.

Um usuário que vê a página “pulando” enquanto carrega inconscientemente percebe o site como menos profissional. Em e-commerces, um CLS ruim pode fazer o usuário clicar em “comprar” sem querer — ou perder o clique em “adicionar ao carrinho” porque o botão se moveu.

Quais são as principais causas de CLS ruim?

Imagens sem dimensões declaradas. Quando o navegador não sabe o tamanho de uma imagem antes de carregá-la, ele não reserva o espaço na página. Quando a imagem carrega, ela empurra todo o conteúdo abaixo.

Anúncios e embeds sem espaço reservado. Banners de anúncio que aparecem dinamicamente são a causa mais comum de CLS alto em sites de conteúdo e blogs.

Fontes web com FOUT/FOIT. Quando a fonte customizada carrega depois do texto, pode haver um “salto” visual se o tamanho da fonte alternativa for diferente.

Conteúdo injetado dinamicamente. Popups, banners promocionais, notificações — qualquer elemento que apareça acima de conteúdo existente empurra tudo para baixo e aumenta o CLS.

Como melhorar o CLS?

Sempre declare width e height nas imagens.

<img src="imagem.webp" width="800" height="450" alt="descrição">

Com as dimensões declaradas, o navegador reserva o espaço correto antes de carregar a imagem.

Use aspect-ratio no CSS para elementos responsivos.

img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Reserve espaço para anúncios e embeds. Defina um min-height para o container dos anúncios antes de eles carregarem. Sim, vai aparecer um espaço vazio por um momento — mas é muito menos prejudicial do que um layout instável.

Otimize o carregamento de fontes.

• Use font-display: swap para mostrar o texto imediatamente com fonte alternativa
• Prefira usar font-display: optional para fontes decorativas não críticas
• Faça preload das fontes mais importantes:

<link rel="preload" as="font" href="fonte-principal.woff2" crossorigin>

Evite inserir conteúdo acima do conteúdo existente. Banners e popups devem ser inseridos abaixo do conteúdo ou em overlay (posição fixa/absoluta), nunca empurrando conteúdo para baixo.

Como medir seus Core Web Vitals

Existem duas formas de coletar dados de Core Web Vitals — e é fundamental entender a diferença entre elas:

Dados de Campo (Field Data / CrUX)

São os dados reais coletados pelo Google a partir de usuários reais do Chrome que visitaram o seu site. Esses dados alimentam o Google Search Console e são os que o Google usa para o ranqueamento.

Onde acessar: Google Search Console → Experiência → Core Web Vitals

O relatório mostra a situação real das suas páginas divididas em três grupos: Boas, Precisam melhorar e Ruins. É o ponto de partida de qualquer diagnóstico sério.

Limitação: o CrUX só tem dados de páginas com volume mínimo de visitas. Páginas novas ou com pouco tráfego podem não ter dados de campo disponíveis.

Dados de Laboratório (Lab Data)

São medições feitas em condições simuladas e controladas. Úteis para diagnóstico e desenvolvimento, mas não refletem a experiência real dos usuários.

Principais ferramentas:

• Google PageSpeed Insights — análise gratuita com dados de campo e laboratório combinados
• Lighthouse — auditoria completa integrada ao Chrome DevTools
• WebPageTest — análise avançada com visualização do processo de carregamento
• Chrome DevTools (Performance tab) — para análise profunda de Long Tasks e Main Thread

O fluxo de trabalho recomendado

1. Comece pelo Search Console — identifique quais páginas estão com status “Ruim” ou “Precisa melhorar”
2. Priorize por impacto de negócio — páginas de produto, landing pages e home geralmente têm maior impacto nas conversões
3. Use o PageSpeed Insights para cada página priorizada — ele combina dados de campo e laboratório
4. Vá para o Lighthouse/DevTools para diagnóstico técnico detalhado
5. Implemente as melhorias e monitore — atualizações no CrUX levam 28 dias para refletir no Search Console

Core Web Vitals e conversão: a conexão que a maioria ignora

A maioria das discussões sobre Core Web Vitals foca em SEO e ranqueamento. Mas o impacto mais imediato — e frequentemente maior — é na taxa de conversão.

O Google documentou em seus próprios estudos que:

• Sites que passam nos Core Web Vitals têm 24% menos abandono de página
• Uma melhora de 0,1 segundo no tempo de resposta mobile pode aumentar as conversões em e-commerces em até 8%
• Reduzir o CLS de “ruim” para “bom” está associado a aumento de 15% na taxa de conversão em média

A lógica é simples: uma página rápida, responsiva e estável cria confiança. Confiança converte.

Para uma empresa que fatura R$ 500 mil por mês em e-commerce, um aumento de 8% na taxa de conversão representa R$ 40 mil adicionais — todo mês, de forma recorrente, sem aumentar o investimento em tráfego.

Essa é a matemática que torna os Core Web Vitals um dos investimentos de maior ROI dentro do SEO.

Os erros mais comuns na otimização de Core Web Vitals

Depois de trabalhar com centenas de projetos, identificamos padrões de erros que se repetem:

Otimizar lab data mas ignorar field data. É possível ter notas excelentes no Lighthouse e péssimos dados de campo no Search Console. O Lighthouse simula condições de laboratório com dispositivo e rede controlados. O field data reflete usuários reais, em conexões 3G, com celulares de entrada. Sempre priorize o field data.

Otimizar apenas a home. A home raramente é a página que mais converte. Páginas de produto, landing pages e artigos de blog costumam ter mais impacto nas conversões. Otimize as páginas que importam para o negócio.

Resolver o sintoma sem entender a causa. Comprimir imagens sem entender por que o LCP está alto pode mascarar o problema real (TTFB alto, por exemplo). O diagnóstico precede a correção.

Adicionar scripts de terceiros sem avaliar o custo. Cada novo pixel, widget ou ferramenta de analytics tem um custo para o INP. Avalie o impacto antes de instalar.

Não monitorar após as otimizações. Core Web Vitals mudam com atualizações de plugins, novos scripts, mudanças de template e atualizações de conteúdo. Monitoramento contínuo é parte da estratégia — não é uma etapa que se conclui.

Priorização: por onde começar?

Se você está começando agora, use este framework de priorização:

Passo 1 — Diagnóstico geral Abra o Google Search Console e veja o relatório de Core Web Vitals. Quantas páginas estão no grupo “Ruim”? Qual métrica está reprovando mais?

Passo 2 — Priorize por tráfego e conversão Ordene as páginas problemáticas pelo volume de tráfego orgânico e pela importância para o negócio. Comece pelas que têm mais impacto.

Passo 3 — Identifique a causa raiz Para cada página priorizada, use o PageSpeed Insights e o Lighthouse para entender o que está causando o problema. Não assuma — meça.

Passo 4 — Implemente em ordem de esforço x impacto Otimizações de imagem (formato, compressão, dimensões declaradas) geralmente têm alto impacto e baixo esforço técnico. Comece por elas. Refatorações de JavaScript pesado têm alto impacto mas alto esforço — planeje com mais cuidado.

Passo 5 — Monitore e itere Configure alertas no Search Console e revise o relatório de Core Web Vitals mensalmente. O ambiente muda — seu site também.

Conclusão: velocidade não é detalhe técnico, é estratégia de negócio

Os Core Web Vitals não são uma burocracia técnica imposta pelo Google. Eles são a tradução matemática de algo que qualquer empreendedor já sabe intuitivamente: uma experiência ruim afasta clientes.

Uma página lenta faz o usuário ir embora. Uma página que trava na hora do clique faz o usuário desistir. Uma página com layout instável faz o usuário perder a confiança.

O Google apenas começou a medir isso de forma sistemática — e a usar essa medição como fator de ranqueamento. O que antes era só boa prática virou exigência competitiva.

Com apenas 36% dos sites atendendo aos padrões ideais, cada ponto percentual de melhoria nos seus Core Web Vitals é uma vantagem sobre a maioria dos concorrentes — no ranqueamento e na conversão.

A SEO Extremo trata Core Web Vitals como parte central da estratégia de SEO técnico — não como uma checklist a ser preenchida, mas como uma alavanca de resultado mensurável.