Em 2021, o Google consolidou os Core Web Vitals como fator de ranqueamento oficial. A discussão que se seguiu no mercado de SEO focou majoritariamente no impacto orgânico — sites mais lentos perdendo posições para concorrentes mais rápidos. O impacto mais imediato, porém, é anterior ao SEO: é a conversão direta. Um site que demora 4 segundos para carregar não está apenas perdendo posições no Google; está perdendo vendas ativas de usuários que já chegaram ao site e estão tentando comprar.

Para varejistas com operações digitais significativas, entender os Core Web Vitals não é tarefa de equipe técnica — é inteligência de negócio. Cada décimo de segundo de melhoria em LCP (Largest Contentful Paint) tem um valor de receita calculável com os dados do próprio Google Analytics 4.

Os Três Métricas que o Google Mede e o que Significam na Prática

LCP — Largest Contentful Paint

LCP mede o tempo até o maior elemento visível da página ser renderizado — frequentemente a imagem hero de um produto ou o banner principal de uma categoria. A meta do Google é LCP abaixo de 2,5 segundos. Entre 2,5 e 4 segundos é "Needs Improvement". Acima de 4 segundos é "Poor".

Para e-commerce, o elemento de LCP quase sempre é uma imagem. As causas mais comuns de LCP alto em lojas virtuais são: imagens sem otimização de formato (JPEG de 2MB em vez de WebP de 150KB), ausência de atributo loading="eager" na imagem hero (o browser adia o carregamento esperando a ordem de renderização), e CDN não configurado com edge nodes próximos ao Brasil (latência de servidor americano servindo imagem para usuário em Recife pode adicionar 400ms ou mais).

INP — Interaction to Next Paint (substituiu FID em 2024)

INP mede a responsividade da página a interações do usuário: clique em botão "Adicionar ao carrinho", seleção de variante de produto, abertura de modal de detalhes. A meta é INP abaixo de 200 milissegundos. Acima de 500ms é "Poor".

Em e-commerce, INP alto geralmente indica JavaScript excessivo sendo executado na thread principal — analytics scripts, chat widgets, pop-ups de captura de e-mail e scripts de personalização rodando simultaneamente. Cada um desses scripts é legítimo individualmente, mas empilhados na mesma thread bloqueiam a resposta a interações do usuário. O padrão correto é carregamento diferido (defer ou async) para scripts não-críticos e uso de web workers para processamento pesado fora da thread principal.

CLS — Cumulative Layout Shift

CLS mede quanto o layout da página se move inesperadamente durante o carregamento. A meta é CLS abaixo de 0,1. O problema mais frequente em e-commerce é imagens sem dimensões declaradas — o browser reserva zero espaço para uma imagem enquanto ela carrega, depois insere a imagem "empurrando" o conteúdo abaixo dela. Resultado: o usuário está lendo a descrição do produto e o texto pula 200px para baixo quando a imagem carrega.

A correção é simples: sempre declarar width e height em tags <img>, mesmo que o tamanho final seja controlado por CSS. O browser usa essa proporção para reservar espaço antes do carregamento.

O Dado de Receita por Décimo de Segundo

Google e Deloitte publicaram em 2020 um estudo com dados de 37 marcas globais de varejo, quantificando o impacto de velocidade em conversão. Os resultados mais relevantes:

  • Redução de 0,1 segundo no tempo de carregamento mobile → aumento médio de 8,4% em taxa de conversão para sites de varejo
  • Redução de 0,1 segundo no tempo de carregamento mobile → aumento médio de 9,2% no valor médio de pedido

Para colocar em perspectiva: uma loja online com faturamento mensal de R$ 500.000 e LCP de 4 segundos que melhora para 2,5 segundos — uma redução de 1,5 segundo — pode esperar, com base nessa referência, um impacto positivo de 8 a 15% em conversão. Isso é R$ 40.000 a R$ 75.000 mensais adicionais sem nenhum investimento em tráfego, apenas em performance técnica.

Esses números são estimativas baseadas em médias de mercado, não garantias. A única forma de quantificar o impacto real para uma operação específica é medir: antes e depois de cada intervenção de performance, com segmentação adequada no GA4 para isolar o efeito da velocidade de outros fatores.

Imagens: A Variável de Maior Impacto no LCP

Em catálogos de e-commerce de grande porte, imagens de produto representam 60 a 85% do peso total de payload de uma página de produto típica. A otimização de imagens é consequentemente o maior alavancador de LCP disponível sem mudança de arquitetura ou infraestrutura.

O roadmap de otimização de imagens em ordem de impacto:

  1. Formato WebP: WebP oferece compressão 25 a 35% melhor que JPEG com qualidade visual equivalente. Suporte em todos os browsers relevantes desde 2020. A conversão de catálogo existente pode ser automatizada com ferramentas como ImageMagick ou scripts PHP usando a extensão GD.
  2. Lazy loading nativo: loading="lazy" em todas as imagens fora da viewport inicial. Nativo nos browsers modernos, zero JavaScript adicional, reduz o payload inicial da página sem afetar imagens que o usuário vai ver.
  3. Dimensões declaradas: sempre declarar width e height — elimina CLS por imagem.
  4. Preload da imagem hero: <link rel="preload" as="image"> no <head> para a imagem principal da página. Instrui o browser a buscá-la com prioridade máxima antes mesmo de processar o restante do HTML.
  5. CDN com edge no Brasil: a diferença de latência entre um servidor em São Paulo e um em Frankfurt servindo uma imagem para um usuário em Porto Alegre pode ser de 200 a 400ms — o equivalente a toda a compressão que você conseguiria otimizando o arquivo.

JavaScript de Terceiros: O Peso Invisível

Cada script de terceiro carregado em uma loja virtual é uma dependência de performance que você não controla. Scripts de analytics, chat, pixels de conversão, heatmap, otimização de conversão e pop-ups de captura somados facilmente chegam a 500KB a 1MB de JavaScript adicional — frequentemente carregado de forma síncrona, bloqueando a renderização da página até que todos sejam baixados, parseados e executados.

A auditoria de scripts de terceiros deve ser feita trimestralmente: liste todos os scripts carregados, meça o impacto individual de cada um usando o DevTools do Chrome (Performance tab → Third Party Usage), e elimine ou adie todos que não contribuem diretamente para conversão. Um chat que ninguém usa mas que custa 300ms de INP está custando dinheiro — mais do que o custo da licença da ferramenta.

Como Medir: PageSpeed Insights vs. Field Data

PageSpeed Insights e Lighthouse medem Core Web Vitals em condições de laboratório — conexão simulada, hardware simulado. Os dados "reais" de Core Web Vitals — chamados de Field Data ou CrUX (Chrome User Experience Report) — são coletados de usuários reais do Chrome e refletem as condições reais de rede e hardware do seu público.

Para varejistas brasileiros, a diferença é frequentemente significativa: uma fatia considerável do público acessa via 4G em dispositivos Android de gama média, com condições de conexão muito diferentes da conexão de fibra em MacBook que o time de desenvolvimento usa para testar. O CrUX disponível no Google Search Console (relatório de Experiência da Página) é a referência correta para decisões de priorização de otimização.