O tamanho do Javascript é um problema de desempenho depois de ser armazenado em cache?

9

Estou escrevendo um projeto que usará algumas bibliotecas JS bastante grandes, incluindo a interface do usuário do jquery. O projeto será executado dentro de uma Intranet. Portanto, o tempo de download não é realmente um problema para mim, e a maioria das pessoas só precisa baixar as bibliotecas uma vez, pois suponho que elas permanecerão no cache do navegador.

A minha pergunta é sobre como os navegadores modernos (IE9, FF5, etc) lidam com o processamento do código Javascript. Eu imagino que em algum momento ele é compilado, mas isso é feito em cada carregamento de página, ou o código compilado também é armazenado em cache. Em caso afirmativo, ele é armazenado em cache mesmo depois que o navegador é fechado?

Este aplicativo da web pode ser executado em alguns dispositivos portáteis de baixa energia, então eu queria ser razoavelmente eficiente. Eu queria combinar todos os arquivos javascript em um grande que está ligado a todas as páginas do aplicativo.

Mas, dependendo de quanto trabalho o navegador deve fazer para processar todo o JS, estou pensando se devo dividi-los, para que nem todas as páginas carreguem todo o JS. Obviamente, isso é mais trabalho.

Qualquer opinião ou informação seria apreciada. Obrigado.

    
por C.J. 29.07.2011 в 15:22
fonte

7 respostas

5

Sim, o tamanho do JavaScript ainda é um problema de desempenho se for armazenado em cache pelos seguintes motivos:

  • A maioria dos navegadores não armazena em cache o código de bytes que eles executam. Portanto, o script ainda deve ser re-analisado em cada carregamento de página. Navegadores modernos estão fazendo isso mais rápido, mas ainda pode ser uma preocupação para arquivos JavaScript muito grandes.
  • O código em seus arquivos JavaScript é realmente executado em cada carregamento de página. Mesmo se os navegadores começarem a armazenar em cache o código de bytes, eles ainda terão que executar novamente o JavaScript toda vez que a página for carregada.
  • Você pode obter uma taxa de cache menor do que a esperada, por motivos além do seu controle. Os usuários podem desativar seu cache ou visitar tantos sites que seus arquivos são expirados do cache rapidamente. Você deve verificar seus logs para certificar-se de que a proporção de carregamentos de página para carregamentos de arquivos JavaScript seja alta.
  • Carregar um arquivo do cache geralmente é bem rápido, mas nem sempre é trivial. Pode demorar mais de 200ms em alguns casos.

Você pode fazer um teste bem rápido para ter uma ideia aproximada de quanto tempo seus scripts demoram para analisar e executar assim:

<script>
  var startTime = (new Date()).getTime();
</script>
<script src="cachedFile1.js"></script>
<script src="cachedFile2.js"></script>
<!--all your scripts included this way-->
<script>
  var endTime = (new Date()).getTime();
  alert("Took " + (endTime - startTime) + " milliseconds to parse and execute");
</script>

Certifique-se de testar em todos os navegadores de destino que você suporta; A análise de JavaScript e o tempo de execução podem variar muito entre diferentes navegadores. Além disso, certifique-se de testar em um computador que seja tão lento quanto os seus usuários. Se você encontrar problemas de desempenho, provavelmente precisará resolvê-los em um criador de perfil. A redução não ajudará muito na melhoria do tempo de análise e execução.

    
por Annie 29.07.2011 / 17:02
fonte
0

Minimize seus arquivos javascript. Isso ocupa menos espaço. Além disso, o Javascript é uma linguagem interpretada, por isso nunca é compilada.

link )

    
por Dismissile 29.07.2011 / 15:27
fonte
0

Realmente não importa quanto existe código, mas quão pesado é. Atualmente, os navegadores podem executar o JS rapidamente. Basta tentar abrir o Gmail forexample (que é quase todo sobre javascript) com o IE7 e, em seguida, com o IE9 ou Chrome.

    
por Pehmolelu 29.07.2011 / 15:30
fonte
0

Você precisa investigar os mecanismos JavaScript usados por cada navegador para entender melhor, por exemplo, o Google Chrome usa o V8: link

Isso também ajuda você a entender melhor:

Como os navegadores executam o javascript

Como os navegadores lidam com JavaScript?

    
por b01 29.07.2011 / 15:33
fonte
0

Leia este artigo , um recurso muito bom para ajudar você a ajustar seu desempenho em JavaScript.

    
por abhijit 29.07.2011 / 15:41
fonte
0

Se o seu caso de uso estiver apenas em um ambiente de intranet, comparado a outras técnicas de otimização, o tamanho do código não será um problema para você. Presumivelmente, os navegadores de destino são relativamente novos e têm mecanismos JS que podem manipular sites de javascript completos, caso em que o tamanho do código não afetará realmente a velocidade, já que a análise de código é muito pequena, em comparação com a execução . Em navegadores mais antigos, no entanto, pode haver uma pequena diferença de velocidade em comparação com o tamanho do código mais otimizado, uma vez que eles nunca foram feitos para executar o javascript, que é milhares e milhares de linhas de código.

Em comparação com a otimização de execução de código, a otimização do comprimento de código provavelmente não será notada para o usuário final. Você pode bater alguns ms comprimindo o código, mas a maioria dos mecanismos modernos cria um "mapa" quando eles analisam o código, de modo que, no tempo de execução, a localização de uma função, variável, etc., realmente não importa. Portanto, preocupe-se mais com a otimização geral de código, em vez dos tamanhos das bibliotecas, etc.

Você pode ouvir sobre os internos do V8 aqui

    
por zatatatata 29.07.2011 / 16:32
fonte
0

Eu nunca pensei sobre isso a partir desse ponto de vista, mas não posso, realmente, por que não agrupar tudo em um arquivo grande não ajudaria * - as ferramentas de criação de JavaScript que eu conheço se concentram em fazer exatamente isso.

* a menos que você tenha um módulo grande que raramente é usado. Nesse caso, mantenha-o separado para que nem todos tenham que usá-lo.

    
por hugomg 29.07.2011 / 17:10
fonte