E-commerce: Percepção da velocidade do site faz toda a diferença

Todos sabemos que a velocidade do site pode fazer uma enorme diferença na taxa de conversão e na aderência de um site de comércio eletrônico.

Um estudo de caso da SOASTA afirmou que melhorar a velocidade de carregamento da página móvel aumentou a taxa de conversão em mais de 25%. Em seu constante esforço para colocar o usuário em primeiro lugar, Jeff Bezos, fundador e CEO da Amazon, é notoriamente obcecado com a velocidade de carregamento da página e está constantemente levando seus funcionários a reduzir a velocidade da página do site da Amazon.

O aumento do domínio móvel amplificou a necessidade de uma velocidade de carregamento de página mais rápida, pois os usuários geralmente navegam em sites em conexões mais lentas.

Existem muitas ferramentas disponíveis para ajudá-lo a melhorar a velocidade de páginas da Web, como Yslow ou Google Pagespeed Insights, e existem várias práticas recomendadas, como minificação e mesclagem de css e js, uso de sprites css e minimização de solicitações de rede que um desenvolvedor front-end deve seguir para garantir que a velocidade da página seja maximizada.

O problema que temos é que, uma vez que você siga as práticas recomendadas padrão e perceba as grandes vitórias, em breve você começará a ver retornos decrescentes nos esforços para melhorar a velocidade geral da página.

Você pode gastar muito tempo fazendo melhorias incrementais cada vez menores e isso será um processo caro e demorado. Desenvolvedores front-end com as habilidades e experiência necessárias para trabalhar nesse nível são surpreendentemente escassos e caros.

Existem algumas coisas que você não pode controlar, como a latência da rede ou a velocidade da conexão móvel, portanto, há um limite para o que pode ser alcançado com a velocidade bruta da página. Em uma conexão 3G, algo entre 600ms e 1s é consumido por sobrecargas de rede obrigatórias, sobre as quais você não pode fazer nada. Com base em um tempo de carregamento de página desejado de 2s, isso nos dá apenas 1s para brincar. Isso não é muito.

Não há como negar que a velocidade bruta da página é muito importante e todos os desenvolvedores devem seguir, no mínimo, as práticas recomendadas padrão.

Este artigo, no entanto, não vai discutir como fazer sua página carregar mais rápido. Há muitos artigos por aí sobre isso e é tudo um pouco técnico.

Este artigo vai focar na percepção da velocidade da página.
O que é mais importante: quão rápido a página carrega ou quão rápido o usuário percebe que ela carrega?

Certamente a percepção é o que mais conta para o usuário.

Velocidade do site: primeiras impressões

Vamos nos concentrar na página inicial do seu site. É provável que contenha uma navegação superior, barra de pesquisa, banner de herói, talvez links para categorias-chave, um carrossel e algum conteúdo. As páginas iniciais tendem a ser bastante pesadas em conteúdo e carregar todo esse conteúdo rapidamente em uma conexão móvel será um grande desafio.

A chave aqui é priorizar o carregamento de conteúdo crítico primeiro, antes de outros conteúdos – dê ao usuário algo importante para ver o mais rápido possível.

Enquanto eles processam essas informações críticas, você pode começar a carregar a próxima camada de conteúdo.

Em um dispositivo móvel, grande parte do conteúdo começará abaixo da dobra e, portanto, deve ser carregado após o conteúdo acima da dobra. É uma prática comum mesclar e reduzir JavaScript. Isso normalmente é visto como uma prática recomendada, mas pode impedir que você priorize o carregamento de JavaScript crítico antes do código menos crítico. Em vez disso, você pode considerar dividir seu JavaScript minificado e mesclado e carregá-lo progressivamente conforme necessário. Não há necessidade de carregar o JavaScript necessário para realizar uma pesquisa antes mesmo de carregar a caixa de pesquisa. Os usuários não digitarão caracteres no campo de pesquisa por pelo menos alguns segundos em um carregamento de página.

Vamos procurar um site que faz isso muito bem. A Amazon dividiu a entrega de ativos e conteúdo para garantir que o usuário receba conteúdo crítico o mais rápido possível e, em seguida, carregue ativos progressivamente em ordem de prioridade.

Este teste foi executado em um simulador de iPhone 6 em uma boa conexão 3G e cache desabilitado. Depois que a página foi carregada inicialmente, iniciei uma atualização completa.

Em pouco mais de 600ms tenho algo começando a carregar com meu nome no cabeçalho. Você também notará que apenas 6 chamadas de rede foram feitas e 5 ativos carregados (3 arquivos css e 2 imagens).

Apenas 50ms depois, agora vejo os principais componentes do cabeçalho, bem como o banner do herói principal. Já tenho a percepção de velocidade, pois o conteúdo principal está sendo entregue a mim muito rapidamente e há algo para meus olhos e cérebro processarem enquanto o conteúdo adicional está sendo carregado.

Após apenas 1 segundo, a navegação principal é carregada. Você notará que não há barra de rolagem visível neste estágio. Isso significa que atualmente não há conteúdo abaixo da dobra. Tempo precioso não foi desperdiçado no carregamento deste conteúdo que o usuário não pode ver. Você também notará que apenas 13 solicitações foram feitas até agora.

Em pouco menos de 2 segundos, agora tenho uma nova seção de conteúdo importante.

Em menos de 3 segundos, agora percebo que a página foi totalmente carregada, enquanto a página levou pouco menos de 5 segundos para carregar por completo. Isso sugere que eu percebo que o site está completamente carregado quando na verdade está apenas 60% carregado.

O tempo real de entrega de conteúdo varia de pessoa para pessoa, mas isso ilustra muito claramente como a Amazon está priorizando o carregamento de conteúdo móvel para garantir que o conteúdo crítico seja carregado o mais rápido possível e que os usuários percebam que o site está começando a carregar muito rapidamente.

Agora vamos olhar para um site que não faz isso tão bem. Este teste foi executado usando exatamente as mesmas ferramentas e velocidade de rede do teste anterior da Amazon. Embora o site de Charles Tyrwhitt priorize alguns conteúdos, há muito mais que pode ser feito para se aproximar da otimização da Amazon.

Não vejo nenhum conteúdo por quase 7,5 segundos. Imediatamente tenho a percepção de que este site está lento no meu dispositivo móvel. Embora o site priorize o conteúdo do cabeçalho, bem como um banner de herói, você pode ver que mais de 90 solicitações foram feitas até este ponto e, como posso ver na barra de rolagem, fica claro que o conteúdo deve ter sido carregado abaixo da dobra.

Após 8,5 segundos, posso ver que um carrossel está começando a carregar. O número de solicitações não mudou, o que sugere que a maior parte das solicitações relacionadas ao conteúdo é feita logo no início do carregamento da página.

Não é até quase 22 segundos que percebo que o site está totalmente carregado. A página realmente levou um total de 28,4 segundos para carregar completamente. Isso sugere que percebo que a página foi completamente carregada quando na verdade estava 77% carregada.

É fácil ver a clara diferença entre as 2 experiências. Embora a página inicial móvel da Amazon carregue significativamente mais rápido do que a página inicial de Charles Tyrwhitt, esforços foram feitos para garantir que os usuários percebam que ela é ainda mais rápida. O usuário começa a ver algo carregando dentro de 12,5% do tempo total de carregamento da página, enquanto os usuários do site Charles Tyrwhitt só veem algo acontecendo dentro de 26% do tempo total de carregamento da página. A página inicial da Amazon fez 6 solicitações de rede antes que o usuário veja o progresso, enquanto a página inicial de Charles Tyrwhitt fez 90 solicitações.

Isso não significa ser excessivamente crítico de Charles Tyrwhitt, pois eles não são, de forma alguma, únicos na maneira como construíram seu site. A melhor prática aceita foi seguida em várias áreas, mas parece que muito mais poderia ser feito para melhorar a percepção da velocidade, bem como a velocidade real.

Melhore a velocidade do site priorizando CSS

É bastante comum que os desenvolvedores front-end coloquem a maioria do CSS de um site em um punhado de arquivos e sempre usem CSS externo, em vez de embutido. O problema que isso causa é que um arquivo css grande precisa ser carregado antes que qualquer conteúdo possa ser mostrado a um usuário.

Uma solução para isso é dividir seus arquivos css e carregá-los em sequência com o conteúdo crítico. Se olharmos para o exemplo da Amazon, eles carregam um arquivo css com apenas 6,5k de tamanho como uma de suas 6 solicitações iniciais. Este arquivo contém o CSS necessário para estilizar o conteúdo crítico em sua página inicial. Na verdade, o tamanho total de todos os arquivos css solicitados antes que o usuário veja o conteúdo na home page móvel da Amazon é inferior a 40k, enquanto na home page de Charles Tyrwhitt é superior a 500k.

Essa prática permite entregar conteúdo crítico ao usuário muito rapidamente e ajuda a reforçar a percepção de velocidade.

Faça o mesmo com JavaScript

Além de priorizar o CSS, você deve considerar como também faz isso com JavaScript. Quase todos os sites de comércio eletrônico dependem muito do JavaScript para funcionar. Tudo bem, desde que o JavaScript não esteja bloqueando o carregamento de conteúdo crítico. Se eu pegar o exemplo do site de Charles Tyrwhitt novamente e desabilitar o JavaScript no meu navegador, agora vejo o conteúdo sendo carregado em 4,5 segundos. Esta é uma grande mudança na minha percepção da velocidade desse site e o JavaScript que foi carregado antes do conteúdo crítico não teve impacto sobre esse conteúdo e, portanto, não há razão para que o JavaScript não possa ser carregado após esse conteúdo.

Há muito que os desenvolvedores da Web podem aprender com a maneira como um site como o Amazon se concentra na percepção da velocidade de seu site, bem como na velocidade real. Embora seu site seja claramente muito rápido, os usuários o percebem como ainda mais rápido devido à maneira como priorizam mostrar ao usuário conteúdo crítico antes de qualquer outra coisa.

Muito tem sido feito sobre o impacto que a velocidade pode ter na sua taxa de conversão, e os varejistas devem considerar investir na otimização do desempenho percebido do site junto com a velocidade real do site.