Use testes A/B para avaliar o impacto da velocidade do site nas suas métricas de negócios.
Nos últimos anos, ficou claro que a performance da velocidade do site é uma parte significativa da experiência do usuário e que melhorá-la beneficia métricas de negócios diferentes, como taxas de conversão e de rejeição. Vários artigos e estudos de caso foram publicados para comprovar isso, incluindo How Website Performance Affects Conversion Rates (em inglês) da Cloudflare, Milliseconds Make Millions (em inglês) da Deloitte e Shopping for Speed on eBay.com (em inglês), para citar alguns.
Embora o caso da velocidade seja claro, muitas empresas ainda têm dificuldade para priorizar o trabalho que vai melhorar a velocidade do site, já que não sabem exatamente como isso afeta os usuários e, como resultado, os negócios.
Na ausência de dados, é fácil atrasar o trabalho de velocidade do site e se concentrar em outras tarefas. Um cenário comum é ter algumas pessoas na empresa que reconhecem a importância da velocidade do site, mas que não conseguem criar um caso para isso e convencer várias partes interessadas a investir de acordo.
Este artigo oferece orientações gerais sobre como aproveitar os testes A/B para avaliar o impacto da velocidade do site nas métricas de negócios, permitindo uma tomada de decisões mais eficaz sobre o assunto.
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 de negócios. Para simplificar, você pode se limitar a identificar uma única página para análise. O trabalho futuro pode ser expandido para várias páginas do mesmo tipo para verificar as descobertas e, em seguida, para outras áreas do site. Confira algumas sugestões de por onde começar na parte de baixo desta etapa. Vários requisitos dirigem o processo de seleção de páginas:
- O teste A/B só pode ser executado nos dispositivos dos 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 no segmento. Os dispositivos móveis são mais sensíveis a sites mais lentos devido a restrições de processamento e de memória e 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 o teste precisa ser uma parte importante do funil de conversão. Cada site tem um propósito diferente, então cada site rastreia métricas de sucesso diferentes. Essas métricas geralmente estão relacionadas a uma jornada do usuário que é analisada usando um funil. Por exemplo, os usuários em um site de e-commerce precisam navegar por uma página inicial, páginas de categoria, páginas de produtos e uma página de finalização de compra para concluir uma compra. Se você estiver otimizando para conversões, uma dessas páginas seria uma boa candidata.
A página precisa ter um propósito único. A menos que seu site tenha uma missão muito específica, geralmente é melhor evitar usar a página inicial para o teste. Muitas páginas iniciais de sites comerciais são portais para uma grande variedade de funcionalidades que vão tornar sua análise ruidosa. Por exemplo, se você estiver otimizando as visualizações de página por sessão em um site de notícias, talvez seja melhor excluir as partes não comerciais do site e se concentrar em seções e artigos monetizados.
A página escolhida precisa receber tráfego suficiente para que você não precise esperar muito para ter um resultado estatisticamente significativo.
A página selecionada precisa ser relativamente lenta. Na verdade, quanto mais lento, melhor. Isso não significa apenas que você provavelmente terá mais facilidade para melhorar a página, mas também significa que os dados serão muito mais claros. Você pode fazer uma verificação rápida no Relatório de velocidade do Google Analytics ou no Relatório Core Web Vitals do Search Console para saber quais das suas páginas são mais lentas.
A página precisa ser relativamente estável. Não atualize as páginas (nada que afete as métricas de negócios) até que o teste seja concluído. Quanto menos fatores externos houver para considerar, mais limpa será a análise.
Usando as informações acima como guia, fica mais claro quais páginas são boas candidatas para o teste. As páginas de destino de anúncios também são uma boa opção, porque você provavelmente terá métricas de negócios, testes A/B e análises integradas à sua disposição. Caso ainda não tenha certeza, confira algumas ideias por vertical:
- Sites de conteúdo: seções, artigos
- Lojas virtuais: páginas de categoria e de produtos
- Players de mídia: páginas de descoberta/pesquisa de vídeos, página de reprodução de vídeos
- Serviços e descoberta (viagens, aluguel de carros, registro de serviços etc.): página inicial de entrada de formulário
Etapa 2: medir a performance
Há duas maneiras gerais de medir métricas: no laboratório e no campo. Para nós, medir métricas no campo (também conhecido como Monitoramento de usuários reais (RUM)) é mais útil porque reflete a experiência de usuários reais. Exemplos de bibliotecas e serviços que podem ajudar a informar dados de RUM incluem Perfume, Monitoramento de desempenho do Firebase e Eventos do Google Analytics.
Há muitas métricas para escolher, porque elas têm como objetivo capturar diferentes aspectos da experiência do usuário. Lembre-se de que seu objetivo é determinar se há uma correlação direta entre a velocidade e as métricas de negócios. Por isso, pode ser útil acompanhar algumas métricas de velocidade para determinar qual delas tem a maior correlação com o sucesso da sua empresa. Em geral, recomendamos começar com os Core Web Vitals. A biblioteca web-vitals.js pode ajudar você a medir algumas das Core Web Vitals no campo, mas observe que o suporte do navegador não é 100%. Além das Core Web Vitals, as Outras Core Web Vitals também valem a pena. Também é possível definir métricas personalizadas, como "Tempo até o primeiro clique no anúncio".
Etapa 3: criar variantes de performance de velocidade
Nesta fase, você vai implementar mudanças para criar uma versão mais rápida da página para ser testada em relação à versão atual.
Alguns pontos importantes:
- Evite fazer mudanças na interface ou na experiência do usuário. Além de uma página ser mais rápida do que a outra, as mudanças precisam ser invisíveis para os usuários.
- A medição também é um aspecto importante dessa etapa. Durante o desenvolvimento, ferramentas de teste de laboratório, como o Lighthouse, devem ser usadas para indicar o efeito das suas mudanças no desempenho. Lembre-se de que as mudanças em uma métrica podem influenciar outra. Depois que as páginas estiverem ativas, use o RUM para uma avaliação mais precisa.
É possível criar variantes de performance de várias maneiras. Para fins de teste, faça isso da maneira mais simples possível. Confira algumas opções abaixo.
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 JavaScript ou CSS não usados apenas para essa página.
- Carregar scripts de terceiros de maneira eficiente
- Use uma ferramenta como o Critical para extrair e inlinear o CSS essencial.
- Remova o código JavaScript não crítico que não afeta a experiência do usuário e que você pode dispensar para fins de teste (por exemplo, certas bibliotecas de terceiros).
- Implemente o carregamento lento no nível do navegador, que não tem suporte de todos os navegadores, mas ainda pode melhorar significativamente o desempenho onde tiver suporte.
- Remova as tags de análise não essenciais ou carregue-as de forma assíncrona
Outras otimizações a serem consideradas podem ser encontradas em Tempos de carregamento rápidos e Lista de verificação de desempenho de front-end. Você também pode usar os Insights do PageSpeed para executar o Lighthouse, que identifica oportunidades para melhorar a performance.
Desacelerar a página
Essa pode ser a maneira mais fácil de criar variantes. Para isso, adicione um script simples, diminua o tempo de resposta do servidor, carregue imagens maiores etc. O Financial Times optou por essa opção ao testar como a performance afetou as métricas de negócios: consulte Um FT.com mais rápido.
Acelerar o carregamento da página
Para casos em que a página de teste (por exemplo, uma página de detalhes do produto) é vinculada principalmente de uma página diferente (por exemplo, a página inicial), prefetching ou pré-renderizar a 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, meça isso e leve isso em consideração ao analisar os resultados do teste (etapa 5).
Etapa 4: criar um teste A/B
Depois de ter 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 medir 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 na velocidade.
Se você estiver usando uma ferramenta de teste A/B, como o Optimizely ou o Optimize, recomendamos configurar um teste do lado do servidor em vez de um do 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 significa que o teste A/B em si distorceria as métricas que você quer medir. Se você só puder fazer testes do lado do cliente, considere configurar o experimento em uma página diferente e mudar as saídas de link para a página de teste para dividir o tráfego. Dessa forma, a página de teste não é arrastada para baixo pelo teste do lado do cliente.
Exemplo de mudanças de desempenho do teste A/B em uma determinada página de detalhes do produto (PDP) por meio de testes no 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, muitas vezes ela precisa de recursos de TI para configurar a divisão do lado do servidor.
Confira 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 do PDP em questão. É fácil de configurar e manter com ferramentas comuns de teste A/B, 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 funcionam de maneira muito semelhante (por exemplo, para dois produtos muito semelhantes). Aplique as mudanças a um deles 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 ele ainda pode ser bastante útil.
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 integradas da sua rede de publicidade, como o teste de divisão de anúncios do Facebook ou os rascunhos e experimentos do Google Ads. Se essa não for uma opção, 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 se sentir confiante nos resultados, é hora de juntar tudo e fazer uma análise. A maneira de fazer isso depende de como o teste foi executado. Vamos conferir as opções.
Se o teste foi realizado em páginas de destino de anúncios usando as ferramentas mencionadas acima, a análise deve ser tão simples quanto ler um resultado. Se você estiver usando os rascunhos e experimentos do Google, confira a comparação usando a ScoreCard.
Plataformas como o Optimizely ou o Optimize também oferecem maneiras fáceas 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, vai precisar criar o relatório. Felizmente, o Google Analytics facilita a criação de relatórios personalizados. Comece por aí. Se você enviou dados de velocidade para o Google Analytics usando uma dimensão personalizada, consulte o guia de relatórios para saber como configurar e incluir esses dados nos seus relatórios personalizados. Confira se o relatório abrange a data do experimento e se está configurado para mostrar as duas variantes. O que deve ser incluído neste relatório?
- Em primeiro lugar, 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 e-commerce, taxa de cliques etc.
- Além disso, outras métricas de página padrão que também são boas 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 seja necessário filtrar para dispositivos móveis e excluir bots e outros tipos de tráfego não relacionados a usuários. Uma análise mais avançada também filtra por região, redes, dispositivos, origem do tráfego e tipos e perfis de usuários, como novos usuários em comparação com 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 cria painéis que podem ser compartilhados com as várias partes interessadas envolvidas na gerenciamento de um site moderno para mais engajamento. Por exemplo, o The Guardian criou um sistema de alerta automatizado que alertava a equipe editorial quando o conteúdo publicado recentemente ultrapassava os limites de tamanho ou velocidade da página e era provável que resultasse em usuários insatisfeitos.
Etapa 6: tirar conclusões e decidir as próximas etapas
Depois de ter dados que conectam as métricas de desempenho e de negócios, você pode analisar os resultados e começar a tirar conclusões.
Se você notar uma correlação clara entre a melhoria da performance e a melhoria das métricas de negócios, resuma os resultados e informe-os em toda a empresa. Agora que você pode falar sobre a performance de velocidade em uma "linguagem de negócios", é mais provável que você chame a atenção de diferentes partes interessadas e coloque a performance de velocidade do site no radar de todos. A próxima etapa é definir orçamentos de performance com base nos resultados e planejar o trabalho para atender a esses orçamentos. Como você sabe o valor que esse trabalho vai proporcionar, é possível priorizar de acordo com isso.
Se você não conseguir identificar uma correlação, confira as ressalvas abaixo e avalie se testes semelhantes precisam ser executados em outro lugar do site (por exemplo, em todo o funil de compra ou em um tipo diferente de página).
Advertências
Há 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 nas 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 de compra for muito lenta ou não for amigável. Considere analisar métricas mais relevantes, como taxas de rejeição, taxas de adição ao carrinho ou qualquer outra métrica diretamente conectada à página que você está testando.
- A diferença de velocidade entre as duas versões não é significativa. Isso precisa ser avaliado de acordo com as métricas do RUM que você está medindo.
- Há um problema com o mecanismo de teste A/B. O tráfego pode não ser distribuído corretamente ou os dados de análise não são informados corretamente. Para descartar isso, faça um teste A/A em que você teste a mesma versão de uma página usando o mesmo mecanismo de teste e verifique se não há diferença nos resultados.
- A velocidade do site não influencia as métricas de negócios. Isso é raro, mas pode ocorrer nos casos em que o mercado-alvo é menos sensível à velocidade (por exemplo, o site é acessado principalmente em dispositivos potentes em uma rede forte) ou a demanda do usuário é muito alta e a escolha é limitada (por exemplo, um serviço de venda de ingressos que vende exclusivamente ingressos para shows de alta demanda). Isso não significa que um site mais rápido não vai melhorar a experiência do usuário e, como resultado, afetar a reputação da marca.
Conclusão
Embora seja tentador lançar otimizações de velocidade em todo o site, geralmente é mais benéfico a longo prazo entender primeiro o que significa para seus usuários e sua empresa ter um site mais rápido. É a diferença entre dizer "Melhoramos o FCP em 1,5 segundo" e "Melhoramos o FCP em 1,5 segundo e isso melhorou nossas taxas de conversão em 5%". Isso permite que você priorize outros trabalhos, receba o apoio de diferentes partes interessadas e torne a velocidade do site um esforço em toda a empresa.