JavaScript étant chargé de manière asynchrone dans Firefox 3 (selon Firebug)?

Question

J'essaie de profiler la performance d'un site Web dont je suis assez confiant est ralenti par le chargement de fichiers JavaScript sur la page.

Les mêmes fichiers JavaScript sont inclus plusieurs fois sur la page et les tags <script /> sont dispersés sur la page au lieu d'être included at the bottom.

Comme je me doutais, lorsque vous regardez l'onglet "Net" de FireBug, la plupart du temps (pas tous) lorsque JavaScript est chargé, aucun autre fichier n'est demandé. Le navigateur attend le chargement du JavaScript.

Il existe cependant quelques exceptions. Il y a quelques occasions où JavaScript est chargé, mais en même temps, d'autres ressources semblent être chargées, comme d'autres fichiers et images JavaScript.

J'ai toujours pensé que JavaScript bloque le chargement des autres ressources sur la page. Ai-je tort de penser à cela, ou ce comportement varie-t-il en fonction du navigateur ou de la version du navigateur?

MISE À JOUR:
Pour ceux qui ont expliqué comment le chargement d'un des blocs de script le chargement d'autres ressources, je suis déjà au courant de cela. Ma question est pourquoi un script ne bloquerait pas le chargement d'autres ressources. Firebug montre que certains fichiers JavaScript ne bloquer le chargement d'autres ressources. Je veux savoir pourquoi cela arriverait.

Answer 1

Les requêtes de ressources Javascript sont en effet bloquantes, mais il y a des façons de contourner cela (à savoir: les balises DOM injectées dans la tête, et les requêtes AJAX) qui sans voir la page.

Y compris plusieurs copies de la même ressource JS est très mauvaise mais pas nécessairement fatale, et est typique des grands sites qui auraient pu être accrétion du travail des équipes distinctes, ou tout simplement vieux mauvais codage, la planification, ou entretien.

En ce qui concerne la recommandation de Yahoo pour placer des scripts au bas du corps, ce qui améliore percieved temps de réponse, et peut améliorer les temps de chargement réel à un degré (parce que toutes les ressources précédentes sont autorisés à Async premier), mais il ne sera jamais aussi efficace que les demandes non bloquantes (bien qu'elles présentent une grande barrière de capacité technique).

Une discussion assez décente de JS non-bloquant here.

Answer 2

Je crois que le contenu est téléchargé, mais pas rendu jusqu'à ce que le chargement du JavaScript soit terminé. Ceci est, à partir du POV du serveur, pas beaucoup d'un accord, mais pour l'utilisateur, il peut faire une énorme différence de vitesse.

Answer 3

Si vous y réfléchissez, une balise doit terminer le traitement avant de pouvoir continuer à afficher le contenu. Que faire si le tag utilisé document.write ou une autre chose merveilleusement stupide? Jusqu'à ce que quelque chose dans la balise de script ait fini de s'exécuter, la page ne peut pas être sûre de ce qu'elle va afficher.

Answer 4

Je ne suis pas entièrement sûr que Firebug offre un vrai reflet de ce qui se passe dans le navigateur.Le moment choisi pour le chargement des ressources semble être bon, mais je ne suis pas certain qu'il s'agisse d'un véritable reflet de ce qui se passe réellement. J'ai eu plus de chance d'utiliser les sniffers/applications proxy HTTP pour surveiller les requêtes HTTP réelles provenant du navigateur. J'utilise Fiddler, mais je sais qu'il existe d'autres outils. En bref, cela peut être un problème avec l'outil et non pas avec la façon dont les ressources sont réellement chargées ... ce qui vaut la peine d'être exclu.

Answer 5

Les navigateurs ont généralement un nombre défini de connexions ouvertes à un seul domaine.
Ainsi, si vous chargez tous vos scripts depuis le même domaine, vous les chargez généralement les uns après les autres.
Mais, si ces scripts sont chargés à partir de plusieurs domaines, ils seront chargés en parallèle.

Answer 6

La raison pour laquelle le navigateur bloque lors du téléchargement de JavaScript est que le navigateur pense qu'il y aura des nœuds DOM créés dans le script. Par exemple, il peut y avoir des appels "dcoument.write()" dans le script. Par exemple, il peut y avoir des appels "dcoument.write()".

Une façon d'indiquer au navigateur que le script ne contient aucune génération DOM est avec l'attribut "reporter". Ainsi,

<script src="script.js" type="text/javascript" defer="defer"></script> 

devrait permettre au navigateur de continuer parallélisation les demandes.

Références:

http://www.w3.org/TR/REC-html40/interact/scripts.html#adef-defer

http://www.websiteoptimization.com/speed/tweak/defer/

Answer 7

Je suppose que vous utilisez Firefox 3.0.10 et Firebug puisque ce sont 1.3.3 les dernières versions.

La version bêta de Firebug 1.4 a fait beaucoup d'améliorations sur l'onglet net, mais elle nécessite Firefox 3.5. Si vous voulez le tester dans Firefox 3.0, utilisez l'un des précédents 1.4 alpha versions. Mais même avec les améliorations, j'ai encore du mal à comprendre le résultat. Je souhaite que les développeurs Firebug documentent plus précisément ce que chaque partie d'un téléchargement signifie. Cela n'a pas de sens pour moi pourquoi la file d'attente est après la connexion. Ma conclusion était de ne pas faire confiance aux résultats dans Firebug, et a fini par utiliser le WebPageTest. Qui était étonnamment bon à venir d'AOL ;-)

De plus, quelles sont les ressources qui sont chargées en même temps que le javascript? Essayez de parcourir les ressources qui sont chargées en même temps, et voyez si elles sont référencées dans un css/iframe/html-ajax. Je devine la raison pour laquelle rien d'autre n'est chargé, c'est parce que le navigateur arrête d'analyser le HTML actuel quand il voit une étiquette de script (sans différer). Comme il ne peut pas continuer à analyser le code HTML, il n'a plus rien à demander.

Si vous pouviez fournir un lien vers la page dont vous parlez. Cela aiderait tout le monde à donner une réponse plus précise.

Answer 8

Comme d'autres l'ont indiqué, le script charge probablement d'autres ressources via l'injection DOM. En fait, Script.aculo.us charge lui-même ses composants enfants/scripts en injectant dans le DOM d'autres balises <script>.

Si vous voulez voir si c'est le cas, utilisez le profileur de Firebug et jetez un oeil à ce que font les scripts.

Answer 9

Comme d'autres l'ont dit, un moyen non-bloquant consiste à injecter <script> étiquettes dans la page head.

Mais Firefox peut également exécuter chargé <script> s en parallèle: Copiez les deux lignes ci-dessous:

http://streetpc.free.fr/tmp/test.js 
http://streetpc.free.fr/tmp/test2.js 

Ensuite, allez à this page, coller dans la zone de texte d'entrée, cliquez sur « JavaScript », puis « Scripts de charge » (qui construit et ajoute un élément enfant <script> au head). Essayez cela dans FF: vous verrez "test2 ok", déplacez la boîte de dialogue pour voir "test ok". Dans les autres navigateurs, vous devriez voir "test ok" (sans autre dialogue derrière) puis "test2 ok", (sauf pour Safari 4, me montrant tes2 avant test).

Answer 10

Firefox 3 a introduit fonction de parallélisme de connexion pour améliorer les performances lors du chargement d'une page Web, je parie que c'est la source de votre problème;)

Lorsque vous ouvrez une page Web qui a beaucoup de différents objets qu'il contient , comme des images, fichiers Javascript, cadres, flux de données, et ainsi de suite, le navigateur tente de télécharger plusieurs d'entre eux à la fois pour obtenir de meilleures performances.

Here's the ZDNET blogpost about it.