Site mais lento e queda na taxa de conversão: como achar a mudança que travou as páginas

Um site mais lento pode derrubar a taxa de conversão?

Pode, mas a lentidão só é a causa quando começou antes da queda e atingiu as páginas e os dispositivos onde as conversões caíram. Problema de velocidade raramente vem sozinho: o deploy que deixou as páginas mais pesadas muitas vezes também mudou o layout, o formulário ou o tracking.

A velocidade importa porque quem espera o conteúdo principal aparecer, ou toca num botão e nada acontece, desiste antes de chegar ao checkout ou ao formulário de lead. O Google mede esses momentos com três Core Web Vitals: Largest Contentful Paint (LCP) para o carregamento, Interaction to Next Paint (INP) para a resposta a cliques e toques e Cumulative Layout Shift (CLS) para a estabilidade visual.

Este artigo não promete um número de vendas perdidas por segundo de atraso. Os números publicados variam de site para site e muitas vezes vêm de estudos de fornecedores. O que você pode fazer é mostrar, com os seus dados, que uma mudança datada deixou as páginas mais lentas e que as conversões caíram nas mesmas páginas, no mesmo período. Para o método geral de qualquer queda, veja como explicar uma queda de conversões ao cliente.

Quais mudanças costumam deixar o site mais lento?

A maioria das perdas de velocidade vem de algo que alguém publicou, não do Google nem da hospedagem. Os suspeitos de sempre são scripts novos, mídia mais pesada e deploys de código.

O guia do Google sobre tags explica que o tempo da thread principal é gasto avaliando e executando o JavaScript do gerenciador de tags e das próprias tags, e os autores relatam uma correlação entre contêineres maiores e INP pior. Tags duplicadas, como um pixel fixo no HTML e injetado de novo pelo GTM, pesam sem trazer dado nenhum. Se a suspeita é uma tag, comece pelo histórico de versões do GTM.

Como confirmo que o site realmente ficou mais lento?

Compare os dados de campo de usuários reais antes e depois da mudança suspeita e use testes de laboratório só para achar a causa. Uma nota isolada do Lighthouse não prova nada: o Google avisa que os resultados de laboratório variam entre execuções por causa da rede, do hardware e da disputa por recursos.

O Google avalia cada métrica no percentil 75 das visualizações de página. Três ferramentas resolvem a maioria dos casos:

• PageSpeed Insights mostra dados de campo do Chrome UX Report dos últimos 28 dias, por URL ou, quando a URL não tem dados suficientes, pela origem, além de um teste de laboratório do Lighthouse.
• O relatório Core Web Vitals do Search Console agrupa URLs parecidas e mostra quantas estão boas, precisam de melhoria ou estão ruins nos últimos 28 dias. Grupos sem dados suficientes ficam de fora.
• O seu próprio monitoramento de usuários reais, se você tiver, é a única fonte que mostra um salto diário no dia do deploy.

A janela de 28 dias pesa na hora de datar. Como o PageSpeed Insights agrega os 28 dias anteriores todo dia, uma lentidão que começou numa terça aparece como uma subida gradual nas semanas seguintes, não como um degrau. Leia a data em que a linha começa a curvar e confirme com testes de laboratório da versão antiga e da nova.

Como isolar qual mudança causou a lentidão e a queda?

Coloque numa única linha do tempo todas as mudanças da semana anterior à queda, descarte primeiro o tracking e só então teste a hipótese da velocidade nas páginas que ficaram lentas. Uma queda nas conversões medidas também pode vir de uma tag quebrada, então confirme que a tag de conversão continua disparando na versão nova antes de culpar a velocidade.

1. Anote o dia em que as conversões caíram e onde: checkout no celular, uma landing page ou o site inteiro.
2. Liste todas as mudanças dos 7 a 14 dias anteriores: deploys, atualizações de tema ou plugin, versões do GTM, scripts novos e mudanças de consentimento, além de edições nos anúncios, como lances, orçamentos e URLs finais.
3. Marque quais mudanças mexeram nas páginas que caíram. Um script novo em todas as páginas e uma queda só no checkout mobile apontam para a resposta no celular.
4. Teste a versão antiga e a nova da página em laboratório e procure o script ou o arquivo que mais acrescenta tempo.

Exemplo: uma loja online de móveis pergunta por que as vendas no celular caíram na terça enquanto o desktop se manteve. Ao alinhar as mudanças, aparece uma tag de chat adicionada no GTM na sexta, um vídeo novo de destaque nas páginas de produto no sábado e nenhuma edição nos anúncios. Os testes de laboratório mostram que o vídeo virou o elemento de LCP e carrega bem depois da imagem antiga. A equipe troca o vídeo por uma imagem estática e as vendas mobile voltam na semana seguinte. Nomes e números são ilustrativos.

Com todas as mudanças numa única linha do tempo, você veria que o vídeo entrou no ar três dias antes da queda, no mesmo template em que as vendas mobile caíram. No Changeline você registra cada deploy, tag e mudança de consentimento com data, responsável e motivo, e importa as edições do Google Ads automaticamente, então a lista do passo 2 já existe quando a pergunta chega.

Como provar que foi a lentidão, e não outra coisa, que derrubou as conversões?

Você prova mostrando que três coisas batem: a lentidão começou com a mudança, as conversões caíram só nas páginas e nos dispositivos afetados, e voltaram quando a mudança foi revertida ou corrigida.

1. Confirme que o tracking dispara
2. Date a lentidão nos dados de campo
3. Compare páginas afetadas e as demais
4. Reverta ou corrija a mudança
5. Acompanhe a volta das conversões

• Segmente por dispositivo e página. Se a taxa de conversão no desktop se manteve, a do celular caiu e a lentidão está sobretudo no celular, isso é evidência. Uma queda em todos os dispositivos e páginas aponta para outro lado.
• Confira o mix de tráfego. Uma campanha, um público ou um orçamento novo pode trazer visitantes mais frios no mesmo dia. Veja a taxa de conversão por origem antes de culpar a velocidade. As outras causas estão em por que a taxa de conversão cai.
• Use um controle. As páginas que não receberam o script ou o arquivo novo são o seu grupo de controle. Se elas ficaram estáveis, a mudança é a causa mais provável.
• Reverta e observe. Tirar o script ou desfazer o deploy é o teste mais limpo. Registre a reversão como uma mudança própria, para que a recuperação também fique datada.

Guarde a evidência por escrito: a mudança, a data, as medições de laboratório antes e depois e a taxa de conversão nas páginas afetadas e nas demais. É isso que o cliente ou o gestor vai pedir, e evita que a mesma discussão volte um mês depois.

Como evitar que a lentidão volte?

Inclua a velocidade em todo deploy e em toda tag nova, e mantenha um registro do que entrou no ar e quando. A maioria das regressões volta porque alguém adiciona o script de novo ou ninguém lembra por que ele foi removido.

O Google recomenda pausar ou remover as tags sem uso em vez de bloqueá-las com uma exceção de acionador, porque a tag bloqueada continua carregando o código no contêiner. Um registro de mudanças de marketing compartilhado dá a desenvolvedores e profissionais de marketing uma única fonte para consultar, e o registro de mudanças do site detalha o lado do site.