PageSpeed Insights no e-commerce: o que corrigir primeiro

A equipe testa a página inicial da loja e recebe uma nota baixa no celular. A primeira reação é comprimir os banners. Dias depois, a nota sobe, mas a página de produto ainda demora para responder quando o cliente escolhe uma cor. No carrinho, o total muda de posição assim que a cotação de frete aparece. A equipe melhorou o que mediu, mas ainda deixou dois problemas importantes na jornada.

O PageSpeed Insights no e-commerce é mais útil quando ajuda a responder uma pergunta específica: onde a experiência piora, para quem e durante qual tarefa? A nota de desempenho é um ponto de partida. A decisão sobre o que corrigir depende da diferença entre o teste simulado e a experiência observada, da função da página e do comportamento que a equipe consegue reproduzir.

Este guia mostra como ler o relatório, montar uma amostra de páginas e validar correções sem reduzir o trabalho de performance a uma corrida por pontos.

1. O que o PageSpeed Insights mede

Entenda a diferença entre dados de campo e de laboratório

O relatório reúne dois tipos de evidência. Os dados de campo vêm do Chrome User Experience Report, também chamado de CrUX, e agregam experiências reais elegíveis de usuários do Chrome ao longo dos 28 dias anteriores. Os dados de laboratório vêm de um teste do Lighthouse executado em condições simuladas. A nota de desempenho pertence a esse teste. Ela não representa diretamente a experiência de todos os clientes da loja. :chatgpt-content-reference{index=”0”}

Use os dados de campo para entender se há um problema observado em visitas reais. Use o laboratório para investigar causas e comparar versões em condições semelhantes. Uma correção pode aparecer no teste logo depois da publicação, enquanto o resultado de campo ainda reúne visitas anteriores à mudança. Uma diferença entre os dois, portanto, não significa que um deles esteja errado. :chatgpt-content-reference{index=”1”}

Confira se o resultado representa a página ou a origem

Quando a URL consultada não tem dados de campo suficientes, o relatório pode mostrar dados agregados da origem, que reúne páginas com o mesmo protocolo, domínio e porta. Se nem a origem tiver dados suficientes, essa seção pode ficar indisponível. :chatgpt-content-reference{index=”2”}

Imagine uma loja em que a página de uma coleção nova ainda não tem dados próprios. O resultado agregado da origem ajuda a enxergar o cenário geral, mas não comprova que aquela coleção tenha a mesma experiência. Nesse caso, a equipe pode testar a página diretamente, repetir o cenário no celular e, se precisar de mais visibilidade, instrumentar medições próprias. Registre a ausência de dados como uma limitação do diagnóstico.

2. Como traduzir as Core Web Vitals em problemas da loja

O Google usa três métricas para avaliar carregamento, resposta a interações e estabilidade visual. A referência é o percentil 75, ou seja, o valor dentro do qual se encontram 75% das observações elegíveis. A avaliação é separada por tipo de dispositivo. Os valores abaixo são referências técnicas, não previsões de conversão. :chatgpt-content-reference{index=”3”}

Descubra o que atrasou a foto principal

Se a foto é o elemento identificado no LCP, investigue quando o navegador descobriu que precisava carregá-la, quanto tempo levou para baixá-la e quando ela apareceu na tela. Uma imagem pesada pode justificar compressão ou versões por tamanho de tela. Se o download só começa tarde, a equipe precisa investigar como a imagem é inserida e priorizada. Comprimir o arquivo pode ajudar pouco quando o atraso acontece antes mesmo de começar a transferência. :chatgpt-content-reference{index=”4”}

Repita a ação que parece lenta

Para investigar INP, reproduza a tarefa. Abra e feche filtros, altere a quantidade no carrinho ou selecione variantes. Observe se o atraso acontece no primeiro toque, após várias interações ou apenas quando a página ainda está carregando. O teste padrão de carregamento do Lighthouse não executa essa sequência de compra por você. Se a dificuldade aparece durante o uso, registre a interação em um teste próprio e confira onde a interface demora a apresentar o resultado. :chatgpt-content-reference{index=”5”}

Observe o que muda de posição e em qual momento

Para investigar CLS, anote o que entrou na tela antes do deslocamento. Uma faixa promocional pode ocupar um espaço que não estava reservado. Uma imagem pode alterar a altura da galeria ao carregar. Em ambos os casos, a correção precisa preservar o conteúdo e manter a área de interação previsível. No celular, vale conferir se botões, campos e o total do pedido permanecem no lugar enquanto o restante da página carrega.

3. Como escolher as páginas certas para avaliar

Monte uma amostra que represente a compra

Comece por páginas que cumprem funções diferentes: uma entrada relevante de campanha ou busca, uma categoria, uma página de produto e o carrinho. Inclua o checkout no teste de jornada quando tiver acesso ao fluxo e puder usar um ambiente adequado. Páginas que dependem de sessão, login ou produtos no carrinho precisam de testes no navegador com esses estados preparados.

Escolha exemplos que exponham diferenças reais. Uma categoria curta pode funcionar bem, enquanto outra, com mais filtros e produtos, reage lentamente. Uma página com um único item pode carregar de forma diferente de outra com galeria extensa e várias opções. Em um e-commerce B2B, inclua uma conta de teste com preços específicos ou pedidos com muitas linhas, se isso fizer parte da rotina do comprador.

Registre as condições que podem mudar o resultado

Anote a URL, o dispositivo, o estado da sessão, a variante escolhida e os recursos ativos na página. Registre também se o teste simulou uma primeira visita ou se o navegador já tinha arquivos em cache, isto é, guardados de um acesso anterior. Uma campanha, uma mudança de catálogo ou a ativação de uma ferramenta externa pode alterar o que a página carrega.

Repita o teste de laboratório em condições comparáveis. Se os resultados variarem, investigue o que mudou antes de atribuir a diferença à última alteração. E reserve tempo para percorrer a jornada em um celular real: a equipe precisa observar se a pessoa consegue escolher, revisar e concluir a compra com as funções da loja preservadas.

4. O que corrigir primeiro: um exemplo de diagnóstico

Compare o impacto na tarefa com a evidência disponível

Imagine uma loja com três achados: um banner pesado na página inicial, um atraso ao selecionar variantes no celular e um deslocamento no botão do carrinho quando aparece o cálculo de frete. Os três merecem atenção, mas podem ter prioridades diferentes.

Se o deslocamento no carrinho é reproduzível e interfere no avanço da compra, pode ser a primeira correção, mesmo que a nota da home chame mais atenção. Se a maioria das entradas relevantes passa por uma página de campanha cuja imagem principal demora a aparecer, a ordem pode mudar. Considere alcance, efeito na tarefa, confiança no diagnóstico e esforço de correção.

Descubra se o ajuste pode ser feito sem trocar de plataforma

Uma imagem mal dimensionada pode ser corrigida no conteúdo ou na configuração da loja. Um componente que demora a reagir pode exigir trabalho na interface. Se a causa estiver em uma ferramenta externa, identifique o que ela entrega e se precisa carregar naquela etapa. A remoção de um script pode melhorar um teste e, ao mesmo tempo, interromper atendimento, mensuração ou outra função que a operação usa.

Compare as opções com o mesmo cenário de compra. Uma migração faz sentido como pauta quando as restrições da arquitetura ou da plataforma impedem melhorias relevantes e existem outros requisitos que justificam a mudança. Uma nota isolada não mostra onde está a causa nem demonstra que trocar de solução vai eliminá-la.

5. Como validar melhorias e evitar que o problema volte

Defina um critério de aceite ligado ao comportamento

“Melhorar a performance do carrinho” deixa margem para interpretações. Um critério mais claro seria: “Ao concluir a cotação de frete no celular, o botão de avançar permanece estável, o total reflete a opção escolhida e a seleção continua disponível para revisão.”

Compare antes e depois com o mesmo cenário e teste também uma resposta lenta ou indisponível do cálculo. Se a equipe mexeu em um componente compartilhado, verifique outras páginas que o utilizam. O objetivo da homologação é confirmar a melhora e preservar as funções que dependem daquele componente.

Acompanhe a experiência depois da publicação

Use o laboratório para verificar o efeito imediato e os dados de campo para acompanhar a experiência ao longo do tempo, considerando a janela de coleta. Registre a data de publicação para entender quais visitas podem fazer parte da comparação. Se houver alteração de campanha, oferta ou composição do tráfego, leve isso em conta antes de atribuir uma mudança na conversão à performance. :chatgpt-content-reference{index=”6”}

Para evitar que o problema volte, inclua verificações na rotina de publicação. Uma nova campanha pode adicionar imagens grandes; uma integração pode passar a carregar em páginas onde não é necessária. Escolha algumas URLs e tarefas para repetir após mudanças relevantes. Assim, a equipe tem uma referência para identificar regressões, que são pioras em comportamentos que já funcionavam bem.

Conclusão

O que corrigir primeiro depende da página, da tarefa afetada e da qualidade da evidência. Um problema reproduzível na seleção de produtos ou no carrinho pode merecer atenção antes de uma oportunidade genérica na home. Em outra loja, a principal dificuldade pode estar no carregamento da página que recebe a campanha.

Use o PageSpeed Insights para formular a hipótese, reproduza o problema na jornada e defina como comprovar a correção. Uma meta útil é específica o suficiente para a equipe saber o que mudou e reconhecer se o problema voltar.

Se sua loja tem relatórios de desempenho, mas a equipe ainda não sabe quais ajustes priorizar, a FZ Commerce pode ajudar a avaliar páginas e tarefas representativas. Um diagnóstico pode começar com a página que recebe mais tráfego de campanha, um produto com variantes e uma compra pelo celular, para orientar quais mudanças de conteúdo, interface ou desenvolvimento merecem entrar no plano.