Estratégias para medir a performance em cada estágio do funil de compra.
As etapas do funil de compra estão sujeitas a problemas de performance de maneiras diferentes e, portanto, precisam de medições e otimizações distintas:
Neste guia, abordaremos como as diferentes etapas podem ser medidas. Para isso, recomendamos que você analise dados de laboratório e de campo.
Os dados de laboratório são coletados pela execução de testes localmente, por exemplo, com o Lighthouse e outras ferramentas. Assim, é possível comparar a performance do site ao longo do tempo e com a concorrência em um ambiente controlado e estável, mas talvez não seja representativo do desempenho dos usuários na vida real.
Os dados de campo são coletados por análises de usuários reais e, portanto, representam a experiência deles. No entanto, não pode ser comparado ao longo do tempo ou com concorrentes. Conexões de rede e hardware de smartphone evoluem com o tempo, e diferentes públicos-alvo podem ter dispositivos diferentes, o que dificulta as comparações com dados de campo. Consulte também Medir o desempenho em campo.
Para ter um panorama completo, as duas fontes de dados são necessárias. As seções a seguir mostram como coletar dados de laboratório e campo para as diferentes marcas de desempenho relevantes em todo o funil.
Discovery
Otimizar para descoberta significa otimizar para o primeiro carregamento, que é o que os novos usuários vão receber, mas também os rastreadores de pesquisa e redes sociais. Os dados do laboratório para o primeiro carregamento podem ser facilmente adquiridos pelo Lighthouse, enquanto os dados de campo (pelo menos para o Chrome) estão disponíveis nos relatórios de UX do Chrome. Uma combinação conveniente de ambos é encontrada no PageSpeed Insights. Também é preciso acompanhar métricas relevantes do campo: medir essas métricas em dispositivos de usuários reais oferece uma boa visão geral.
Do ponto de vista do usuário, as métricas mais importantes são:
- Primeira exibição de conteúdo (FCP, na sigla em inglês):o tempo que o usuário olha para uma tela em branco. É aqui que a maioria dos usuários pula porque não vê progresso.
- Primeira exibição significativa (FMP, na sigla em inglês):quando o usuário começa a ver o conteúdo principal. Geralmente, essa é a imagem principal. No entanto, para uma página de destino, ela pode até mesmo ser uma call-to-action, como um botão Comprar, já que o usuário pode ter chegado com uma intenção clara (por exemplo, por meio de uma campanha publicitária segmentada).
- Latência na primeira entrada (FID, na sigla em inglês):o tempo que o site precisa para reagir à primeira entrada do usuário. Excesso de JavaScript e outros problemas de carregamento de recursos podem bloquear isso, levando a toques ou cliques com falha, entradas incorretas e abandono de página.
Há mais métricas que você pode analisar, mas essas são uma boa linha de base. Além disso, capture as taxas de rejeição, as conversões e o engajamento do usuário para que você possa defini-los em relação.
Engajamento e conversão
Após o primeiro carregamento de uma página de destino, o usuário navegará pelo seu site, esperando que a conversão seja bem-sucedida.
Nesta fase, é importante ter navegações e interações rápidas e responsáveis. Infelizmente, não é trivial medir o fluxo completo de eventos de navegação e interação no campo, já que cada usuário segue caminhos diferentes na página. Portanto, recomendamos medir o tempo necessário para as submetas de conversão ou de conversão ("Tempo para ação") com scripts e medindo o fluxo em um teste de laboratório para comparar o desempenho ao longo do tempo ou com concorrentes.
Há duas maneiras convenientes de fazer isso:
WebPageTest
O WebPageTest oferece uma solução de script muito flexível. A ideia básica é:
- Instrua o WebPageTest a navegar pelas páginas do fluxo com o
comando
navigate
. - Se necessário, faça um script do clique em botões pelos comandos
clickAndWait
e preencha os campos de texto comsetValue
. Para testar aplicativos de página única, useclickAndWait
em vez de comandosnavigate
para todas as etapas após a primeira, porquenavigate
fará um carregamento completo em vez do carregamento de página virtual leve. - Combine as diferentes etapas do fluxo na análise usando
combineSteps
para produzir um único relatório de resultados gerais para o fluxo completo.
Esse script pode ser assim:
combineSteps
navigate https://www.store.google.com/landingpage
navigate https://www.store.google.com/productpage
clickAndWait innerText=Buy Now
navigate https://www.store.google.com/basket
navigate https://www.store.google.com/checkout
Com um script como esse, é possível medir e comparar facilmente o desempenho ao longo do tempo. Isso pode até ser automatizado pela API WebPageTest.
Animador de fantoches
Outra ótima opção para o teste de script é por meio da versão headless do Chrome, que pode ser controlada pela API Node Puppeteer. A ideia geral é iniciar o navegador com o Puppeteer, navegar até a página de destino com a função goto, injetar o JavaScript para preencher campos ou clicar em botões e avançar pelo funil com mais chamadas de goto, conforme necessário.
Como métrica, a duração do fluxo pode ser medida diretamente, mas também é possível somar os valores de FCP, FMP ou TTI das cargas individuais do fluxo. Em Testar o desempenho do site com o Puppeteer, você tem uma visão geral de como conseguir métricas de desempenho por meio do Puppeteer. Um exemplo de script Node muito simplificado pode ter esta aparência:
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
const start = performance.now();
await page.goto('https://www.store.google.com/landingpage');
await page.goto('https://www.store.google.com/productpage');
// click the buy button, which triggers overlay basket
await page.click('#buy_btn');
// wait until basket overlay is shown
await page.waitFor('#close_btn');
await page.goto('https://www.store.google.com/basket');
await page.goto('https://www.store.google.com/checkout');
console.log('Flow took ' + parseInt((performance.now() - start)/1000) + ' seconds');
await browser.close();
})();
Esse script pode ser facilmente automatizado e incluído no processo de build ou nos orçamentos de desempenho, além de ser monitorado regularmente.
Reengajamento
Os usuários vão voltar ao seu site em intervalos de tempo diferentes. Dependendo do tempo decorrido, o navegador pode ter menos recursos do site armazenados em cache, precisando de mais solicitações de rede. Isso dificulta a estimativa das diferenças de desempenho em visitas repetidas em testes de laboratório. No entanto, ainda é recomendável acompanhar isso. Uma ótima ferramenta de teste de laboratório para visitas repetidas é o WebPageTest, que tem uma opção dedicada para uma visita repetida direta:
Para ter uma ideia melhor do desempenho de visitas repetidas no campo, use o pacote de análise de sua preferência para segmentar as métricas de desempenho por tipo de usuário. Confira um exemplo desse tipo de relatório no Google Analytics:
Um relatório como esse também informa o tempo de carregamento da página de usuários novos e recorrentes.
Recap
Este guia mostrou como medir a primeira carga, o fluxo e a carga repetida em testes de campo e de laboratório. Otimize as diferentes etapas do funil para maximizar a descoberta (primeiro carregamento), o engajamento (navegações e fluxo) e o reengajamento (repetição de carga).