Séquence de chargement et d'exécution d'une page web?

1) HTML est téléchargé.

2) HTML est analysé progressivement. Lorsqu'une demande d'un actif est atteinte, le navigateur tente de télécharger l'actif. Une configuration par défaut pour la plupart des serveurs HTTP et la plupart des navigateurs est de traiter seulement deux requêtes en parallèle. IE peut être reconfiguré pour télécharger un nombre illimité d'actifs en parallèle. Steve Souders a été en mesure de télécharger plus de 100 demandes en parallèle sur IE. L'exception est que les requêtes de script bloquent l'actif parallèle les demandes dans IE. C'est pourquoi il est fortement suggéré de mettre tout JavaScript dans des fichiers JavaScript externes et de placer la requête juste avant la balise de corps de fermeture dans le HTML.

3) Une fois le code HTML analysé, le DOM est rendu. CSS est rendu en parallèle au rendu du DOM dans presque tous les agents utilisateurs. Par conséquent, il est fortement recommandé de mettre tout le code CSS dans des fichiers CSS externes qui sont demandés le plus haut possible dans la section

du document. Sinon, l' la page est rendue jusqu'à l'occurrence de la position de la requête CSS dans le DOM, puis le rendu commence par le haut.

4) Ce N'est qu'après que le DOM est complètement rendu et que les demandes pour tous les actifs de la page sont résolues ou que JavaScript s'exécute à partir de L'événement onload. IE7, et je ne suis pas sûr de IE8, ne temporise pas rapidement les actifs si une réponse HTTP n'est pas reçue de la demande d'actif. Cela signifie un actif demandé par JavaScript en ligne sur la page, c'est-à-dire JavaScript écrit dans des balises HTML qui ne sont pas contenues dans une fonction, peut empêcher l'exécution de l'événement onload pendant des heures. Ce problème peut être déclenché si un tel code en ligne existe dans la page et ne s'exécute pas en raison d'une collision d'espace de noms qui provoque un plantage de code.

Parmi les étapes ci-dessus, celle qui nécessite le plus de CPU est l'analyse du DOM/CSS. Si vous souhaitez que votre page soit traitée plus rapidement écrivez des CSS efficaces en éliminant les instructions redondantes et en consolidant Instructions CSS dans le moins de références d'éléments possibles. La réduction du nombre de nœuds dans votre arborescence DOM produira également un rendu plus rapide.

Gardez à l'esprit que chaque ressource que vous demandez à partir de votre HTML ou même de vos ressources CSS/JavaScript est demandée avec un en-tête HTTP séparé. Cela consomme de la bande passante et nécessite un traitement par requête. Si vous voulez charger votre page aussi rapidement que possible, réduisez le nombre de requêtes HTTP et réduisez la taille de votre HTML. Vous êtes ne pas faire de votre expérience utilisateur des faveurs en faisant la moyenne du poids de la page à 180k à partir de HTML seul. De nombreux développeurs souscrivent à une erreur selon laquelle un utilisateur se décide sur la qualité du contenu de la page en 6 nanosecondes, puis purge la requête DNS de son serveur et brûle son ordinateur en cas de mécontentement, donc ils fournissent la plus belle page possible à 250k de HTML. Gardez votre HTML court et doux afin qu'un utilisateur puisse charger vos pages plus rapidement. Rien n'améliore l'expérience utilisateur comme une page Web rapide et réactive.

Ouvrez votre page dans Firefox et obtenez L'addon HTTPFox. Il vous dira tout ce dont vous avez besoin.

Trouvé ceci sur archiviste.incuito:

Http://archivist.incutio.com/viewlist/css-discuss/76444

Lorsque vous demandez une page pour la première fois, votre le navigateur envoie une requête GET au serveur, qui renvoie le code HTML au navigateur. Le navigateur démarre alors analyser la page (peut-être avant tout il a été retournés).

Quand il trouve une référence à un entité externe telle qu'un fichier CSS, un fichier image, un fichier de script, un Flash fichier, ou toute autre chose externe à la page (soit sur le même serveur/domaine ou non), il se prépare à faites une autre demande GET pour cela ressources.

Cependant, la norme HTTP spécifie que le navigateur ne devrait pas faire plus plus de deux demandes simultanées au même domaine. Donc, il met chaque demande à un domaine particulier dans une file d'attente, et lorsque chaque entité est renvoyée elle démarre le suivante dans la file d'attente pour que domaine.

Le temps qu'il faut pour qu'une entité soit retourné dépend de sa taille, de la charger le serveur est actuellement éprouver, et l'activité de chaque machine unique entre le la machine exécutant le navigateur et le serveur. La liste de ces machines peut en principe être différent pour chaque demande, dans la mesure où un image pourrait voyager des Etats-Unis pour moi AU ROYAUME-UNI sur L'Atlantique, tandis que un autre du même serveur sortir via le Pacifique, L'Asie et L'Europe, qui prend plus de temps. Alors vous pourriez obtenir un séquence comme suit, où un page a (dans cet ordre) références à trois fichiers de script, et cinq image fichiers, tous de tailles différentes:

1. récupère script1 et script2; demande de file d'attente pour script3 et images1-5.
2. script2 arrive (il est plus petit que script1): GET script3, file d'attente images1-5.
3. script1 arrive; GET image1, file d'attente images2-5.
4. image1 arrive, GET image2, file d'attente images3-5.
5. script3 échoue à arriver en raison d'un problème réseau-récupère script3 à nouveau (nouvelle tentative automatique).
6. image2 arrive, script3 toujours pas ici; GET image3, file d'attente images4-5.
7. l'image 3 arrive; obtenez image4, file d'attente image5, script3 toujours en chemin.
8. image4 arrive, GET image5;
9. image5 arrive.
10. script3 arrive.

En bref: tout ancien ordre, selon ce que l' le serveur fait, ce que le reste de l'Internet est en train de faire, et si oui ou non quelque chose a des erreurs et à re-cheveux. Cela peut on dirait une façon bizarre de faire choses, mais il serait tout à fait littéralement être impossible pour Internet (PAS juste le WWW) pour travailler avec n'importe quel degré de fiabilité si ce n'était pas fait façon.

En outre, la file d'attente interne du navigateur peut ne pas récupérer les entités dans l'ordre ils apparaissent dans la page - ce n'est pas requis par toute norme.

(Oh, et n'oubliez pas la mise en cache, à la fois dans le navigateur et dans les proxies de mise en cache utilisé par les FAI pour alléger la charge sur le réseau.)

Si vous demandez cela parce que vous voulez accélérer votre site web, consultez la page de Yahoo sur Les meilleures pratiques pour accélérer votre Site web . Il a beaucoup de meilleures pratiques pour accélérer votre site web.

Dynatrace AJAX Edition vous montre la séquence exacte du chargement, de l'analyse et de l'exécution de la page.

AFAIK, le navigateur (au moins Firefox) demande chaque ressource dès qu'il l'analyse. S'il rencontre une balise img, il demandera cette image dès que la balise img a été analysée. Et cela peut être avant même qu'il ait reçu la totalité du document HTML... c'est-à-dire qu'il pourrait toujours être en train de télécharger le document HTML lorsque cela se produit.

Pour Firefox, il existe des files d'attente de navigateur qui s'appliquent, en fonction de la façon dont elles sont définies dans about: config. Par exemple il ne tentera pas de télécharger plus de 8 fichiers à la fois à partir du même serveur... les demandes supplémentaires seront mises en file d'attente. Je pense qu'il y a des limites par domaine, par limites de proxy, et d'autres choses, qui sont documentées sur le site Web de Mozilla et peuvent être définies dans about:config. J'ai lu quelque part que IE n'a pas de telles limites.

L'événement jQuery ready est déclenché dès que le document HTML principal a été téléchargé et QU'il est DOM analysé. Ensuite, l'événement load est déclenché une fois toutes les ressources liées (css, images,etc.) ont été téléchargé et analysé aussi bien. Il est clairement indiqué dans la documentation jQuery.

Si vous voulez contrôler l'ordre dans lequel tout ce qui est chargé, je crois que le moyen le plus fiable de le faire est via JavaScript.

La réponse choisie ressemble à ne s'applique pas aux navigateurs modernes, au moins sur Firefox 52. Ce que j'ai observé, c'est que les demandes de chargement de ressources comme css, javascript sont émises avant que L'analyseur HTML atteigne l'élément, par exemple

<html>
  <head>
    <!-- prints the date before parsing and blocks HTMP parsering -->
    <script>
      console.log("start: " + (new Date()).toISOString());
      for(var i=0; i<1000000000; i++) {};
    </script>

    <script src="jquery.js" type="text/javascript"></script>
    <script src="abc.js" type="text/javascript"></script>
    <link rel="stylesheets" type="text/css" href="abc.css"></link>
    <style>h2{font-wight:bold;}</style>
    <script>
      $(document).ready(function(){
      $("#img").attr("src", "kkk.png");
     });
   </script>
 </head>
 <body>
   <img id="img" src="abc.jpg" style="width:400px;height:300px;"/>
   <script src="kkk.js" type="text/javascript"></script>
   </body>
</html>

Ce que j'ai trouvé que l'Heure de début des demandes de chargement des ressources CSS et javascript n'était pas bloquée. On dirait que Firefox a une analyse HTML et identifie les ressources clés(la ressource img n'est pas incluse) avant de commencer à analyser le HTML.