Há um elefante na sala que estamos ignorando há anos: window.onload não é a melhor métrica para medir a velocidade do site.

Nós não temos realmente “ignorado” essa questão. Nós já reconhecemos isso, mas não temos coordenado nossos esforços para chegar a um melhor substituto. Vamos fazer isso agora.

window.onload é tão Web 1.0

O que estamos procurando é uma métrica que capta a percepção do usuário de quando a página está pronta. Infelizmente, perception.ready() não está no roteiro de nenhum browser. Então, precisamos encontrar uma métrica que seja um bom proxy.

Dez anos atrás, window.onload era um bom proxy para a percepção do usuário de quando uma página estava pronta. Naquela época, as páginas eram principalmente HTML e imagens. JavaScript, CSS, DHTML e Ajax eram menos comuns, assim como os atrasos e bloqueios de renderização que eles introduziram. Não foi perfeito, mas window.onload estava perto o suficiente. Além disso, ele tinha outros atributos desejáveis:

• padrão em todos os navegadores – window.onload significa a mesma coisa em todos os navegadores. (A única exceção de que eu estou ciente é que o IE 6-9 não espera scripts assíncronos antes de disparar window.onload, enquanto a maioria dos outros navegadores o fazem.)
• mensurável por terceiros – window.onload é um marco na página que pode ser medida por outra pessoa que não o dono do site, por exemplo, os serviços de métricas como Keynote Systems e ferramentas como Boomerang. Ele não requer proprietários de sites para adicionar o código personalizado para suas páginas.
• mensurável para usuários reais – medir window.onload é uma operação leve, para que possa ser realizada em tráfego de usuários reais, sem prejudicar a experiência do usuário.

Web 2.0 é mais dinâmica

Avançando para hoje, vemos que window.onload não reflete a percepção do usuário, como ele já fez antes.

Existem alguns casos em que um website renderiza rapidamente, mas o window.onload dispara muito mais tarde. Nessas situações, a percepção do usuário da página é rápida, mas o window.onload diz que a página é lenta. Um bom exemplo disso são páginas de produtos da Amazon. A Amazon fez um grande trabalho de obter o conteúdo que está acima da dobra para renderizar rapidamente, mas todos os comentários abaixo da dobra e recomendações produzem um alto valor de window.onload. Olhando para estes resultados da WebPagetest para a Amazon, vemos que acima da dobra é quase completamente renderizado em 2 segundos, mas o window.onload não acontece até 5,2 segundos. (Os tamanhos relativos das barras de rolagem mostram que uma grande quantidade de conteúdo foi adicionada abaixo da dobra).

Amazon – 2s (~90% renderizados)/Amazon 5,2s (onload)

Mas o oposto também é verdadeiro. Sites altamente dinâmicos carregam muito da página visível após o window.onload. Para esses sites, o window.onload relata um valor que é mais rápido que a percepção do usuário. Um bom exemplo desse tipo de aplicação web dinâmica é o Gmail. Olhando para os resultados da WebPagetest para o Gmail, vemos que o window.onload é de 3,3 segundos, mas naquele momento só a barra de progresso é visível. O conteúdo acima da dobra se encaixar em 4,8 segundos. É claro que nesse exemplo o window.onload não é uma boa aproximação para a percepção do usuário de que a página está pronta.

É sobre redenrização, não downloads

Os exemplos acima não são destinados a mostrar que a Amazon é rápida e que o Gmail é lento. Também não é a intenção dizer que todo o conteúdo deve ser carregado antes ou depois do window.onload. O ponto é que os sites de hoje são muito dinâmicos para ter sua velocidade percebida com precisão pelo window.onload.

A razão é porque o window.onload é baseado em quando os recursos da página são baixados. Nos velhos tempos, de apenas texto e imagens, a disponibilidade do conteúdo da página estava intimamente ligada aos seus recursos de downloads. Mas com a crescente dependência de JavaScript, CSS, Ajax, a velocidade percebida dos sites atuais é melhor refletida quando o conteúdo da página é processado. O uso do JavaScript e CSS está crescendo. À medida que a adoção dessas técnicas dinâmicas aumenta, o mesmo acontece com a diferença entre o window.onload e a percepção do usuário da velocidade do website. Em outras palavras, o problema só vai piorar.

A conclusão é clara: a substituição para o window.onload deve se concentrar na renderização.

Como “isso” parece

Essa nova métrica de desempenho deve levar em consideração a renderização. Ela deve capturar quando o conteúdo acima da dobra é (principalmente) renderizado.

Estou ciente de duas métricas de desempenho que existem hoje, que estão focadas em renderização. Ambas estão disponíveis em WebPagetest. Tempo de renderização acima da dobra (PDF) foi desenvolvido pelo Google. Ele encontra o ponto em que o conteúdo da página chega à sua renderização final, com a inteligência de se adaptar para GIFs animados, streaming de vídeo, anúncios rotativos etc. A outra técnica, chamada de Speed Index e desenvolvida por Pat Meenan, dá o “tempo médio em que partes visíveis da página são exibidas”. Ambas as técnicas usam uma série de imagens para fazer a sua análise e têm a complexidade computacional que vem com a análise da imagem.

Em outras palavras, não é possível executar essas métricas de renderização sobre o tráfego de usuário real em sua forma atual. Isso é importante porque, além da incorporação de renderização, essa nova métrica deve manter os atributos mencionados anteriormente que fazem o window.onload tão atraente: padrão em todos os navegadores, mensuráveis por terceiros, e mensuráveis para usuários reais.

Outra grande desvantagem para o window.onload é que ele não funciona para aplicações web de uma página (como o Gmail). Esses aplicativos web têm apenas um window.onload, mas normalmente têm vários outros “page loads” baseados em Ajax durante a sessão do usuário, onde alguns ou a maioria do conteúdo da página é reescrita. É importante que essa nova métrica funcione para aplicativos Ajax.

Tome a iniciativa

Eu entendo completamente se você estiver frustrado com minha falta de detalhes de implementação. Medir renderização é complexo. O ponto em que a página é (praticamente) renderizada é bastante óbvio quando você verifica em uma série de prints da tela em WebPagetest. Escrever o código que mede isso de uma maneira consistente é realmente difícil. Um colega de trabalho me mostrou essa thread do W3C Web Performance Working Group, falando sobre medir a primeira pintura que destaca alguns dos desafios.

Para piorar a situação, a nova métrica que estou discutindo é provavelmente muito mais complexa de medir a primeira pintura. Acredito que precisamos medir quando o conteúdo acima da dobra é (principalmente) renderizado. O que exatamente é “acima da dobra”? O que é “principalmente”?

Outro desafio está levando a comunidade para longe do window.onload. O desempenho principal da métrica em ferramentas populares como WebPagetest, Google Analytics Site Speed, Torbit Insight, SOASTA (LogNormal) mPulse, e meu próprio HTTP Archive é window.onload. Ouvi dizer que algumas pessoas de TI ainda têm seus bônus com base nas métricas do window.onload relatadas por serviços como Keynote Systems e Gomez.

Vai levar algum tempo para definir, implementar e transitar para um melhor desempenho métrico. Mas temos que fazer a bola rolar. Basear-se em window.onload como a métrica de desempenho principal não produz necessariamente uma experiência mais rápida para o usuário. E ainda assim fazer os nossos sites mais rápidos para os usuários é o que estamos realmente buscando. Precisamos de uma métrica que acompanhe com mais precisão o nosso progresso em direção a esse objetivo final.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/