Porque você não deveria ligar para o tempo do onload (ou: as métricas que importam para performance real na Web)

Um site rápido é um site que passa a sensação de rapidez para o usuário. No fundo, performance é UX e quem diz se o site é rápido ou não é seu usuário.

Mas como bons desenvolvedores com cabeças analíticas e lógicas, queremos uma resposta exata para “Quanto meu site é rápido?” Ou ainda “Como medir a performance do meu site?” ou “Me dê uma nota de performance”.

Na comunidade de performance front-end, 1 segundo é tido como o número mágico. O santo graal. Se seu site carregar em menos de 1 segundo, ele é rápido. Mas como medir?

Você pode usar várias ferramentas de análise de performance para obter números interessantes. Eu gosto bastante do WebPageTest, mas há também o PageSpeed, YSlow e tantos outros. Você pode, por exemplo, medir o tamanho total da página em KB (e tentar diminuir o peso das coisas se a página estiver grande demais). Ou medir quantos requests estão sendo feitos (e concatenar arquivos pra aliviar).

Screenshot 2015-05-22 19.24.40

Mas fato é que nem tamanho da página nem número de resquests te dizem se a página é rápida ou não. Claro, são métricas relacionadas a experiência final do usuário. Mas são números que, sozinhos, não dizem nada.

Porque o onload não serve – e nem o DOMContentLoaded

Uma métrica historicamente usada para saber o tempo de carregamento é esperar o evento onload. O navegador dispara esse evento quando a página termina de carregar (seus CSS, JS, imagens, etc). Parece um bom número pra ficar de olho. Na imagem anterior, que mostra números do site da Caelum, o Load Time indica 2.1s. Parece bem longe do 1s ideal.

Mas o onload não serve muito. Primeiro porque nos sites de hoje muita coisa acontece depois do onload. Carregamos coisas assíncronas, Ajax diversos e coisas assim. Na imagem mesmo, note que há um outro número, o Fully Loaded, que é maior ainda – 2.4s – e indica quando acaba de carregar tudo, mesmo depois do onload.

O pior problema do onload, porém, é que ele não está relacionado de forma alguma a experiência real do usuário. Saber que todas as imagens acabaram de carregar em X segundos não interessa tanto, se você pensar que isso inclui até aquela imagenzinha no rodapé, pouco útil para o usuário.

Aliás, outro evento, o DOMContentLoaded, indica quando o DOM está pronto. Dispara antes do onload, afinal não espera os outros componentes chegarem. Mas também sofre dos mesmos problemas e não serve de indicativo.

Observando quadro a quadro

Um aspecto que influencia bastante a experiência real do usuário é quanto tempo ele fica encarando uma tela em branco. Quanto mais tempo demora para aparecer algo na tela, pior a sensação de lerdeza. Aliás, é por isso que carregamos as coisas assincronamente, por exemplo.

No WebPageTest você pode pedir para gravar um vídeo da experiência do usuário de acordo com o tempo:

Parece rápido, mas podemos analisar também quadro a quadro de acordo com o tempo:

filmstrip

Repare que o site começa a ser desenhado já em 0,6s. Antes disso, muita tela em branco.

A métrica Start Render

Se olhar de novo a tabela dos números, vai reparar que existe uma métrica Start Render indicando 0.596s. Esse número é justamente o que reparamos no vídeo anterior: que a página começa a ser renderizada na tela a partir daí.

Screenshot 2015-05-22 19.24.40

O Start Render é uma métrica bastante útil e reflete o início da experiência real do usuário. Esse número deve ser bem baixo. Poucas centenas de milissegundos. O valor de 600ms do exemplo do site da Caelum já é alto. Se der, diminua mais.

O Speed Index

Claro que só olhar o Start Render não diz tudo. Ele fala só do início da percepção de performance. Mas se olhar o onload completo também não diz nada, o que devemos olhar? Foque na experiência inicial do usuário.

Pense: se eu abrir o site da Caelum sem cronometrar nada, qual indício me diz que a página carregou? Olhando no quadro a quadro acima, repare que em 0,9s o site já parece usável. Mesmo o onload demorando 2,4s, em apenas 900ms o usuário já tem a sensação de carregamento total.

Porque isso? Porque o conteúdo inicial da página, aquele antes da dobra (above the fold) já foi todo carregado. Visualmente ele já está desenhado na tela. Nem me interessa se o rodapé já carregou por exemplo. Ou se existe algum outro pedaço da página lá embaixo ainda a ser carregado. No site da Caelum, por exemplo, há um widget do Facebook duas scrolladas pra baixo que carrega assincronamente. Ele é o principal culpado do nosso onload ir para 2,4s. Mas, como usuário, você não liga pra isso quando abre a página. E fica feliz que tudo parece carregado em apenas 900ms.

Medir o tempo para o conteúdo antes da dobra aparecer na tela é o que faz o Speed Index. Essa métrica, criada pelo WebPageTest, faz uns cálculos complexos analisando as imagens da tela para chegar em um número exato. Ele indica, em milissegundos, quando a parte superior do site parece visualmente estável para o usuário.

É uma excelente métrica que diz mais sobre a experiência real do usuário na página. O ideal é ficar abaixo de 1000 sempre. O número mágico da performance. Carregar a página em menos de 1 segundo.

Nesta análise do site da Caelum conseguimos 821. Isso quer dizer que após 821ms o usuário já vê o topo do site todo e pode interagir. Mesmo que haja conteúdo secundário ainda sendo carregado lá embaixo.

Otimize as métricas certas

Se seu objetivo com performance é agradar o usuário, invista maior parte do tempo otimizando o Start Render e o Speed Index. Não gaste tempo pensando no onload ou no número de requests em si. O tamanho da página é legal otimizar pensando em 3G, pra não acabar com o plano de dados do usuário. Mas a percepção de performance em si está no Speed Index.

Falando em mobile, é claro que um Speed Index de 1000 seria ótimo. Mas é quase utópico. A comunidade de performance considera 1000 um número bom para Desktop e 3000 um número bom para mobile em 3G. .

No WebPageTest, você pode testar em dispositivos móveis reais (um Moto G, por exemplo) em redes com velocidade e latência iguais de 3G. Aliás, esse costuma ser um teste de abrir os olhos. É bem difícil fazer um site rodar bem no mobile. E muita gente não faz ideia de como seu próprio site é ruim no 3G.

O site da Caelum consegue 2300, com um Start Render 2s (veja o teste). É um site bastante otimizado já. Mas há espaço para melhorias.

E você, como mede a performance dos seus sites? Indica outra ferramenta? Qual seu SpeedIndex?

6 Comentários

  1. Arthur Carvalho 07/07/2015 at 10:23 #

    Olá Sérgio,

    Novo tópico pra mim que mesmo usando o webpagetest, nunca tinha reparado o ‘Speed Index’. Estava sempre atento em reduzir número de requests, otimizar imagens, tempo de onload – e claro, muitos outros números. Vou ler sobre o Speed Index – que dentre as métricas do webpagetest, é a única que possui uma página só pra ela.

    Você comenta também sobre comunidade de perfomance… Quais lugares você costumer ler sobre o assunto?

    Excelente post, você comentar performance sempre acrescenta bastante conhecimento a aqueles interessados no assunto. Valeu!!

  2. Sérgio Lopes 07/07/2015 at 13:50 #

    Pra complementar: um post bastante recente com explicacoa detalhada do SpeedIndex:

    https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/june/speed-index–how-it-works-and-what-it-means/

    @Arthur: Sou mega fã do perfplanet, que agrega muitos autores que costumam falar de performance. http://www.perfplanet.com/

  3. Leandro Nunes 07/07/2015 at 15:49 #

    Boa Sérgio!
    Venho em busca desse speedIndex < 1000 há tempos, porém em projetos comerciais tenho algumas dificuldades. O principal "calcanhar de aquiles" que identifico é o sdk do Facebook e o embed do TagManager.
    O Facebook é relativamente tranquilo de contornar… mas o analytics ainda não achei uma "bala de prata"!
    Você possui alguma dica em relação ao analytics? Já que postergar seu carregamento provavelmente irá impactar em alguma métrica perdida imagino eu…

    Ótimo artigo!
    []s

  4. Sérgio Lopes 07/07/2015 at 16:12 #

    @Leandro
    Eu não gosto muito do Tag Manager. Como ele cria uma camada a mais de indireção, demora mais pra carregar. Entendo as vantagens de manutencao, mas nao gosto da perda de performance.

    Dito isso, eu uso o Analytics direto no HTML. E ele ja é assincrono por natureza, entao nao prejudica a performance. Ele nao afeta tanto o speed index nao. O facebook sim, mas ai carrega lazy tbm.

  5. Anderson Aguiar 28/07/2015 at 10:12 #

    Parabéns pelo post Sérgio, compartilho da mesma visão.

    Devemos focar principalmente na experiência do usuário, claro que também devemos reduzir requests e o tamanho de nossos assets, pois isso consequentemente trará um ganho para os usuários e também para a empresa se estivermos falando de um grande volume de acessos.

  6. Wellington Soares 04/09/2015 at 10:44 #

    Oi, Sergio,

    Ótimo post! Dá uma olhada nesse posts:
    http://techblog.netflix.com/2015/08/making-netflixcom-faster.html
    http://www.stevesouders.com/blog/2015/08/07/dominteractive-is-it-really/

    PS: Acabei te vendo no QConRio2015 e nem tive a chance de conversarmos :/

Deixe uma resposta