Use o teste A/B para avaliar o impacto da velocidade do site nas suas métricas de negócios.
Nos últimos anos, ficou bem estabelecido que o desempenho da velocidade do site é uma parte significativa da experiência do usuário e que melhorá-lo beneficia diferentes métricas de negócios, como taxas de conversão e de rejeição. Vários artigos e estudos de caso foram publicados para comprovar isso, incluindo Como o desempenho do site afeta as taxas de conversão da Cloudflare, Milliseconds Make Millions (link em inglês) da Deloitte e Shopping for Speed on eBay.com, entre outros.
Mesmo que o caso da velocidade seja claro, muitas empresas ainda têm dificuldade em priorizar trabalhos que aumentem a velocidade do site, já que elas não sabem exatamente como isso afeta os usuários e, como resultado, os negócios.
Na ausência de dados, é fácil atrasar a velocidade do site e se concentrar em outras tarefas. É comum que algumas pessoas da empresa reconheçam a importância da velocidade do site, mas não consigam criar um caso para isso e convencer várias partes interessadas a investir da forma adequada.
Neste artigo, fornecemos orientações de alto nível sobre como aproveitar o teste A/B para avaliar o impacto da velocidade do site nas métricas de negócios, permitindo uma tomada de decisão mais eficaz.
Etapa 1: escolher uma página para o teste A/B
Seu objetivo é testar a hipótese de que a velocidade da página está relacionada às métricas do seu negócio. Para simplificar, você pode primeiro se limitar à identificação de uma única página para análise. Trabalho futuro pode expandir para várias páginas do mesmo tipo para verificar descobertas e, em seguida, para outras áreas do site. Veja algumas sugestões de por onde começar na parte de baixo desta etapa. Vários requisitos orientam o processo de seleção da página:
- O teste A/B só deve ser realizado em dispositivos de usuários de dispositivos móveis. Globalmente, os sites parceiros que ajudamos têm uma média de mais de 50% (e crescendo) do tráfego proveniente de dispositivos móveis, mas isso pode aumentar significativamente com base na região e na indústria. Os dispositivos móveis são mais sensíveis a sites mais lentos devido a restrições de processamento e memória, além de redes menos estáveis. Além disso, os padrões de uso em trânsito significam que as expectativas de velocidade são maiores.
A página escolhida para teste deve ser uma parte importante do seu funil de conversão. Cada site tem uma finalidade diferente, portanto, cada site acompanha métricas de sucesso diferentes. Essas métricas geralmente estão relacionadas à jornada do usuário, que é analisada com um funil. Por exemplo, os usuários em um site de e-commerce precisam navegar pela página inicial, pelas de categorias, de produtos e de finalização da compra para concluir a compra. Se você estiver otimizando para conversões, uma dessas páginas será uma boa candidata.
A página precisa ter um único propósito. A menos que seu site tenha uma missão muito específica, geralmente é melhor evitar usar a página inicial para o teste. As páginas iniciais de muitas páginas iniciais de sites comerciais são portais para uma ampla variedade de funcionalidades que tornam sua análise ruidosa. Por exemplo, se você estiver otimizando para visualizações de página por sessão em um site de notícias, convém excluir as partes não comerciais do site e focar nas seções e artigos monetizados.
A página escolhida precisa receber tráfego suficiente. Assim, não é preciso esperar muito para ter um resultado estatisticamente significativo.
A página selecionada deve ser relativamente lenta. Na verdade, quanto mais lento, melhor. Isso não apenas significa que você provavelmente terá mais facilidade para melhorar a página, mas também significa que os dados devem ser muito mais claros. Você pode fazer uma verificação rápida no Relatório de velocidade do Google Analytics ou no Relatório de Core Web Vitals do Search Console para ver quais páginas estão mais lentas.
A página precisa estar relativamente estável. Não atualize as páginas (tudo que pode afetar as métricas de negócios) até que o teste seja concluído. Quanto menos fatores externos houver a considerar, mais limpa será a análise.
Usando as informações acima como guia, fica um pouco mais claro quais páginas são boas candidatas para seu teste. As páginas de destino do anúncio também são uma boa escolha, porque você provavelmente terá métricas de negócios integradas, testes A/B e análises à sua disposição. Caso você ainda não tenha certeza, aqui estão algumas ideias por setor:
- Sites de conteúdo: seções, artigos
- Vitrines: páginas de categorias, páginas de produtos
- Players de mídia: páginas de pesquisa/descoberta de vídeo, página de reprodução de vídeo
- Serviços e descoberta (viagens, aluguel de carros, registro de serviços etc.): página inicial de entrada do formulário
Etapa 2: avaliar a performance
Há duas maneiras gerais de medir métricas: no laboratório e em campo. Pessoalmente, descobrimos que a medição de métricas no campo, também conhecida como Monitoramento real de usuários (RUM, na sigla em inglês), é mais útil porque reflete a experiência de usuários reais. Exemplos de bibliotecas e serviços que podem ajudar você a relatar dados RUM incluem Perfume, Monitoramento de desempenho do Firebase e Eventos do Google Analytics.
Há muitas métricas para escolher, porque elas tentam capturar diferentes aspectos da experiência do usuário. Lembre-se de que seu objetivo é, em algum momento, determinar se há uma correlação direta entre a velocidade e as métricas de negócios. Por isso, pode ser útil rastrear algumas métricas para determinar qual tem a correlação mais forte com o sucesso da sua empresa. Em geral, recomendamos começar com as Core Web Vitals. A biblioteca web-vitals.js (link em inglês) pode ajudar você a medir algumas das Core Web Vitals em campo, embora o suporte ao navegador não seja 100%. Além das Core Web Vitals, também vale a pena conferir as outras métricas da Web. Também é possível definir métricas personalizadas, como "Tempo até o primeiro clique no anúncio".
Etapa 3: criar variantes de desempenho de velocidade
Nesta fase, você implementará as alterações para criar uma versão mais rápida da página a ser testada em relação à versão atual.
Lembre-se do seguinte:
- Evite fazer mudanças na interface ou UX. Além de uma página ser mais rápida que a outra, as alterações precisam ser invisíveis aos usuários.
- A medição também é um aspecto importante desta etapa. Durante o desenvolvimento, ferramentas de teste de laboratório, como o Lighthouse, devem ser usadas para indicar o efeito das alterações no desempenho. Lembre-se de que alterações em uma métrica geralmente podem influenciar outra. Quando as páginas estiverem ativas, use o RUM para ter uma avaliação mais precisa.
A criação de variantes de desempenho pode ser feita de diferentes maneiras. Para os fins do teste, é recomendado fazê-lo da forma mais simples possível. Veja abaixo algumas opções.
Criar uma página mais rápida
- Use uma ferramenta como o Squoosh para otimizar manualmente as imagens na página de teste.
- Use a cobertura de código do DevTools para eliminar manualmente o JavaScript ou CSS não utilizado somente para essa página.
- Carregar scripts de terceiros com eficiência
- Use uma ferramenta como Crítico para detalhar e CSSs in-line essenciais.
- Remover o código JavaScript não crítico que não afeta a experiência do usuário e que pode ser usado sem a finalidade de teste (por exemplo, algumas bibliotecas de terceiros).
- Implemente o carregamento lento no nível do navegador, que não é compatível com todos os navegadores, mas que ainda pode melhorar significativamente o desempenho quando compatível
- Remova tags de análise não críticas ou carregue-as de forma assíncrona
Outras otimizações a serem consideradas podem ser encontradas em Tempos de carregamento rápidos e na Lista de verificação de desempenho do front-end. Também é possível usar o PageSpeed Insights para executar o Lighthouse, que identifica oportunidades para melhorar o desempenho.
Diminuir a velocidade da página
Essa pode ser a maneira mais fácil de criar variantes e pode ser feita com a adição de um script simples, diminuindo os tempos de resposta do servidor, carregando imagens maiores etc. O Financial Times optou por essa opção ao testar como o desempenho afetou as métricas de negócios: consulte Um FT.com mais rápido.
Acelerar o carregamento de páginas
Nos casos em que a página de teste (digamos, uma página de detalhes do produto) está vinculada principalmente a uma página diferente (por exemplo, a página inicial), a pré-busca ou a pré-renderização da página do produto diretamente da página inicial para o grupo de teste vai acelerar o carregamento subsequente da página. Nesse caso, a divisão do teste A/B (etapa 4) é feita na página inicial. Além disso, tudo isso pode deixar a primeira página mais lenta. Portanto, avalie isso e considere isso ao analisar os resultados do teste (etapa 5).
Etapa 4: criar um teste A/B
Quando você tiver duas versões da mesma página em que uma é mais rápida que a outra, a próxima etapa é dividir o tráfego para avaliar o impacto. Em geral, existem muitas técnicas e ferramentas para realizar testes A/B, mas nem todos os métodos são adequados para medir o impacto no desempenho da velocidade.
Se você estiver usando uma ferramenta de teste A/B, como Optimizely ou Optimize, recomendamos configurar um teste no lado do servidor em vez de um teste no lado do cliente, já que o teste A/B do lado do cliente geralmente funciona ocultando o conteúdo da página até que o experimento seja carregado, o que significaria que o próprio teste A/B distorceria as métricas que você queria medir. Se você só puder fazer testes do lado do cliente, considere configurar o experimento em outra página e alterar os links para a página de teste para dividir o tráfego. Dessa forma, a página de teste em si não é arrastada pelo teste do lado do cliente.
Exemplo de alterações de desempenho do teste AB em uma determinada página de detalhes do produto (PDP, na sigla em inglês) por meio de testes do lado do servidor:
A solicitação vai para o back-end, que distribui os usuários para as duas versões diferentes da página. Embora essa seja uma boa configuração em geral, ela geralmente precisa de recursos de TI para configurar a divisão do lado do servidor.
Veja um exemplo de configuração de teste do lado do cliente usando a página anterior (a página inicial no diagrama abaixo) para executar o JavaScript de teste:
O JavaScript de teste manipula o link de saída para fornecer aos dois grupos de teste de usuários links para as duas versões da PDP em questão. Isso é fácil de configurar e manter com ferramentas de teste A/B comuns, como Optimizely ou Optimize, e não influencia o teste de desempenho, porque o JavaScript de teste é executado em uma página diferente.
Como alternativa, você pode escolher duas páginas que se comportam e têm um desempenho muito parecido (por exemplo, para dois produtos muito semelhantes). Aplique as alterações a uma delas e compare a diferença nas métricas ao longo do tempo. Isso significa que você não está realizando um teste A/B adequado, mas ainda assim pode ser muito esclarecedor.
Caso sua página de teste seja usada como uma página de destino para campanhas publicitárias, pode ser útil usar as ferramentas de teste A/B incorporadas da rede de publicidade, como o Teste A/B dos anúncios do Facebook ou os Rascunhos e experimentos do Google Ads. Se isso não for possível, use duas campanhas com a mesma configuração e defina páginas de destino diferentes como segmentações.
Etapa 5: analisar o teste A/B
Depois de executar o teste por tempo suficiente e ter dados suficientes para ter confiança nos resultados, é hora de reunir tudo e executar uma análise. A forma como você faz isso depende de como o teste foi executado. Portanto, vamos analisar as opções.
Se você realizou seu teste em páginas de destino de anúncios usando as ferramentas mencionadas acima, a análise será tão direta quanto ler um resultado. Se você usa os rascunhos e experimentos do Google, veja a comparação usando o ScoreCard.
Plataformas como o Optimizely ou o Optimize também oferecem maneiras fáceis de interpretar os resultados e determinar o impacto da velocidade nas suas páginas.
Se você estiver usando o Google Analytics ou uma ferramenta semelhante, precisará gerar o relatório. Felizmente, o Google Analytics facilita a criação de relatórios personalizados, então você precisa começar por aí. Se você enviou dados de velocidade ao Google Analytics usando uma dimensão personalizada, confira o guia de relatórios para saber como configurar esses dados e incluí-los nos seus relatórios. Verifique se o relatório abrange a data do experimento e se está configurado para exibir as duas variantes. O que deve ser incluído nesse relatório?
- Primeiro, você precisa incluir as métricas de negócios mais importantes para você: conversões, visualizações de página, anúncios visualizados, taxa de conversão, métricas de comércio eletrônico, taxa de cliques etc.
- Além disso, outras métricas de página padrão que também são um bom caso para melhorar a velocidade do site são a taxa de rejeição, a duração média da sessão e a porcentagem de saída.
Talvez também seja necessário filtrar por dispositivos móveis e excluir bots e outros tipos de tráfego que não são de usuários. Uma análise mais avançada também filtra por região, redes, dispositivos, origem de tráfego, além de perfis e tipos de usuários, como novos usuários versus visitantes recorrentes. Cada grupo de usuários pode ser mais ou menos sensível a velocidades mais lentas, e identificá-los também é muito útil.
O Looker Studio (antigo Data Studio) ou outras ferramentas de visualização de dados facilitam a integração de várias fontes de dados, incluindo o Google Analytics. Isso facilita a realização de análises e também a criação de painéis que podem ser compartilhados com as várias partes interessadas envolvidas na execução de um site moderno para maior adesão. Por exemplo, o Guardian criou um sistema de alertas automatizado que avisava a equipe editorial quando o conteúdo publicado recentemente ultrapassava os limites de velocidade ou tamanho da página e poderia resultar em usuários insatisfeitos.
Etapa 6: tirar conclusões e decidir as próximas etapas
Depois de ter dados que conectam métricas de desempenho e de negócios, é possível examinar os resultados e começar a tirar conclusões.
Se você conseguir ver claramente uma correlação entre melhorar o desempenho e melhorar as métricas de negócios, resuma os resultados e informe-os em toda a empresa. Agora que você pode falar sobre o desempenho da velocidade em uma "linguagem comercial", é mais provável que chame a atenção de diferentes partes interessadas e preste atenção ao desempenho da velocidade do site. A próxima etapa é definir orçamentos de desempenho com base nos resultados e planejar o trabalho para atingir esses orçamentos. Como você sabe o valor que esse trabalho vai proporcionar, será possível priorizar de acordo.
Se não for possível identificar uma correlação, confira os avisos abaixo e avalie se testes semelhantes precisam ser executados em outro lugar no site (por exemplo, em todo o funil de compra ou em um tipo diferente de página).
Advertências
Pode haver vários motivos para não encontrar uma correlação significativa entre as métricas de velocidade do site e as métricas de negócios:
- A página escolhida não tem influência suficiente sobre as métricas de negócios que você está examinando. Por exemplo, uma página de produto mais rápida pode não ter um grande efeito nas taxas de conversão se a página de finalização da compra for muito lenta ou maldosa. Considere analisar métricas mais relevantes, como taxas de rejeição, taxas de adição ao carrinho ou qualquer outra métrica que esteja mais diretamente conectada à página que você está testando.
- A diferença de velocidade não é significativa o suficiente entre as duas versões. Ela deve ser avaliada de acordo com as métricas RUM que você estiver medindo.
- Há uma falha no mecanismo de teste A/B. O tráfego pode não ser distribuído corretamente ou as análises não são informadas corretamente. Para descartar isso, execute um teste A/A em que você testa a mesma versão de uma página usando o mesmo mecanismo de teste e garanta que não haja diferença nos resultados.
- A velocidade do site realmente não influencia as métricas de negócios. Isso é raro, mas pode ocorrer nos casos em que seu mercado de destino é menos sensível à velocidade (por exemplo, o site é acessado principalmente por dispositivos potentes em uma rede forte) ou a demanda do usuário é muito alta e as opções são limitadas (por exemplo, um serviço de venda de ingressos que vende exclusivamente ingressos para shows com alta demanda). Isso não significa que um site mais rápido não vai melhorar a experiência do usuário e, consequentemente, afetar a reputação da marca.
Conclusão
Embora seja tentador implementar otimizações de velocidade em todo o site, geralmente é mais vantajoso a longo prazo entender primeiro o que significa ter um site mais rápido para os usuários e sua empresa. É a diferença entre dizer "melhoramos a FCP em 1,5 segundo" e "melhoramos a FCP em 1,5 segundo e isso melhoramos nossas taxas de conversão em 5%". Assim, você poderá priorizar outros trabalhos, conseguir a adesão de diferentes partes interessadas e tornar o desempenho da velocidade do site um esforço em toda a empresa.