Fiz uma pesquisa sobre a percepção da velocidade para a minha palestra no Ignite Velocity. A percepção da velocidade do site é, obviamente, alimentada pelo o que o usuário vê no navegador. Embora o conteúdo do site seja controlado pelo proprietário do site, o navegador também fornece feedback para o usuário. Esse feedback afeta a percepção do usuário da velocidade do website. Bons desenvolvedores precisam entender como o seu código afeta o que os usuários veem, incluindo o feedback do navegador que é acionado (ou não acionado).

Indicadores

Vamos começar enumerando os mecanismos de feedback do navegador. Eu identifiquei seis formas através das quais os navegadores dão feedback quando eles estão ocupados fazendo alguma ação:

1. tab icon – Isso é tipicamente o favicon do site. Acontece um spinner quando a aba está carregando.
2. status bar – Alguns navegadores exibem uma mensagem sobre pedidos pendentes na barra de status.
3. reload icon – Esse ícone (normalmente uma seta circular) muda para um “X” durante o download.
4. progress bar – Alguns navegadores têm uma barra de progresso. Opera mostra a fração de downloads concluídos:
5. network busy – O iOS mostra um indicador de carregamento do navegador sempre que há tráfego de rede. (Tecnicamente isso está fora do navegador, mas eu o incluí, já que é uma forte sugestão visual no topo da tela.)
6. cursor – Em algumas situações, o cursor muda para um “cursor de progresso”.

Cenários de teste

Os indicadores de carregamento do navegador são acionados durante a navegação web normal, como clicar em links. Eles também são desencadeados por alguns dos comportamentos dinâmicos populares em páginas web de hoje. Eu elaborei esta lista de cenários para medir indicadores de carregamento do navegador:

• Clique em links – Clique em um link para outra página web.
• Script assíncrono – O documento HTML contém <SCRIPT ASYNC SRC=”…”>.
• Script dinâmico, antes do onload – O documento HTML carrega um script usando document.createElement (‘script’) e appendChild ().
• iframe dinâmico – Clicar em um botão inicia o carregamento de um iframe usando document.createElement (‘iframe’) e appendChild ().
• Script dinâmico – O mesmo que o iframe dinâmico, mas com um script.
• Folha de estilo dinâmica – O mesmo que o iframe dinâmico, mas com uma folha de estilo.
• Imagem dinâmica – O mesmo que o iframe dinâmico, mas com uma imagem.
• Imagem de background dinâmica – O mesmo que o iframe dinâmica, mas com uma imagem de fundo com CSS.
• XHR – Clicar em um botão inicia um XMLHttpRequest.
• Loop em JS demorado – Clicar em um botão inicia algum JavaScript que circula por alguns segundos.

Eu escolhi esses cenários para simular situações do mundo real. Por exemplo, muitos aplicativos web usam XHR – eles acionam algum indicador de carregamento do navegador? Carousels muitas vezes buscam imagens de forma dinâmica – o usuário obtém qualquer feedback do navegador quando isso acontece?

Você pode ver o código específico para cada cenário nesta página de teste. Executei cada cenário nos principais navegadores e salvei os resultados em um teste de usuário no Browserscope.

Resultados

Muitos dos casos de teste não desencadeiam qualquer um dos indicadores de carregamento do navegador: script dinâmico, folha de estilo dinâmica, imagem dinâmica, imagem de background dinâmica, XHR, e loop em JS demorado. (Exceto no iOS, o indicador de carregamento foi acionado para cada teste que envolvia uma solicitação HTTP.) Eu não incluí esses testes na tabela de resultados. Os resultados para clique em links, script assíncrono, script dinâmico antes do onload e iframe dinâmico são mostrados na tabela a seguir.

navegador	clique em links	script assíncrono	script dinâmico antes do onload	iframe dinâmico
Chrome 27 (Mac OS)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Chrome 27 (Windows)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Firefox 21 (Mac OS)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Firefox 21 (Windows)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
IE 9 (Windows)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Opera 12 (Mac OS)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Opera 12 (Windows)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Safari 6 (Mac OS)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Safari 5 (Windows)	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Mobile:
Android 4	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Chrome Mobile 26	TSCPRN	TSCPRN	TSCPRN	TSCPRN
Mobile Safari 6	TSCPRN	TSCPRN	TSCPRN	TSCPRN

Cada resultado é essencialmente uma máscara de bits que aponta se o indicador de carregamento do navegador foi acionado. Por exemplo, o primeiro resultado para “Chrome 27 (Mac OS)” e do teste de “clique em links” é TSCPRN. Isso significa que os indicadores tab icon, status bar e reload icon foram acionados, mas os indicadores cursor, progress bar e network não foram acionados. Algumas notas sobre os indicadores:

• O indicador network é aplicável apenas para o Safari Mobile.
• O indicador progress bar só é aplicável para Opera, Safari, Android, Chrome Mobile e Safari Mobile.
• Navegadores móveis não têm tabs, status bars, nem cursores (atualmente), então esses indicadores não são aplicáveis.

Considerações finais

O objetivo desses testes é ver como os indicadores de carregamento do navegador podem afetar a percepção do usuário de velocidade em diferentes cenários. Os próprios testes são inventados, mas é fácil (e necessário) colocá-los no contexto de uma página web.

Por exemplo, se um recurso envolve um pedido JSON, que técnica deve ser usada? Esses indicadores de carregamento do navegador fornecem algumas orientações. Se os dados JSON são assíncronos para a experiência do usuário, como atualizar as cotações de ações ou status online de amigos, então seria melhor não acionar os indicadores de carregamento do navegador. Fazer isso faria com que o usuário fizesse uma pausa em suas ações atuais e imaginasse o que a página web estaria fazendo. Por outro lado, se o recurso foi síncrono para a experiência do usuário, como abrir uma pasta de e-mail, então seria melhor dar ao usuário o feedback de que a ação estava sendo realizada.

Nesse contexto, nota-se que a técnica de iframe dinâmico desencadeia indicadores de carregamento do navegador em alguns. Portanto, essa seria uma má escolha para tarefas de background. E se ele foi escolhido para a ação síncrona, deve ser aumentado para fornecer feedback em todos os navegadores (como um ícone de progresso ou indicador de carregamento).

Um dos maiores pontos, para mim, foi que o cursor de progresso só é acionado no Windows. Acho que esse é um mecanismo de feedback primário ao usar o mouse – especialmente quando se clica em um link. Esses comentários no Mozilla Bugs parecem apontar para uma guideline de design do Mac OS. Acho que é uma distração no Mac OS ter que mover meus olhos para longe de onde estou focando a fim de obter o feedback de que o meu clique foi “ouvido”.

Das técnicas que não acionaram o indicador de carregamento, praticamente todas de carregamento dinâmico se enquadram nessa categoria, sendo a exceção o iframe dinâmico. (Por “carregamento dinâmico”, eu quero dizer usar JavaScript para iniciar a solicitação HTTP.) Isso é bom e ruim. Muitas vezes, imagens dinâmicas são utilizadas para guiar métricas e informações de registro. É bom saber que esses guias não estão interferindo com a experiência do usuário. Por outro lado, se um recurso síncrono carrega os scripts de forma dinâmica, pode ser necessário fornecer outros feedbacks para o usuário de que a ação está sendo realizada.

Esses indicadores têm um impacto na percepção da velocidade do website pelo usuário. Acionar o indicador de carregamento do navegador para ações que deveriam estar em segundo plano chama a atenção do usuário, tornando a experiência mais lenta. Se a ação de um usuário é síncrona, mas não há feedback, isso é frustrante e faz a experiência parecer mais longa do que realmente é. Nós podemos produzir melhores experiências do usuário, levando em consideração essas compensações e evitando-as ou aumentando-as, dependendo da situação.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.stevesouders.com/blog/2013/06/16/browser-busy-indicators/