Sintoma no caixa versus causa real na velocidade mobile
O painel das campanhas mostra o volume de tráfego vindo de smartphones subindo, o custo por clique sendo pago no dia, mas a taxa de conversão caindo de forma isolada nos dispositivos móveis. A reação padrão da equipe é trocar o criativo ou alterar a segmentação de público. Na prática, quando o tráfego mobile cresce e a conversão cai enquanto o desktop mantém sua taxa estável, a causa real está no tempo que a CPU do celular leva para processar os arquivos da loja em conexões de rede oscilantes. Entender e ajustar o Core Web Vitals no e-commerce mobile passo a passo é o trabalho de infraestrutura necessário para impedir que a interatividade da página trave e destrua a eficiência dos anúncios.
Testar a loja no computador da empresa conectado ao Wi-Fi cria uma ilusão de velocidade. O computador possui um processador com múltiplos núcleos operando sem limitação de energia, e a rede local entrega latência abaixo de 10 milissegundos. O seu cliente na rua está em um smartphone intermediário com aceleração de hardware limitada pelo aquecimento e pela bateria, navegando sob rede 4G com latência de 80 a 150 milissegundos. O que no desktop carrega em 1,2 segundo exige mais de 6 segundos de processamento na CPU do celular.
Outro erro comum é tomar decisões com base no relatório sintético do PageSpeed Insights. A pontuação em modo laboratório roda em um servidor simulado e não reflete os dados reais de navegação. A prioridade técnica precisa ser pautada no relatório CrUX (Chrome User Experience Report), que coleta a experiência dos usuários reais nos últimos 28 dias no percentil 75 (p75). Se o p75 dos seus visitantes móveis enfrenta atrasos na resposta ao toque, o Google penaliza o custo de aquisição e o comprador abandona a página antes de ver o produto.
Como diagnosticar e corrigir o LCP na imagem da PDP mobile
O Largest Contentful Paint (LCP) mede o tempo necessário para carregar o maior elemento visual visível na viewport do usuário. Em uma página de produto (PDP) mobile, esse elemento é quase sempre a imagem principal do carrossel de fotos. Se a imagem demora mais de 2,5 segundos para ser exibida na tela do celular, o usuário percebe a loja como lenta e interrompe a rolagem.
Para localizar com precisão qual elemento está acionando o LCP, abra a PDP no Google Chrome, acione a ferramenta DevTools (F12) e selecione a aba Performance. Defina a emulação de CPU para "4x slowdown" e a rede para "Fast 3G" ou "4G". Clique em gravar e recarregue a página. No painel de resultados, expanda a seção "Timings" e clique na marcação LCP. O painel destacará exatamente o nó do HTML responsável pelo tempo de renderização final.
Ajuste técnico de tags de imagem e servidor de mídia
Identificada a imagem principal, a correção exige alterar o comportamento com que o navegador prioriza aquele arquivo. O erro mais comum no e-commerce é aplicar a propriedade loading="lazy" em todas as imagens da página por meio de plugins automatizados. Quando o carregamento tardio é aplicado à imagem principal acima da dobra, o navegador adia o download até que todo o DOM seja interpretado, atrasando o LCP em até 1,8 segundo.
Remova o atributo loading="lazy" da primeira imagem da galeria da PDP. Adicione a tag fetchpriority="high" diretamente na tag da imagem ou no precarregamento do cabeçalho HTML:
<link rel="preload" fetchpriority="high" as="image" href="imagem-produto.webp" type="image/webp">
No servidor de mídia ou na CDN, configure a conversão automática para formatos modernos como WebP ou AVIF. Um arquivo JPEG de 800 KB exportado do Photoshop deve ser entregue na resolução nativa da tela do smartphone (geralmente entre 360px e 420px de largura) ocupando menos de 65 KB. Utilize a sintaxe srcset com dimensões explícitas no HTML para evitar que o celular baixe a versão desktop de 2000px de largura.
Redução do INP travado por scripts e aplicativos de terceiros
O Interaction to Next Paint (INP) mede o tempo entre a ação do usuário — um toque na tela — e a resposta visual dada pelo navegador. Desde março de 2024, o INP substituiu oficialmente o FID (First Input Delay) no Core Web Vitals. Em e-commerces, o travamento clássico ocorre no toque do botão "Adicionar ao Carrinho". Se a resposta demora mais de 200 milissegundos, o comprador clica novamente, gera requisições duplicadas ou abandona o checkout.
A causa primária do INP alto no mobile não é o tamanho das imagens, mas o tempo de execução de JavaScript na thread principal do navegador. Quando o usuário clica no botão de compra, a thread principal da CPU do celular está ocupada processando scripts de pixels de anúncios, ferramentas de chat flutuante, gravadores de sessão e aplicativos de recomendação de produtos.
Para mapear os bloqueios:
- Abra o DevTools na aba Performance, ative a limitação de CPU em 4x e inicie a gravação.
- Toque no botão "Adicionar ao Carrinho" e pare a gravação.
- Analise o bloco "Main" no gráfico de execução. As barras marcadas com triângulos vermelhos indicam Long Tasks — tarefas que ocupam a thread principal por mais de 50 milissegundos.
A correção exige uma faxina no Google Tag Manager (GTM). Tags inativas de campanhas encerradas ou ferramentas legadas continuam baixando e executando JavaScript no celular do usuário. Remova todas as tags sem uso. Para os scripts obrigatórios de rastreamento, migre o disparo do lado do cliente (Client-Side) para o lado do servidor (Server-Side GTM e Conversions API da Meta e do Google). Isso remove o processamento de dados do processador do smartphone do cliente e transfere a carga para o servidor.
Ferramentas de suporte ao vivo e widgets de avaliações devem ser carregados de forma assíncrona com atraso atrelado à interação do usuário (scroll ou touchstart), impedindo que esses scripts disputem a CPU no momento em que a página está sendo renderizada.
Eliminação do CLS em banners dinâmicos e cálculo de frete
O Cumulative Layout Shift (CLS) quantifica o impacto de deslocamentos inesperados do conteúdo da tela durante o carregamento. Uma pontuação de CLS acima de 0,1 significa que o cliente tenta clicar em um botão de variação de tamanho ou no botão de compra e, no exato milésimo de segundo do toque, um elemento dinâmico aparece no topo da tela, empurrando o conteúdo para baixo. O resultado é um toque errado.
Em lojas virtuais mobile, os vilões do CLS são os blocos que dependem de requisições assíncronas para definir sua altura:
- O bloco de estrelas de avaliações do produto que carrega via script externo.
- O banner dinâmico de frete grátis ou cupom na parte superior da PDP.
- O simulador de frete e o seletor de parcelamento do meio de pagamento.
A solução técnica consiste em reservar o espaço vertical exato no CSS antes mesmo que o conteúdo do script seja baixado. Defina a propriedade min-height nos contêineres dos aplicativos de frete e avaliações no CSS da loja. Se a caixa do simulador de frete precisa de 120 pixels de altura, a classe CSS correspondente deve possuir min-height: 120px e contain: layout definidos na folha de estilo principal.
Outro fator determinante para o CLS mobile é o carregamento de fontes customizadas da web. Quando uma fonte externa demora a baixar, o navegador exibe primeiro a fonte nativa do sistema e, ao concluir o download, substitui a tipografia. Esse processo altera a altura das linhas do texto e desloca os botões da PDP. Utilize a propriedade font-display: swap no arquivo @font-face e alinhe o tamanho do caractere (size-adjust) para que a fonte do sistema ocupe a mesma área da fonte customizada.
Checklist de auditoria item a item em uma página de produto
Antes de liberar alterações em ambiente de produção, execute a verificação prática dos três pilares do Core Web Vitals simulando o cenário real de um smartphone conectado à rede móvel.
- Passo 1: No DevTools, ative a limitação de rede em 4G e CPU em 4x. Recarregue a PDP e confirme se a marcação do LCP ocorre em até 2,5 segundos, com a imagem do produto principal totalmente visível sem depender de scripts secundários.
- Passo 2: Com a gravação da aba Performance ativa, interaja com as variações de produto (cor e tamanho) e clique no botão de compra. Verifique se o INP permanece abaixo de 200 milissegundos e se nenhuma Long Task ultrapassa 50 milissegundos na thread principal.
- Passo 3: Role a página do topo até o fim da descrição, acionando o calculador de frete e a tabela de parcelamento. Confirme na aba Rendering (ativando a opção "Layout Shift Regions") se o indicador de CLS permanece abaixo de 0,1, sem que nenhum elemento empurre os botões de ação na tela.
Perguntas frequentes
O uso de plataformas SaaS como Shopify ou VTEX impede a correção manual de scripts de terceiros?
Não, mas a estratégia de implementação muda. Nessas plataformas você não edita as configurações de servidor web, mas tem controle total sobre os aplicativos instalados, as chamadas do Google Tag Manager e o código do tema. O excesso de aplicativos instalados via loja de temas injeta dezenas de scripts no cabeçalho da página, sendo necessário remover extensões não utilizadas e consolidar funcionalidades diretamente no código do tema.
Qual a diferença entre medir Core Web Vitals no PageSpeed e no Google Search Console?
O PageSpeed Insights faz simulações instantâneas baseadas no momento da consulta em ambiente sintético de laboratório. Já o relatório do Google Search Console utiliza exclusivamente dados agregados do relatório CrUX, que compila a experiência real de usuários navegando no Chrome nos últimos 28 dias. Para fins de indexação e medição da taxa de conversão real, os dados do Search Console e do CrUX são os únicos que refletem o comportamento de compra da sua base.
O protocolo HTTP/3 traz ganho direto nos índices de LCP no mobile?
Sim, o protocolo HTTP/3 melhora a transferência de dados em conexões móveis instáveis porque utiliza o protocolo QUIC baseado em UDP, reduzindo o tempo de estabelecimento da conexão criptografada. Em redes 4G com perda de pacotes, o HTTP/3 evita que a entrega da imagem principal do produto seja interrompida pelo bloqueio de início de fila comum no HTTP/2 baseado em TCP.