Core Web Vitals: o que são e como otimizar para SEO

SEO técnico · Performance · Guia atualizado

Um site que demora mais de três segundos para exibir o conteúdo principal perde, em média, mais da metade dos visitantes antes mesmo de eles lerem a primeira frase. Em 24 anos trabalhando com SEO, vi essa conta se repetir em praticamente todo projeto que auditei: o problema quase nunca é falta de conteúdo bom, é o site que não entrega esse conteúdo rápido o suficiente. É exatamente aí que entram os Core Web Vitals — o conjunto de métricas que o Google usa para medir, de forma objetiva, a experiência real de carregamento, interatividade e estabilidade visual de uma página.

Desde que o Google incorporou essas métricas como sinal de ranqueamento, muita gente no mercado de SEO passou a tratar o assunto de forma superficial, citando LCP, INP e CLS em uma lista genérica de “boas práticas” sem nunca explicar como cada uma funciona de verdade, o que causa cada problema e como resolver na prática. Este artigo é diferente: aqui eu vou detalhar cada métrica, mostrar como medi-las corretamente (PageSpeed Insights, Search Console, Lighthouse e CrUX não medem exatamente a mesma coisa, e isso confunde muita gente), e entregar um guia de otimização real — de imagens a CDN, passando por JavaScript, CSS e a escolha de hospedagem.

Se você já leu nosso checklist de SEO técnico e sentiu que a parte de performance ficou rasa, este é o artigo complementar que faltava. Vamos direto ao ponto, com dados de referência reais e sem enrolação.

O que são Core Web Vitals: entendendo LCP, INP e CLS

Core Web Vitals é o conjunto de três métricas criadas pelo Google para quantificar a experiência do usuário em uma página web: velocidade de carregamento do conteúdo principal, capacidade de resposta às interações e estabilidade visual durante o carregamento. Elas substituíram métricas mais antigas e vagas (como “tempo de carregamento total”) por indicadores que refletem o que o usuário efetivamente sente ao navegar.

LCP (Largest Contentful Paint)

O LCP mede quanto tempo leva para o maior elemento visível da tela (geralmente uma imagem de destaque, um vídeo ou um bloco de texto grande) ser renderizado por completo. Na prática, é o momento em que o usuário sente que “a página carregou”. Um LCP de 4 segundos não significa que o site está lento como um todo — significa que a parte mais importante da tela demorou 4 segundos para aparecer, o que já é tempo suficiente para o visitante desistir.

INP (Interaction to Next Paint)

O INP substituiu o antigo FID (First Input Delay) em março de 2024 e mede a responsividade geral da página durante toda a visita, não apenas na primeira interação. Ele calcula o tempo entre um clique, toque ou tecla pressionada e o momento em que o navegador atualiza visualmente a tela em resposta. Um site com JavaScript pesado costuma “travar” justamente aqui: o usuário clica em um botão e nada acontece por meio segundo, o que ele interpreta como site quebrado.

CLS (Cumulative Layout Shift)

O CLS mede o quanto os elementos da página se movem inesperadamente enquanto ela carrega. É aquele clássico problema de clicar em um botão e, no instante seguinte, um banner carregar acima dele e empurrar tudo para baixo — fazendo você clicar em outra coisa sem querer. O CLS é medido em uma pontuação (não em segundos): quanto mais próximo de zero, mais estável é o layout.

Essas três métricas juntas formam o que o Google chama de “sinais de experiência de página” (page experience signals), e são medidas tanto em laboratório (Lighthouse, PageSpeed Insights) quanto em campo, com dados reais de usuários coletados pelo Chrome (CrUX — Chrome User Experience Report). Entender essa diferença é essencial, e eu explico exatamente como cada ferramenta funciona mais adiante, na seção sobre ferramentas de SEO e monitoramento.

Por que o Google usa Core Web Vitals como fator de ranqueamento

O Google introduziu oficialmente os Core Web Vitals como sinal de ranqueamento em 2021, dentro da chamada “Page Experience Update”. A lógica por trás disso é simples de entender, mesmo que a implementação técnica não seja: o objetivo declarado do Google sempre foi entregar a melhor resposta possível para quem pesquisa, e “melhor resposta” não é só o conteúdo mais relevante — é também a página que entrega esse conteúdo sem fricção. Um artigo tecnicamente perfeito, mas que demora 8 segundos para carregar no celular, entrega uma experiência ruim, e o Google passou a penalizar isso de forma mensurável.

Não é o fator mais forte, mas é um fator de desempate real

É importante calibrar a expectativa aqui: Core Web Vitals não é, isoladamente, o critério mais pesado no algoritmo — relevância de conteúdo, autoridade de domínio e correspondência com a intenção de busca continuam pesando mais. Mas em nichos competitivos, onde dezenas de páginas têm qualidade de conteúdo parecida, a performance técnica costuma ser o fator de desempate. Já vi clientes subirem da segunda para a primeira página do Google só depois de resolver o LCP e o CLS, sem tocar em uma linha do conteúdo.

Mobile-first indexing torna isso ainda mais crítico

Desde que o Google passou a indexar praticamente tudo com base na versão mobile do site, a performance em conexões móveis (muitas vezes 4G, não wifi) virou o padrão de avaliação. Isso significa que um site rápido no notebook do escritório pode estar reprovado nos Core Web Vitals quando avaliado como o usuário real o acessa: no celular, em movimento, com conexão instável. Se você ainda não validou isso, veja nosso conteúdo sobre o que é SEO para entender como o mobile-first se encaixa na estratégia geral.

Impacto direto em conversão, não só em ranking

Além do efeito no ranqueamento, existe um efeito comercial direto: estudos amplamente citados no mercado (incluindo dados que o próprio Google publicou) mostram que cada segundo adicional de carregamento reduz taxas de conversão em e-commerce em torno de 7% a 20%, dependendo do setor. Ou seja, mesmo que a página já esteja bem posicionada, um Core Web Vitals ruim significa perder vendas e leads que já chegaram até você. Por isso trato performance como parte da consultoria de SEO desde o primeiro diagnóstico, e não como um item de checklist opcional no fim do projeto.

O que muda com sites em Core Web Vitals “ruim” no Search Console

Quando o Search Console classifica um grupo de URLs como “ruim” nos Core Web Vitals, isso não gera uma penalidade manual — mas reduz a chance dessas páginas aparecerem em posições de destaque, como o carrossel de Top Stories (para sites de notícias) e, em alguns casos, afeta a elegibilidade para certos recursos de rich results. Em resumo: performance ruim não é uma sentença de morte no ranking, mas é um teto que impede o site de competir pelas melhores posições.

Como medir Core Web Vitals: PageSpeed Insights, Search Console, Lighthouse e CrUX

Um erro comum que vejo em auditorias é o cliente testar o site uma única vez no PageSpeed Insights, ver uma nota verde e considerar o assunto encerrado. Cada ferramenta mede algo ligeiramente diferente, e usar só uma dá uma visão incompleta.

Google PageSpeed Insights

É o ponto de partida mais acessível: você cola a URL em pagespeed.web.dev e recebe duas coisas distintas na mesma tela — dados de laboratório (rodados na hora, em um ambiente controlado) e, quando o site tem tráfego suficiente, dados de campo reais vindos do CrUX dos últimos 28 dias. É a diferença entre “como o site se comporta em teste” e “como os usuários reais estão vivendo isso”. Sempre priorize o dado de campo quando ele existir — é o que o Google efetivamente usa para ranqueamento.

Google Search Console — relatório de Core Web Vitals

O Search Console agrupa URLs por padrão de template (não site a site) e classifica cada grupo como Bom, Precisa de melhorias ou Ruim, separado por desktop e mobile. É a ferramenta certa para enxergar o problema em escala: se seu blog tem 300 posts e todos usam o mesmo template, um problema estrutural aparece de uma vez, afetando centenas de URLs simultaneamente — não adianta corrigir só a home.

Lighthouse (Chrome DevTools)

O Lighthouse é a ferramenta de diagnóstico técnico mais detalhada, embutida no próprio Chrome (F12 → aba Lighthouse). Diferente do PageSpeed Insights, ele roda localmente na sua máquina, o que significa que sua conexão de internet e o poder de processamento do seu computador interferem no resultado — por isso duas pessoas testando o mesmo site podem ver números diferentes. Use o Lighthouse para identificar a causa raiz (ele aponta exatamente qual script está travando o INP, qual imagem está causando o LCP alto), não para tirar a nota “oficial” do site.

CrUX (Chrome User Experience Report)

O CrUX é o banco de dados que alimenta os números “reais” do PageSpeed Insights e do Search Console: dados anonimizados coletados de usuários reais do Chrome que visitaram seu site nos últimos 28 dias. É essa a fonte de verdade que o Google usa como sinal de ranqueamento — não o teste isolado do Lighthouse. Sites com pouco tráfego às vezes não têm dados suficientes no CrUX (“Não há dados suficientes”), e nesse caso o Google recorre aos dados do domínio como um todo ou de páginas semelhantes.

Tabela de valores de referência

Métrica	Bom	Precisa melhorar	Ruim
LCP (Largest Contentful Paint)	até 2,5s	2,5s a 4s	acima de 4s
INP (Interaction to Next Paint)	até 200ms	200ms a 500ms	acima de 500ms
CLS (Cumulative Layout Shift)	até 0,1	0,1 a 0,25	acima de 0,25

Esses são os limiares oficiais do Google, medidos no percentil 75 das visitas — ou seja, para o site ser classificado como “Bom”, 75% das visitas precisam ficar dentro da faixa verde, não apenas a média. É comum um site ter LCP médio de 2s mas ainda assim ser classificado como “Precisa melhorar”, porque uma parcela relevante dos acessos (geralmente em 4G ou aparelhos mais fracos) fica acima do limite.

Passo a passo prático para otimizar Core Web Vitals

Depois de centenas de auditorias, percebo que a maioria dos problemas de Core Web Vitals se concentra em cinco frentes. Vou detalhar cada uma com ações concretas, não só teoria.

1. Otimização de imagens

Imagens pesadas são, disparado, a causa número um de LCP ruim. As ações que mais geram resultado: converter para formatos modernos (WebP ou AVIF, que pesam de 25% a 50% menos que JPEG na mesma qualidade visual), dimensionar a imagem no tamanho exato que ela será exibida (nada de subir uma foto de 4000px para exibir em um espaço de 800px), usar loading="lazy" em imagens abaixo da dobra e, principalmente, nunca aplicar lazy loading na imagem que é o elemento do LCP — isso atrasa exatamente o que você está tentando acelerar. Use o atributo fetchpriority="high" na imagem principal para o navegador priorizá-la.

2. JavaScript: o maior vilão do INP

Scripts pesados e mal otimizados são a causa mais comum de INP alto. As ações práticas: eliminar JavaScript não utilizado (muito comum em sites WordPress com plugins acumulados ao longo dos anos), dividir o código em partes menores (code splitting) para que o navegador não precise processar um arquivo gigante de uma vez, adiar (defer) scripts que não são essenciais para a primeira renderização, e evitar bibliotecas de terceiros pesadas (chats, pixels de redes sociais, players de vídeo incorporados) que travam a thread principal do navegador. Se seu site usa muitos plugins, veja se cada um realmente precisa carregar em todas as páginas.

3. CSS: eliminando o que bloqueia a renderização

CSS não utilizado ou mal estruturado atrasa o momento em que o navegador consegue começar a desenhar a página. As ações que funcionam: extrair o CSS crítico (o mínimo necessário para renderizar o que aparece na primeira tela) e inserir isso inline no <head>, carregar o restante do CSS de forma assíncrona, e remover regras não utilizadas com ferramentas como PurgeCSS. Também vale minificar todos os arquivos CSS e combinar arquivos pequenos para reduzir o número de requisições.

4. Hospedagem: a base que muita gente ignora

Não existe otimização de frontend que compense uma hospedagem ruim. Servidor compartilhado barato, com TTFB (Time to First Byte) acima de 600ms, já compromete o LCP antes mesmo do navegador começar a baixar qualquer imagem ou script. Migrar para hospedagem com SSD NVMe, PHP na versão mais recente e recursos dedicados costuma, sozinho, resolver 30% do problema de LCP em sites WordPress mal hospedados. Se você contrata terceiros para cuidar disso, vale entender o que um freelancer de criação de sites pode fazer nessa configuração inicial.

5. CDN (Content Delivery Network)

Uma CDN distribui cópias estáticas do seu site (imagens, CSS, JS) em servidores espalhados pelo mundo, entregando o conteúdo a partir do ponto mais próximo do visitante. Para um site brasileiro com tráfego internacional, isso reduz drasticamente a latência. Cloudflare (com plano gratuito robusto), BunnyCDN e a CDN nativa de hospedagens como a Kinsta são opções comuns. Configure cache de borda agressivo para arquivos estáticos e mantenha HTML dinâmico fora do cache de CDN quando o conteúdo mudar com frequência.

6. Cache do navegador e cache de página

Cache mal configurado obriga o navegador a rebaixar recursos que não mudaram desde a última visita. Configure headers de cache longo (Cache-Control: max-age) para arquivos estáticos versionados, use plugins de cache de página completa (como WP Rocket ou W3 Total Cache no WordPress) para servir HTML pré-gerado em vez de processar PHP a cada visita, e ative compressão Gzip ou Brotli no servidor — Brotli, quando disponível, comprime cerca de 15% a 20% melhor que Gzip para o mesmo conteúdo.

Priorize pelo impacto, não pela facilidade

Se você só tem tempo para atacar um item, comece pela imagem do LCP e pela hospedagem — juntos, costumam resolver a maior parte do problema mais rápido do que qualquer ajuste fino de código. Depois, avance para JavaScript (INP) e só então refine CLS, que costuma exigir ajustes mais pontuais de layout.

Erros comuns que prejudicam a performance do site

Ao longo de auditorias em dezenas de sites brasileiros, alguns erros se repetem com uma frequência que chama atenção. Listo os mais comuns, porque corrigi-los costuma trazer ganho rápido.

Excesso de plugins no WordPress

É comum encontrar sites com 40, 50 plugins ativos, cada um carregando seu próprio CSS e JavaScript em todas as páginas, mesmo quando o recurso só é usado em uma única página específica. Cada plugin extra é uma requisição a mais, um script a mais concorrendo pela thread principal. Faça uma auditoria de plugins pelo menos duas vezes por ano e remova o que não está em uso ativo.

Fontes personalizadas carregadas de forma errada

Fontes do Google Fonts ou customizadas, quando carregadas de forma bloqueante, atrasam a renderização do texto (o famoso “flash de texto invisível”). Use font-display: swap para o navegador exibir uma fonte padrão imediatamente enquanto a fonte real carrega, e pré-carregue (preload) as fontes críticas usadas acima da dobra.

Anúncios e pop-ups sem reserva de espaço

Essa é a causa mais comum de CLS ruim: um espaço de anúncio ou banner de cookies que carrega depois do conteúdo e empurra tudo para baixo. A solução é simples e frequentemente ignorada: reserve o espaço exato (largura e altura) no CSS antes mesmo do elemento carregar, usando aspect-ratio ou dimensões fixas, para que o navegador já saiba quanto espaço alocar.

Vídeos incorporados de terceiros (YouTube, Vimeo)

Embeds de vídeo carregam um iframe pesado, com scripts e CSS do provedor externo, mesmo que o usuário nunca clique em play. Use uma “imagem de capa” leve (facade) que só carrega o player real no clique — isso pode reduzir o peso inicial da página em centenas de kilobytes.

Ignorar a versão mobile

Muita equipe testa e otimiza o site pensando no desktop e depois assume que “no celular deve estar parecido”. Não está. Processadores mais fracos e conexões móveis instáveis tornam o mesmo JavaScript até três vezes mais lento para processar no celular. Sempre teste e otimize pensando primeiro em mobile — é o que o Google avalia por padrão.

Não monitorar depois de corrigir

Resolver o problema uma vez e nunca mais checar é outro erro clássico: um novo plugin, uma nova campanha de anúncios ou uma atualização de tema pode reintroduzir os mesmos problemas meses depois. Trate Core Web Vitals como manutenção contínua, não como projeto de uma vez só — no próximo tópico eu mostro como estruturar esse monitoramento.

Ferramentas e monitoramento contínuo de performance

Otimizar uma vez e esquecer é o erro que descrevi na seção anterior. Para evitar isso, estruturo o monitoramento de Core Web Vitals em três camadas, usando ferramentas diferentes para cada finalidade.

Monitoramento passivo: Google Search Console

Configure o relatório de Core Web Vitals do Search Console para revisão mensal. Ele avisa quando um grupo de URLs muda de status (de “Bom” para “Precisa de melhorias”, por exemplo), o que geralmente indica uma mudança recente no site — nova campanha de anúncios, atualização de tema, plugin novo. É gratuito e já está disponível para qualquer site verificado.

Monitoramento ativo: PageSpeed Insights e Lighthouse CI

Para times técnicos, vale integrar o Lighthouse CI ao processo de deploy: cada vez que uma nova versão do site é publicada, o teste roda automaticamente e bloqueia o deploy se a pontuação cair abaixo de um limite definido. Isso evita que uma alteração de código introduza regressão de performance sem ninguém perceber até o próximo mês.

Real User Monitoring (RUM)

Ferramentas de RUM, como o próprio Google Analytics 4 combinado com a biblioteca web-vitals.js, capturam dados reais de cada visitante em tempo real — não uma amostra de 28 dias como o CrUX. Isso permite identificar problemas específicos de segmento: talvez o site esteja rápido no geral, mas lento especificamente para usuários em determinada operadora de celular ou região do país.

Ferramentas complementares de terceiros

GTmetrix e WebPageTest continuam relevantes para diagnósticos mais profundos, especialmente por permitirem simular localizações geográficas e velocidades de conexão específicas (3G, 4G, cabo). São úteis para validar hipóteses antes de implementar uma mudança em produção. Consulte também nosso guia de ferramentas de SEO para outras opções que uso no dia a dia.

Rotina recomendada de revisão

Na prática, recomendo aos clientes: checagem rápida semanal do PageSpeed Insights nas páginas de maior tráfego, revisão mensal completa do relatório de Core Web Vitals no Search Console, e uma auditoria técnica trimestral mais profunda (a mesma lógica de qualquer auditoria de SEO completa) revisando plugins, scripts de terceiros e configuração de cache do zero.

Perguntas Frequentes

O que são Core Web Vitals?

Core Web Vitals é um conjunto de três métricas do Google — LCP, INP e CLS — que medem a experiência real de carregamento, interatividade e estabilidade visual de uma página. Elas fazem parte dos sinais de ranqueamento desde 2021 e são medidas tanto em laboratório quanto com dados reais de usuários (CrUX).

Qual é o valor ideal de LCP?

O LCP considerado bom é de até 2,5 segundos. Entre 2,5s e 4s o site é classificado como ‘precisa melhorar’, e acima de 4 segundos como ‘ruim’. Esses limiares são medidos no percentil 75 das visitas reais, não na média.

O que é um bom INP?

Um INP de até 200 milissegundos é considerado bom. De 200ms a 500ms o site precisa melhorar, e acima de 500ms é classificado como ruim. O INP substituiu o antigo FID em março de 2024 e mede a responsividade durante toda a visita.

Qual o valor ideal de CLS?

O CLS bom fica até 0,1. De 0,1 a 0,25 o site precisa melhorar, e acima de 0,25 é ruim. Diferente das outras métricas, o CLS não é medido em tempo, mas em uma pontuação de estabilidade visual.

Core Web Vitals é fator de ranqueamento do Google?

Sim, desde a Page Experience Update de 2021. Não é o fator mais forte do algoritmo — relevância de conteúdo e autoridade pesam mais — mas costuma ser decisivo como critério de desempate entre páginas de qualidade parecida, especialmente em nichos competitivos.

Qual a diferença entre PageSpeed Insights e Lighthouse?

O PageSpeed Insights roda na nuvem do Google e mostra tanto dados de laboratório quanto dados reais de campo (CrUX). O Lighthouse roda localmente no seu navegador via Chrome DevTools e serve principalmente para diagnóstico técnico detalhado, já que o resultado varia conforme sua conexão e máquina.

O que é CrUX e por que ele importa?

CrUX (Chrome User Experience Report) é o banco de dados de experiências reais de navegação coletadas anonimamente do Chrome nos últimos 28 dias. É essa a fonte que o Google efetivamente usa como sinal de ranqueamento, não o teste isolado do Lighthouse ou do GTmetrix.

Como o Search Console mostra os Core Web Vitals do meu site?

O Search Console agrupa URLs por template similar (não site inteiro) e classifica cada grupo como Bom, Precisa de melhorias ou Ruim, separando desktop de mobile. Isso ajuda a identificar problemas estruturais que afetam muitas páginas de uma vez.

Imagens grandes prejudicam qual métrica?

Imagens pesadas e mal dimensionadas são a causa mais comum de LCP ruim, já que costumam ser o maior elemento visível da tela. Converter para WebP ou AVIF, dimensionar corretamente e priorizar o carregamento da imagem principal resolve a maior parte dos casos.

JavaScript pesado afeta qual Core Web Vital?

JavaScript excessivo é a principal causa de INP alto, porque scripts pesados travam a thread principal do navegador e atrasam a resposta a cliques e toques. Eliminar código não utilizado e adiar scripts não essenciais costuma trazer o ganho mais rápido nessa métrica.

CDN ajuda a melhorar Core Web Vitals?

Sim. Uma CDN distribui arquivos estáticos (imagens, CSS, JS) em servidores próximos geograficamente do visitante, reduzindo a latência de entrega e, consequentemente, o LCP. Cloudflare e BunnyCDN são opções comuns para sites brasileiros com público nacional e internacional.

Com que frequência devo monitorar Core Web Vitals?

Recomendo checagem semanal no PageSpeed Insights das páginas de maior tráfego, revisão mensal completa no Search Console, e uma auditoria técnica trimestral revisando plugins, scripts de terceiros e cache — já que atualizações no site podem reintroduzir problemas resolvidos anteriormente.

Leia também

• O Que é SEO: guia completo para entender e aplicar
• SEO On-Page: checklist completo de otimização
• Ferramentas de SEO: as que realmente uso depois de 24 anos no mercado
• Auditoria SEO: o que é, o que analisa, quanto custa e como contratar
• Freelancer de SEO Técnico: o que faz, quanto custa e como contratar

Veja também

O que é AEO (Answer Engine Optimization): guia completo

Como Aparecer no ChatGPT e Perplexity: Guia de GEO para Empresas

Schema Markup: Guia Completo de Dados Estruturados para SEO, AEO e GEO