Site mais lento e quebra na taxa de conversão: como encontrar a alteração responsável

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

Pode, mas a lentidão só é a causa quando começou antes da quebra e afetou as páginas e os dispositivos onde as conversões caíram. Os problemas de velocidade raramente chegam sozinhos: a publicação que tornou as páginas mais pesadas muitas vezes também mudou o layout, o formulário ou o tracking.

A velocidade conta porque quem espera pelo conteúdo principal, ou toca num botão e não vê resposta, sai antes de chegar ao checkout ou ao formulário de contacto. A 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 valores publicados variam de site para site e muitas vezes vêm de estudos de fornecedores. O que é possível é mostrar, com dados próprios, que uma alteração datada tornou 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 quebra, consulte como explicar uma quebra de conversões ao cliente.

Que alterações costumam tornar um site mais lento?

A maior parte das perdas de velocidade vem de algo que alguém publicou, não da Google nem do alojamento. Os suspeitos habituais são scripts novos, ficheiros multimédia mais pesados e publicações de código.

O guia da Google sobre etiquetas explica que o tempo da thread principal é gasto a avaliar e executar o JavaScript do gestor de etiquetas e das próprias etiquetas, e os autores referem uma correlação entre contentores maiores e um INP pior. Etiquetas duplicadas, como um píxel fixo no HTML e injetado outra vez pelo GTM, pesam sem acrescentar dados. Se a suspeita for uma etiqueta, comece pelo histórico de versões do GTM.

Como confirmar que o site ficou mesmo mais lento?

Compare os dados de campo de utilizadores reais antes e depois da alteração suspeita e use testes de laboratório apenas para encontrar a causa. Uma pontuação isolada do Lighthouse não é prova: a Google avisa que os resultados de laboratório variam entre execuções devido à rede, ao hardware e à disputa de recursos.

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

• PageSpeed Insights mostra dados de campo do Chrome UX Report dos 28 dias anteriores, por URL ou, quando o 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 semelhantes e mostra quantos estão bons, precisam de melhorias ou estão fracos nos últimos 28 dias. Os grupos sem dados suficientes ficam de fora.
• A monitorização de utilizadores reais da própria equipa, se existir, é a única fonte que mostra um salto diário no dia da publicação.

A janela de 28 dias pesa na datação. Como o PageSpeed Insights agrega todos os dias os 28 dias anteriores, uma lentidão iniciada numa terça-feira surge 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 que alteração causou a lentidão e a quebra?

Coloque numa única cronologia todas as alterações da semana anterior à quebra, exclua primeiro o tracking e só depois teste a hipótese da velocidade nas páginas que ficaram lentas. Uma quebra nas conversões medidas também pode vir de uma etiqueta avariada, por isso confirme que a etiqueta de conversão continua a disparar na versão nova antes de culpar a velocidade.

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

Exemplo: uma loja online de mobiliário pergunta porque é que as vendas no telemóvel caíram na terça-feira enquanto o computador se manteve. Ao alinhar as alterações, surge uma etiqueta de chat adicionada no GTM na sexta-feira, um vídeo de destaque novo 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 passou a ser o elemento de LCP e carrega muito depois da imagem antiga. A equipa troca o vídeo por uma imagem estática e as vendas móveis recuperam na semana seguinte. Nomes e números são ilustrativos.

Com todas as alterações numa única cronologia, veria que o vídeo entrou no ar três dias antes da quebra, no mesmo modelo onde as vendas móveis caíram. No Changeline é possível registar cada publicação, etiqueta e alteração de consentimento com data, responsável e motivo, e importar automaticamente as edições do Google Ads, pelo que a lista do passo 2 já existe quando a pergunta chega.

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

A prova está em mostrar que três coisas coincidem: a lentidão começou com a alteração, as conversões caíram apenas nas páginas e nos dispositivos afetados e recuperaram quando a alteração foi revertida ou corrigida.

1. Confirmar que o tracking dispara
2. Datar a lentidão nos dados de campo
3. Comparar páginas afetadas e as outras
4. Reverter ou corrigir a alteração
5. Acompanhar a recuperação

• Segmente por dispositivo e página. Se a taxa de conversão no computador se manteve, a do telemóvel caiu e a lentidão está sobretudo no telemóvel, isso é evidência. Uma quebra em todos os dispositivos e páginas aponta para outro lado.
• Verifique a composição do tráfego. Uma campanha, um público ou um orçamento novo pode trazer visitantes menos qualificados no mesmo dia. Veja a taxa de conversão por origem antes de culpar a velocidade. As outras causas estão em porque cai a taxa de conversão.
• Use um grupo de controlo. As páginas que não receberam o script ou o ficheiro novo são o grupo de controlo. Se ficaram estáveis, a alteração é a causa mais provável.
• Reverta e observe. Retirar o script ou anular a publicação é o teste mais limpo. Registe a reversão como uma alteração própria, para que a recuperação também fique datada.

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

Como evitar que a lentidão volte?

Inclua a velocidade em cada publicação e em cada etiqueta nova, e mantenha um registo do que entrou no ar e quando. A maioria das regressões volta porque alguém adiciona o script outra vez ou ninguém se lembra porque foi removido.

A Google recomenda pausar ou remover as etiquetas sem uso em vez de as bloquear com uma exceção de acionador, porque a etiqueta bloqueada continua a levar o código no contentor. Um registo de alterações de marketing partilhado dá a programadores e profissionais de marketing uma única fonte para consultar, e o registo de alterações do site detalha o lado do site.