Serviços rápidos e ágeis fazem uma ótima experiência do usuário. O problema é que a maioria de nós hoje não tem as ferramentas para quantificar de forma confiável essa métrica: as medições do lado do servidor não levam em conta a rede e a latência do lado do cliente, e a maioria das ferramentas do navegador possui pouca visibilidade para as partes mais baixas da pilha. Como resultado, na maioria dos casos, simplesmente cruze os dedos, otimize os componentes individuais em um ambiente de laboratório e espere que ele corresponda à experiência do usuário – o que, infelizmente, raramente é o caso.

Se você quer ter a visão completa sobre a experiência do usuário, você precisa medir a latência do ponto de vista do cliente. O seu servidor pode responder em <50ms para solicitações de entrada, mas o DNS, um caminho de roteamento esquisito para a conexão, ou as três dezenas de recursos externos e uma carga JavaScript de bloqueio podem resultar – muitas vezes isso acontece! – em um tempo de carregamento de multi-segundo – que é como o usuário vê!

Navigation Timing – a especificação do W3C

Se quisermos ver a perspectiva do usuário final, então precisamos instrumentar o navegador para nos dar essa informação. Felizmente, o W3C Web Performance Working Group está à nossa frente: o Navigation Timing. A especificação é ainda um projeto, mas Chrome, Firefox e IE já implementaram a proposta.

Se parece complicado, é porque é mesmo! À medida que você clica em qualquer link dessa página, o navegador tem que primeiro descarregar o DOM, e então verificar o AppCache para o recurso solicitado. Se isso falhar, então precisamos resolver o hostname (DNS), após o qual podemos realizar o handshake TCP (com upgrade SSL opcional). Apenas depois que essas idas e vindas são feitas podemos emitir a solicitação HTTP, momento em que o nosso servidor finalmente começa a trabalhar na resposta, que por sua vez leva mais tempo para transmitir de volta através de uma rede não confiável (responseEnd). Agora, o navegador pode começar a carregar o corpo da resposta, repetindo esse processo para cada sub-recurso (alguns em paralelo, alguns em bloqueio), e só depois é que o loadEventEnd funciona.

Existem muitos fornecedores e serviços que terão prazer em ajudá-lo a otimizar qualquer parte em particular dessa pilha: provedores de DNS, ferramentas de monitoramento do lado do servidor, CDNs, e assim por diante. O problema é que nenhum desses serviços nos dá a visão completa. E, para ser justo, poucos de nós hoje estamos pedindo isso também – isso é algo que precisa mudar.

Medição “Percebida Latência (User)”

Navigation Timing ainda é um trabalho em andamento e há algumas omissões notáveis de implementação: não há suporte para Safari ou iOS, ou nenhuma implementação do Opera. Dito isso, ter alguns dados é melhor do que dado nenhum, e é apenas uma questão de tempo. Se você é um usuário do Chrome, abra seu console Javascript (Cmd-Opt-j no OSX) e digite performance.timing para ver todas as medidas acima para a página atual. Alternativamente, confira este protótipo Mozilla para uma grande demonstração visual, ou adicione um destes bookmarklets do navegador para ver as estatísticas sob demanda para qualquer página no seu browser.

Google Analytics + relatórios “Site Speed”

Uma característica pouco conhecida do Google Analytics é que ele já prevê uma série de relatórios “Site Speed” com base nos dados de Navigation Timing! Para começar, abra o seu perfil e siga para Content > Site Speed. Aviso: eu trabalho com a equipe GA.

Por padrão, o rastreador ga.js vai fazer uma amostra desses dados a partir de 10% do seu tráfego, até 10K visitas por dia – se você não está atingindo o limite superior, aumente a sua taxa de amostragem! Com isso funcionando, podemos agora começar a olhar para as reais distribuições de latência de usuário. Palavra-chave: distribuições.

Relatórios Site Speed oferecem várias métricas ótimas, tais como tempos médios de resposta (sim, os tempos de resposta do servidor no GA!), latência de DNS, bem como uma dúzia de outras métricas e dimensões. No entanto, infelizmente, as médias só confundem: se você está investigando o desempenho como uma função do tempo, então você precisa olhar para a distribuição subjacente dos dados. Jogue fora as médias, precisamos de histogramas!

Distribuições de desempenho: igvita.com

Vá direto para Content > Site Speed > Page Timings > Performance, na verdade, faça dela a sua página inicial. Lá, você vai encontrar os histogramas para todas as métricas-chave: DNS, redirecionamento, conexão com o servidor e resposta, download, e os tempos de carregamento da página. Para um exemplo, vamos dar uma olhada em alguns dados para igvita.com:

Uma típica distribuição skewed para o tempo total carregamento da página. Só que, em janeiro há uma mudança notável! Acontece que eu migrei do site do WordPress para Jekyll, e introduzi um novo tema otimizado em 31 de dezembro. Parece que o esforço definitivamente valeu a pena: mais de 50% dos carregamentos da página estão abaixo de 3 segundos.

O histograma do tempo de resposta do servidor é muito mais interessante. Sim, o tempo médio de resposta foi de 910ms para 220ms, mas o que a média oculta é a distribuição bimodal dos dados, para que possamos formar uma hipótese: o primeiro pico é quando um usuário acessa um objeto em cache, o segundo requer uma busca e/ou trabalho extra do servidor. De fato, em muitos sites, não é incomum encontrar três picos: na resposta do cache do cliente, no cache do servidor, e um render completo no servidor.

Finalmente, porque os dados moram em GA, agora nós podemos também decompô-los e analisá-los com relação a qualquer número de dimensões do visitante: continente, cidade, versão do navegador, e assim por diante. Se você não está familiarizado com os segmentos avançados em GA, então agora é uma boa hora para isso. Por exemplo, como é que um novo visitante (cache cold) de Pequim se compara a uma visitante de San Francisco?

Compreendendo o “formato dos dados”

Se o seu trabalho é pensar sobre o desempenho, então você precisa abordar isso de uma perspectiva dos usuários: redes são esquisitas, caches são pequenos, dispositivos são lentos, e a renderização DOM é bem complicada. O Navigation Timing é uma peça fundamental que vai nos ajudar a juntar tudo isso. O Google Analytics fornece algumas excelentes ferramentas para dar sentido a esses dados, mas eu estou esperando para ver muito mais dessa área no futuro.

Nós precisamos de ferramentas que nos permitam compreender o desempenho do nosso site a partir da perspectiva de um usuário real, e ferramentas que consigam ir além de apenas calcular a média. Afinal, uma média de um skewed, ou uma distribuição multi-modal nos diz muito pouco: aprofunde-se nos dados, entenda a forma dela e otimize a partir daí.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.igvita.com/2012/04/04/measuring-site-speed-with-navigation-timing/