Recentemente, tuitei que as chaves para um aplicativo web mais rápido eram arquitetura do Ajax, JavaScript, e caching. Essa afirmação é baseada na minha experiência – não possuo dados concretos sobre a contribuição que cada uma faz e as economias que poderiam elas podem oferecer. Mas vou comentar sobre cada uma.

• Arquitetura do Ajax – A Web 1.0 com uma página tendo que ser recarregada em cada ação do usuário não é a escolha certa. Empurrar a página para fora do usuário e recarregar os recursos que não foram alterados acaba produzindo uma experiência de usuário frustrante. Manter uma interface de usuário no Chrome constante com um web app 2.0 é mais direto, e o Ajax nos permite realizar as atualizações de conteúdo por meio de solicitações de API com dados leves e clientside JavaScript, resultando em um aplicativo web bom e rápido (quando feito corretamente).
• JavaScript – O JavaScript é o maior e mais importante pilar na tenda de desempenho da web, mas há apenas alguns anos atrás era ainda pior. Você se lembra?! Ele costumava ser aquele que carregava um script, bloqueava o analisador HTML e todos os outros downloads na página. Os scripts eram baixados um-de-cada-vez!!! Em 2009, o IE8 o tornou-se o primeiro browser a suportar o carregamento de script paralelo. Firefox 3.5, Chrome2, Safari 4 e logo seguiram os mesmos passos e, mais recentemente, o Opera 12 entrou na jogada. (O carregamento de script paralelo é a melhoria mais importante para o desempenho IMO da web.) Além de scripts de carregamento, a velocidade dos mecanismos de JavaScript em si tem aumentado significativamente. Então, nós estamos muito melhores do que estávamos há alguns anos atrás. Mas quando eu faço mergulhos mais profundos no desempenho em sites mais importantes, o JavaScript ainda é o motivo mais frequente de páginas e renderização especialmente lentas. Isso se deve a vários fatores. Os payloads do JavaScript aumentaram para ~ 200K. Os navegadores ainda têm um comportamento de bloqueio em torno do JavaScript, por exemplo, um stylesheet seguido por um script inline pode bloquear downloads subsequentes em alguns navegadores. E até termos um apoio mais amplo para a valorização progressiva, muitas páginas estão em branco enquanto esperam um payload pesado de JavaScript ser baixado, analisado e executado.
• Caching – Um cache melhor não torna os sites mais rápidos para usuários iniciantes. Mas, no contexto de aplicativos web, estamos falando de usuários que estão envolvidos em uma sessão mais longa e que estão propensos a voltar a usar esse aplicativo novamente. Na viagem para criar experiências de aplicativo web que rivalizam com os de desktop e nativos, o cache é um ingrediente chave. Armazenamento em cache me frustra. Os proprietários de websites não usam o armazenamento de cache tanto quanto deveriam. 58% das respostas não têm armazenamento de cabeçalhos, e 89% são armazenáveis por menos de um mês, embora 38% das pessoas não mudarem. As memórias em cache do navegador são muito pequenas e os seus algoritmos purgativos necessitam de atualização. Temos localStorage com uma API super simples, mas os fabricantes de browsers alertam que é ruim para o desempenho. Cache de aplicativos é uma solução mais pesada, com a qual é difícil trabalhar (ver também a grande apresentação de Jake Archibald).

Sou obcecado com cache, que acredito que é uma grande oportunidade, mas ainda muito mal aproveitada. Analisar armazenamento em cache é difícil. No laboratório é difícil (e demorado) testar o preenchimento e a limpeza do cache. Não há nenhum armazenamento de cache em API que o torna fácil de manipular e medir.

Os testes no laboratório de armazenamento em cache são informativos, mas para os desenvolvedores web e fabricantes de browsers é mais importante entender como o cache funciona para usuários reais. Já faz cinco anos desde Tenni Theurer e eu executamos o experimento seminal para medir o uso de cache do navegador. Esse estudo mostrou que 20% dos page views foram realizados com um cache vazio, mas o mais surpreendente foi que entre 40% e 60% dos usuários diários tiveram pelo menos uma visualização de página vazia de cache. Definitivamente, vou voltar a executar essa experiência.

Eu comecei meu foco em armazenamento em cache lançando um teste para medir o que acontece quando os usuários limpam o cache. É interessante como navegadores diferem em suas interfaces de usuário para o cache. Eles não são nem intuitivos nem consistentes. Gostaria muito de sua ajuda na geração de dados. Por favor, execute a experiência e contribua com seus resultados. Você pode encontrar o experimento aqui:

Clear Browser Experiment

***

Texto original disponível em http://www.stevesouders.com/blog/2012/09/06/keys-to-a-fast-web-app/