Performance técnica não é detalhe, é pré-requisito. Reduzir o LCP de 3.8 segundos para 1.2 segundos num projeto de migração de e-commerce foi parte essencial de um crescimento de 810% em receita orgânica — não porque o Google “premia” site rápido, mas porque performance ruim é teto baixo pra qualquer estratégia de conteúdo. Esse dado sozinho já contraria boa parte do que se fala por aí sobre Core Web Vitals ser “só mais um detalhe técnico”.
Você já deve ter lido a definição de Core Web Vitals uma dezena de vezes: três métricas, limites recomendados, ferramenta de teste. O que a maioria dos guias não mostra é o que acontece quando você realmente corrige isso num site real, com tráfego real e receita real em jogo.
Depois de 23 anos em SEO, aprendi que Core Web Vitals é uma das áreas onde a distância entre “saber o conceito” e “ter corrigido isso na prática” é enorme. Se você quer isso resolvido com rigor no seu site, veja como estruturo projetos de SEO técnico.
As 3 métricas de Core Web Vitals, sem o jargão de manual
Antes de falar em correção, vale entender o que cada métrica realmente mede — sem o jargão de manual.
LCP: Largest Contentful Paint
Mede o tempo até o maior elemento visual da página (geralmente uma imagem ou bloco de texto) terminar de carregar. O limite recomendado pelo Google é 2.5 segundos. No projeto de migração que já mencionei em outros artigos aqui do blog, o LCP começou em 3.8 segundos — bem acima do aceitável, e diretamente limitando conversão antes mesmo de qualquer discussão sobre conteúdo.
Em e-commerce, o elemento que costuma determinar o LCP é a imagem principal do produto ou do banner de destaque — por isso otimização de imagem tende a ser o primeiro ponto de ataque em qualquer correção de LCP alto.
INP: Interaction to Next Paint
Substituiu o antigo FID (First Input Delay) como métrica oficial em 2024. Mede o tempo de resposta da página a qualquer interação do usuário — clique, toque, tecla. Página que trava ou demora pra reagir a um clique, mesmo que carregue rápido inicialmente, é penalizada aqui.
Essa mudança de FID pra INP foi significativa porque o FID só media a primeira interação da visita. INP avalia interações ao longo de toda a sessão, dando um retrato muito mais realista da experiência do usuário durante todo o tempo que ele passa na página.
Páginas com muito JavaScript rodando em segundo plano — carrosséis complexos, animações pesadas, múltiplos scripts de rastreamento — tendem a apresentar INP ruim, mesmo que o carregamento inicial pareça rápido. É um problema que só aparece quando o usuário realmente interage com a página, o que torna a métrica particularmente relevante pra sites com muita interatividade, como e-commerce com filtros dinâmicos.
CLS: Cumulative Layout Shift
Mede o quanto os elementos da página “pulam” durante o carregamento — aquele efeito irritante de clicar num botão e, no último segundo, um banner carregar e empurrar o botão pra outro lugar. CLS alto é comum em sites com anúncios ou imagens sem dimensão definida no código.
A correção mais simples pra CLS é sempre declarar largura e altura explícitas em imagens e vídeos no código, reservando o espaço antes mesmo do elemento carregar completamente — assim o layout não precisa se reorganizar depois que o conteúdo aparece.
Outra causa comum de CLS alto é a inserção dinâmica de conteúdo acima do que o usuário já está lendo — banners de cookie, avisos promocionais ou widgets de chat que aparecem de repente e empurram todo o resto da página pra baixo. Reservar espaço fixo pra esses elementos, mesmo antes deles carregarem, evita esse tipo de deslocamento.
O case real: LCP de 3.8s para 1.2s
O projeto era uma marca de beleza migrando pra VTEX, com tráfego orgânico estagnado. A auditoria inicial revelou um LCP de 3.8 segundos — quase 1.3 segundos acima do limite recomendado. Esse número, sozinho, já explicava boa parte da estagnação de conversão que o cliente relatava antes mesmo de olharmos pra qualquer outro aspecto do site.
O que causava o LCP alto
Imagens de produto sem compressão adequada, carregadas em resolução total mesmo em thumbnails pequenos. Scripts de terceiros (chat, analytics, pixels de remarketing) bloqueando a renderização antes do conteúdo principal aparecer. Ausência de CDN configurada corretamente para ativos estáticos.
Esse tipo de diagnóstico costuma revelar mais de um problema simultâneo — raramente existe uma única causa isolada de LCP alto. É a soma de vários pequenos problemas técnicos, cada um contribuindo alguns décimos de segundo, que resulta no tempo final ruim.
O que corrigimos, em ordem de prioridade
Primeiro, compressão e redimensionamento de imagens em WebP, com lazy loading correto para imagens fora da primeira dobra. Depois, CDN bem configurada pra ativos estáticos. Por último, revisão de scripts de terceiros, removendo o que não gerava valor real e adiando carregamento do que não era crítico pra primeira renderização.
O resultado: 3.8s para 1.2s
Essa redução de mais de 68% no LCP, combinada com outras correções técnicas, ajudou a puxar o crescimento de 810% em receita orgânica que já detalhei no case completo de SEO para e-commerce. Performance não foi o único fator, mas foi pré-requisito indispensável pra tudo o resto funcionar.
O que mais me chamou atenção nesse projeto específico foi a velocidade com que o resultado apareceu depois da correção técnica — as métricas de Core Web Vitals melhoraram no Search Console em poucas semanas, bem antes do crescimento de receita orgânica se consolidar totalmente. Isso confirma o padrão que costumo explicar pros clientes: performance é fundação, e fundação sólida sustenta crescimento que vem depois.
Core Web Vitals é fator de ranking? A resposta completa
Core Web Vitals é um sinal de ranking oficial do Google desde 2021, mas o impacto real é mais indireto do que a maioria imagina. Entender essa nuance evita tanto o exagero de quem trata performance como prioridade única, quanto o descuido de quem acha que não importa nada.
Não é o fator que “decide” o ranking sozinho
Assim como schema markup, Core Web Vitals não substitui qualidade de conteúdo ou autoridade — é um fator entre centenas que compõem a decisão final do algoritmo. Um site com conteúdo excelente e performance mediana pode ranquear melhor que um site rápido com conteúdo raso.
Isso não significa que performance não importa — significa que ela funciona como pré-requisito, não como diferencial isolado. Dois sites com conteúdo equivalente, o mais rápido tende a levar vantagem; mas performance sozinha nunca compensa conteúdo fraco.
O impacto real costuma vir da conversão, não do ranking
Na minha experiência, o ganho mais consistente de melhorar Core Web Vitals aparece na taxa de conversão, não necessariamente numa posição de ranking isolada. Usuário que espera menos, converte mais — isso é válido independente de qualquer decisão do algoritmo do Google.
Teto baixo pra qualquer outra estratégia
Performance ruim é teto baixo, não importa quão bom seja o seu conteúdo. Você pode ter o melhor artigo do nicho, mas se a página demora 5 segundos pra carregar, uma parcela significativa de visitantes abandona antes mesmo de ler a primeira frase.
Estudos amplamente divulgados no setor mostram que a taxa de abandono cresce de forma acentuada a cada segundo adicional de carregamento — o que significa que mesmo pequenas melhorias de performance podem representar ganho real de audiência que nunca chegou a ler o conteúdo, simplesmente porque desistiu antes da página aparecer.
Os fatores que mais prejudicam Core Web Vitals
Depois de auditar sites de portes diferentes, alguns fatores se repetem como principais responsáveis por métricas ruins.
Imagens não otimizadas
Esse é, disparado, o problema mais comum que encontro. Imagens em resolução total, sem compressão, sem formato moderno (WebP ou AVIF) e sem lazy loading adequado. Corrigir isso sozinho já resolve boa parte dos casos de LCP alto.
Um erro específico que vejo com frequência: imagem de produto com 3000 pixels de largura, sendo exibida numa thumbnail de 300 pixels no layout. O navegador baixa o arquivo inteiro mesmo assim, desperdiçando banda e tempo que poderiam ser evitados com o dimensionamento correto no servidor.
Scripts de terceiros excessivos
Cada pixel de rastreamento, chat ao vivo, ferramenta de heatmap ou widget de review adiciona peso e pode bloquear renderização. Vale sempre perguntar: esse script realmente traz valor proporcional ao custo de performance que ele impõe?
Uma auditoria simples de scripts de terceiros, listando cada um e seu impacto medido em milissegundos de atraso, costuma revelar que boa parte deles poderia ser removida ou carregada de forma assíncrona sem prejuízo real pro negócio.
Hospedagem inadequada pro volume de tráfego
Hospedagem compartilhada de baixo custo, tentando servir um site com tráfego significativo, é uma causa recorrente de tempo de resposta de servidor ruim — que afeta diretamente o LCP, já que nada carrega rápido se o servidor demora pra responder a requisição inicial.
O sintoma clássico é performance boa em horários de baixo tráfego e degradação visível em picos de acesso — sinal claro de que o servidor está no limite da capacidade contratada. Migrar pra uma hospedagem com recurso dedicado, ou pelo menos com melhor gerenciamento de carga, costuma resolver esse tipo de problema de forma definitiva.
CSS e JavaScript não otimizados
Arquivos de CSS e JS grandes, não minificados, carregados de forma bloqueante, atrasam a renderização da página inteira. Priorizar o carregamento apenas do que é crítico pra primeira renderização, adiando o resto, costuma gerar ganho significativo.
Uma técnica que aplico com frequência é o “code splitting” — dividir o código em pedaços menores carregados sob demanda, em vez de baixar o arquivo inteiro de uma vez só. Isso reduz drasticamente o peso inicial que o navegador precisa processar antes de mostrar qualquer conteúdo pro usuário.
Como medir Core Web Vitals corretamente
Antes de corrigir qualquer coisa, é preciso medir corretamente — e aqui já vejo confusão comum entre ferramentas.
Search Console: dados reais de usuários (CrUX)
O relatório de Core Web Vitals no Search Console usa dados reais de usuários que visitaram seu site (Chrome User Experience Report). É a fonte mais confiável pra saber como o Google está avaliando sua performance de verdade, porque reflete experiência real, não simulação.
Um detalhe importante: esse relatório exige volume mínimo de tráfego pra gerar dado — sites muito pequenos podem não ter dado suficiente no CrUX, e nesse caso as ferramentas de laboratório se tornam a única fonte disponível, mesmo com suas limitações.
Os dados do CrUX são agregados dos últimos 28 dias de navegação real de usuários que usam o Chrome com sincronização ativada e compartilhamento de dados de uso habilitado. Isso significa que o relatório reflete uma amostra representativa, mas não necessariamente 100% de todos os visitantes do site.
PageSpeed Insights: laboratório + campo
Combina dados de campo (CrUX, quando disponível) com teste de laboratório (simulação controlada). Útil pra diagnóstico rápido, mas o dado de laboratório pode diferir do que usuários reais experimentam, especialmente em conexões mais lentas.
Uma vantagem prática do PageSpeed Insights é que ele já sugere, diretamente no relatório, quais otimizações específicas trariam maior ganho — imagens pra comprimir, scripts pra adiar, recursos pra pré-carregar. É um bom ponto de partida antes de investigar mais a fundo com outras ferramentas.
Lighthouse: só laboratório
Ferramenta de teste totalmente simulada, sem dado real de usuário. Excelente pra debugar problemas específicos durante desenvolvimento, mas não deveria ser a única fonte de verdade sobre performance real do site em produção.
Uso o Lighthouse principalmente durante o processo de desenvolvimento e testes, antes de qualquer mudança ir pro ar — é rápido, roda direto no navegador, e permite iterar sobre correções sem esperar dado real de usuário se acumular ao longo de semanas.
Por que os números variam entre ferramentas
É comum ver resultado diferente entre PageSpeed Insights e Search Console pra mesma página — isso acontece porque um é simulação e o outro é dado real agregado de usuários reais, com toda a variação de dispositivo, conexão e localização que isso implica.
Erros comuns que vejo em otimização de Core Web Vitals
Depois de auditar dezenas de contas, alguns erros de abordagem se repetem com frequência.
Otimizar só a homepage
Muita gente audita e corrige só a página inicial, ignorando páginas de produto, categoria ou artigo — que geralmente são as que recebem mais tráfego orgânico real vindo da busca.
Em e-commerce, isso é ainda mais crítico: a homepage costuma receber uma fração pequena do tráfego total comparado às páginas de produto e categoria, que são exatamente onde a decisão de compra acontece.
Recomendo sempre auditar uma amostra representativa das páginas de maior tráfego, não só a homepage — pegando pelo menos uma página de cada template diferente do site (produto, categoria, artigo de blog, página institucional), já que cada template pode ter performance completamente distinta dependendo de quantos elementos carrega.
Confiar só em teste de laboratório
Um resultado bom no Lighthouse não garante experiência real boa pro usuário — sempre valide também com dados de campo do Search Console antes de considerar o problema resolvido. Já vi mais de uma página com nota alta no Lighthouse e métricas ruins no CrUX, justamente porque a simulação de laboratório não reflete condições reais de rede e dispositivo dos visitantes.
Ignorar o impacto de scripts de terceiros
Focar só em otimizar imagens e código próprio, esquecendo que ferramentas de terceiros (chat, analytics, pixels) frequentemente são o maior peso de performance no site. Já vi caso onde um único widget de chat, mal configurado, era responsável por mais atraso de carregamento do que todas as imagens da página somadas.
Tratar como projeto único, não como manutenção contínua
Corrigir performance uma vez e nunca mais revisar é receita pra regressão — nova funcionalidade, novo plugin ou nova imagem sem otimização podem deteriorar métricas que já estavam boas. Recomendo revisão trimestral, no mínimo, como parte da rotina de manutenção técnica contínua do site.
Como aplicar isso no seu site, passo a passo
Reunindo tudo em um processo prático, na ordem que costumo aplicar.
1. Meça o estado atual no Search Console
Comece pelo relatório de Core Web Vitals, que usa dados reais de usuário — é o ponto de partida mais confiável pra saber onde você realmente está. Sem esse diagnóstico inicial, qualquer correção vira tentativa e erro sem direção clara. Anote as três URLs com pior desempenho reportadas pra usar como referência ao longo de todo o processo de correção.
2. Priorize as páginas de maior tráfego
Corrija primeiro as páginas que recebem mais visita orgânica, não necessariamente a homepage. É ali que o ganho de conversão será mais significativo. Use o relatório de páginas do Google Analytics cruzado com o relatório de Core Web Vitals do Search Console pra identificar rapidamente onde o esforço de correção vai gerar o maior retorno.
3. Otimize imagens primeiro
Compressão, formato moderno (WebP) e lazy loading correto resolvem a maior parte dos casos de LCP alto com esforço relativamente baixo. Ferramentas de compressão automática, integradas ao CMS ou plataforma, tornam essa etapa simples de manter mesmo sem conhecimento técnico avançado.
4. Audite scripts de terceiros
Remova o que não gera valor real e adie o carregamento do que não é crítico pra primeira renderização. Documente cada script removido e monitore métricas de negócio depois da remoção, pra garantir que nenhuma funcionalidade importante foi perdida no processo.
5. Valide com PageSpeed Insights e Lighthouse
Use as ferramentas de laboratório pra confirmar melhorias antes de considerar a correção concluída, mas sempre volte ao Search Console pra confirmar com dado real depois.
Conclusão
Performance técnica não é detalhe, é pré-requisito. Depois de reduzir o LCP de 3.8 segundos para 1.2 segundos num projeto real, e ver isso contribuir diretamente pra um crescimento de 810% em receita orgânica, minha convicção é simples: Core Web Vitals não é teoria de manual — é trabalho técnico que sustenta qualquer outra estratégia de conteúdo.
Não existe atalho aqui. Site lento é teto baixo, não importa quão bom seja o resto da estratégia. Investir em performance técnica sólida é investir na base que permite que tudo o mais funcione.
Se você quer Core Web Vitals corrigido com rigor no seu site, converse comigo sobre SEO técnico completo.
Perguntas Frequentes
Core Web Vitals realmente afeta o ranking no Google?
Não sozinho. Core Web Vitals é um sinal de ranking oficial desde 2021, mas é um fator entre centenas. Um site com conteúdo excelente e performance mediana pode ranquear melhor que um site rápido com conteúdo raso. O impacto mais consistente costuma aparecer na taxa de conversão.
Qual a diferença entre LCP, INP e CLS?
LCP (Largest Contentful Paint) mede o tempo até o maior elemento visível carregar, com limite recomendado de 2.5 segundos. INP mede tempo de resposta a interações do usuário. CLS mede o quanto os elementos da página se movem durante o carregamento.
Qual ferramenta usar para medir Core Web Vitals?
O Search Console usa dados reais de usuários (CrUX) que visitaram seu site, refletindo experiência real. PageSpeed Insights e Lighthouse usam total ou parcialmente simulação de laboratório, útil para diagnóstico mas nem sempre igual à experiência real do usuário.
O que mais causa problema de Core Web Vitals?
Imagens não otimizadas (sem compressão ou formato moderno), scripts de terceiros excessivos, hospedagem inadequada para o volume de tráfego e CSS/JavaScript não otimizados são as causas mais comuns encontradas em auditorias.
Como corrigir um LCP alto na prática?
Reduzir o LCP de 3.8 segundos para 1.2 segundos, através de compressão de imagens, CDN e revisão de scripts de terceiros, foi parte essencial de um crescimento de 810% em receita orgânica em um projeto real de migração de e-commerce.
O que substituiu o FID nas métricas do Google?
INP substituiu o antigo FID (First Input Delay) como métrica oficial do Google em 2024, medindo de forma mais abrangente o tempo de resposta da página a qualquer interação do usuário, não apenas a primeira.
