O usuário inicia uma navegação, e o navegador está ocupado: ele provavelmente vai ter que resolver uma dúzia de DNS, estabelecer um número ainda maior de conexões e, em seguida, enviar um ou mais pedidos para cada um. Por sua vez, para cada request, muitas vezes o tamanho da resposta é desconhecido (transferências fragmentadas) e, mesmo quando se sabe, ele ainda não é capaz de prever com segurança o tempo de download devido às variações de rede, ao tempo de processamento do servidor, e assim por diante. Finalmente, a obtenção e o processamento de um recurso podem desencadear uma subárvore inteira de novas requisições.

Ok, então o carregamento de uma página é um negócio complicado, e daí? Bem, se não há nenhuma maneira de prever com segurança o tempo que a página pode demorar para carregar, então por que tantos navegadores ainda usam e mostram a barra de progresso? Na melhor das hipóteses, o indicador de 0-100% é uma mentira que engana o usuário; pior, os critérios de sucesso forçam os desenvolvedores a otimizar o “tempo onload”, que diminui a experiência progressiva de renderização que os aplicativos modernos têm o objetivo de entregar. Barras de progresso no navegador falham para usuários e desenvolvedores; podemos e devemos fazer melhor.

Indicadores indeterminados na era pós-onload

Para ser claro, indicadores de progresso são vitais para ajudar o usuário a entender que uma operação está em andamento. O navegador precisa mostrar alguma forma de um indicador de “ocupado”, e as questões importantes são: o tipo de indicador, se o progresso pode ser estimado, e que critérios são usados ​​para acionar a sua exibição.

Alguns navegadores já substituíram “barras de progresso” por “indicadores indeterminados” que abordam a pretensão de tentar prever e estimar algo que eles não podem. No entanto, esse tratamento é inconsistente entre diferentes navegadores e até mesmo em navegadores da mesma marca, mas em plataformas diferentes – por exemplo, muitos navegadores móveis usam barras de progresso, ao passo que os seus análogos para desktop usam indicadores indeterminados. Precisamos corrigir isso.

Além disso, já que estamos falando disso, quais são as condições que desencadeiam um indicador de “ocupado” do browser? Hoje, o indicador é apresentado apenas quando a página está carregando: é ativo até que o evento onload seja acionado, o que deveria indicar que a página terminou de buscar todos os recursos e agora está “pronta”. No entanto, em um mundo otimizado para renderização progressiva, esse é um conceito cada vez menos útil: a presença de uma solicitação pendente não significa que o usuário não pode ou não deve interagir com a página; muitas páginas adiam a obtenção e postergam o processamento até depois do onload e outras tantas fazem a obtenção e o processamento baseado na interação do usuário.

O tempo de onload é uma métrica de desempenho ruim e que os desenvolvedores têm jogado por um tempo, fFazendo com que os critérios de sucesso para o indicador de “ocupado” pareça ser uma decisão que vale a pena rever. Por exemplo, em vez de confiar no que é agora um marco de inicialização arbitrária, e se isso representasse a capacidade da página de aceitar e processar a interação do usuário?

• Será que a página possui conteúdo visível e pronto para aceitar a interação (por exemplo, toque, rolagem)? Ocultar o indicador de “ocupado”.
• A thread de UI está ocupada (ver Jank), devido a um longo processo do JavaScript ou outro trabalho? Mostrar o indicador de “ocupado” até que essa condição seja resolvida; o indicador de “ocupado” pode ser mostrado em qualquer ponto do ciclo de vida da aplicação.

O carregamento da página inicial é simplesmente um caso especial de pintar o primeiro frame (de preferência em <1000 ms), no momento em que a página é incapaz de processar a interação do usuário. Publique o primeiro frame, se a thread da UI estiver ocupada mais uma vez, então o navegador pode e deve mostrar o mesmo indicador. Mudando o indicador de “ocupado” para sinalizar interatividade resolveria nossos problemas existentes com a penalizar renderização progressiva, remover a necessidade de continuar o onload e criar incentivos diretos para que os desenvolvedores construam e otimizem para experiências livres de Jank mais suaves.

***

Ilya Grigorik faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://www.igvita.com/2015/06/25/browser-progress-bar-is-an-anti-pattern/