Pensar sobre a performance de uma página Web é algo difícil. O que exatamente é um site rápido? Qual o tempo ideal para o site carregar? O que é “carregar”? Como medir que seu site está rápido? Quem te fala que seu site está rápido?

Performance é UX. Quem te fala se seu site está rápido ou não é o usuário. Velocidade depende mais da percepção do usuário que do número medido no cronômetro.

Antigamente, a gente estava acostumado a medir o carregamento a partir do onload da página. Mas ele não serve mais. Coisas assíncronas não contam no onload. Sites complexos, como SPAs, continuam rodando mesmo depois do onload.

E o onload não representa a experiência real do usuário. Como estamos falando de percepção, para o usuário não interessa muito quando a página toda terminou de carregar. Se ele puder começar a interagir com sua página logo, não vai ligar se você ainda estiver carregando alguma coisa lá no rodapé, por exemplo.

Além disso, temos que pensar em que tipo de performance estamos falando. É só o carregamento que conta? Em páginas modernas, podemos ter animações, por exemplo, que precisam ser executadas de forma performática. Tem também a performance das interações do usuário – quanto tempo entre eu clicar em algo e acontecer alguma coisa?

Percepção de performance

Se a questão toda é como o usuário percebe a performance do meu site, então como isso acontece? Apelemos para a neurociência. Estudos tão antigos quanto 1968 já se preocupavam em medir objetivamente os tempos de resposta aceitáveis para o cérebro humano ao interagir com computadores. Estudos esses que foram depois confirmados em pesquisas mais recentes.

Chegou-se a conclusão que existem 3 limites de tempo que desencadeiam respostas neurológicas diferentes nas pessoas. Se eu quero executar uma tarefa e ela demora X tempo, a ideia é que meu cérebro percebe isso de uma forma específica.

• Ações com respostas da ordem de 0.1s são percebidas pelo cérebro como instantâneas. Aperto um botão e o sistema pode demorar até 100ms que eu não noto a demora.
• Já quando a reação demora por volta de 1s para acontecer, meu cérebro já nota a demora, a sensação não é de instantaneidade. Mas eu ainda percebo aquilo como uma única tarefa, percebo a conexão entre minha ação e a reação do sistema. Tudo faz parte de um mesmo fluxo de pensamento.
• Até por volta de 10s o cérebro consegue, com muito esforço, esperar. Esse é o limite aproximado pro quanto conseguimos segurar a atenção do usuário. Mais que isso, e ele se perde totalmente.

Esses 3 números mágicos – 0.1s, 1s, 10s – são uma base para se pensar nos limites neurológicos de percepção de performance. E como tratam de neurociência, já se concluiu que eles se mantêm os mesmos nos últimos 50 anos.

Percepção de performance em páginas Web

Como aplicar esses conceitos na Web? Bom, parece óbvio que não queremos uma página carregando por mais de 10s. O usuário digita o endereço e, se demoramos 10s para carregar, sua atenção já era – lá está ele vendo o Whatsapp no celular. O santo graal seria carregar páginas em 100ms, mas isso parece bastante impossível dada a arquitetura online da Web.

A comunidade de performance front-end hoje persegue o número de 1s. Carregar a página em 1s seria perfeito para o usuário. Mas é um número bem difícil.

A questão na verdade é entender o que significa carregar em 1s. Lembre que estamos falando de percepção, não exatamente de tempo de cronômetro. O consenso é que queremos que o site pareça carregado em 1s. Em geral, isso significa priorizar e carregar o conteúdo antes da dobra, aquilo que aparece antes do primeiro scroll. É isso que dá a sensação inicial de página carregada. Aquela imagem no rodapé? Não importa muito se ela demora mais alguns segundos.

O importante é priorizar o conteúdo inicial e deixá-lo disponível para uso em 1s. Em conexões 3G, a comunidade de performance chegou num consenso de dar um desconto para 3s, dado que só a latência de abertura da conexão pode levar um tempão (e uma métrica legal para medir tudo isso é o SpeedIndex, sobre o qual já escrevi antes).

Além do carregamento

Outros aspectos de performance do site vão ter outras expectativas. Por exemplo, quando clico em um botão, a expectativa é que ele responda instantaneamente. Quem já teve o famoso problema do double submit – você clica, não sabe direito se foi e clica de novo. O problema é que, para parecer instantâneo, o botão precisa reagir em 100ms.

Não necessariamente completar sua tarefa nesse tempo. Mas dar algum feedback visual de que o clique foi registrado. Seja um efeito ou, se a tarefa for demorar demais, o aparecimento de um loader qualquer.

Queremos deixar as interações do usuário o mais próximas de 100ms quanto possível. E o resto? Animações por exemplo.

No caso das animações, os gamers já sabem qual a expectativa do usuário para um efeito fluído: 60FPS. Rodá-la a 60 quadros por segundo, que é a taxa de atualização da maioria dos monitores modernos (60Hz). Não é uma tarefa fácil; envolve saber trabalhar com aceleração de GPU e outros truques. Mas é a expectativa do usuário.

Performance é UX

O ponto é que pensar em performance é essencialmente pensar em experiência do usuário. Mais do que números, é pensar em como o usuário percebe a performance. E usar isso a nosso favor. Não faz sentido otimizar um clique para muito menos que 100ms por exemplo, já que nosso cérebro tem esse limite de percepção.

E podemos usar outros truques para enganar o cérebro e fazê-lo perceber uma performance melhor mesmo que o número do cronômetro em si não seja tão bom.

Uma anedota antiga da época do falecido Google Reader conta que o time fez uma única mudança: o background que era azul foi para branco. E choveram elogios dos usuários dizendo como o site estava mais rápido! Como? Percepção. Como o fundo padrão dos navegadores é branco, a página usar branco também fez com que desse a sensação de ter começado a carregar antes. Incrível como a mente funciona.

Outro caso mais recente aconteceu no Blogger. O wizard de criação de novos blogs estava super otimizado. O usuário preenchia os dados – nome, URL etc -, clicava no botão e na hora seu blog estava no ar. Mas o pessoal do Blogger notou que muita gente voltava e fazia tudo de novo. Porque?

Estudando a fundo concluíram que criar um blog não é uma tarefa corriqueira. A pessoa passa um tempão pensando até tomar essa decisão importante para vida dela: vou criar meu blog. Passa um tempo pensando no nome, na URL, preenche e confere com carinho aquele formulário. E aí toma aquele passo importante: clica no botão Finalizar. E… pimba, pronto, tá criado? Não pode ser, criar um blog é algo muito importante mim, não pode ser trivial assim pro Blogger.

A expectativa de performance do usuário estava incompatível com o que acontecia. A solução? Colocaram um delay proposital de 2s com um loader após o clique do botão. E tudo melhorou. Ele não faz nada, só dá um tempo para cabeça do usuário processar aquele momento. Performance é UX.