Vraag Laad- en uitvoeringsvolgorde van een webpagina?


Ik heb wat webgebaseerde projecten gedaan, maar ik denk niet te veel na over de laad- en uitvoeringsvolgorde van een gewone webpagina. Maar nu moet ik details weten. Het is moeilijk om antwoorden van Google of zo te vinden, dus ik heb deze vraag gemaakt.

Een voorbeeldpagina is als volgt:

<html>
 <head>
  <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>

Dus hier zijn mijn vragen:

  1. Hoe laadt deze pagina?
  2. Wat is de volgorde van het laden?
  3. Wanneer wordt de JS-code uitgevoerd? (inline en extern)
  4. Wanneer wordt de CSS uitgevoerd (toegepast)?
  5. Wanneer wordt $ (document) .ready uitgevoerd?
  6. Wordt abc.jpg gedownload? Of downloadt het gewoon kkk.png?

Ik heb het volgende begrip:

  1. De browser laadt eerst de html (DOM).
  2. De browser begint de externe bronnen regel voor regel van boven naar beneden te laden.
  3. Als een <script> wordt voldaan, wordt het laden geblokkeerd en wacht u tot het JS-bestand is geladen en uitgevoerd en gaat u verder.
  4. Andere bronnen (CSS / afbeeldingen) worden parallel geladen en indien nodig uitgevoerd (zoals CSS).

Of is het zo:

De browser parseert de html (DOM) en haalt de externe bronnen in een array of stack-achtige structuur. Nadat de html is geladen, begint de browser de externe bronnen in de structuur parallel te laden en uit te voeren, totdat alle bronnen zijn geladen. Vervolgens wordt de DOM aangepast aan het gedrag van de gebruiker, afhankelijk van de JS.

Kan iemand een gedetailleerde uitleg geven over wat er gebeurt als je de reactie van een html-pagina hebt? Is dit in verschillende browsers verschillend? Enige referentie over deze vraag?

Bedankt.

BEWERK:

Ik heb een experiment gedaan in Firefox met Firebug. En het wordt weergegeven als de volgende afbeelding: alt text


225
2017-11-25 08:26


oorsprong


antwoorden:


Volgens uw steekproef,

<html>
 <head>
  <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>

ongeveer de uitvoeringsstroom is ongeveer als volgt:

  1. Het HTML-document wordt gedownload
  2. Het ontleden van het HTML-document begint
  3. HTML-parsing bereikt <script src="jquery.js" ...
  4. jquery.js is gedownload en geparseerd
  5. HTML-parsing bereikt <script src="abc.js" ...
  6. abc.js is gedownload, geparseerd en uitgevoerd
  7. HTML-parsing bereikt <link href="abc.css" ...
  8. abc.css is gedownload en geparseerd
  9. HTML-parsing bereikt <style>...</style>
  10. Interne CSS-regels worden geparseerd en gedefinieerd
  11. HTML-parsing bereikt <script>...</script>
  12. Intern Javascript wordt geparseerd en uitgevoerd
  13. HTML-parsing bereikt <img src="abc.jpg" ...
  14. abc.jpg wordt gedownload en weergegeven
  15. HTML-parsing bereikt <script src="kkk.js" ...
  16. kkk.js is gedownload, geparseerd en uitgevoerd
  17. Het parseren van HTML-document eindigt

Merk op dat de download asynchroon en niet-blokkerend kan zijn vanwege het gedrag van de browser. In Firefox is er bijvoorbeeld deze instelling die het aantal gelijktijdige verzoeken per domein beperkt.

Ook afhankelijk van of het onderdeel al in de cache is geplaatst of niet, kan het onderdeel in een bijna-toekomstig verzoek mogelijk niet opnieuw worden aangevraagd. Als het onderdeel in de cache is opgeslagen, wordt het onderdeel uit de cache geladen in plaats van de daadwerkelijke URL.

Wanneer het ontleden is voltooid en het document gereed en geladen is, de gebeurtenissen onload is ontslagen. Dus wanneer onload is ontslagen, de $("#img").attr("src","kkk.png"); wordt uitgevoerd. Zo:

  1. Document is gereed, onload is geactiveerd.
  2. Javascript-executie hits $("#img").attr("src", "kkk.png");
  3. kkk.png is gedownload en wordt geladen in #img

De $(document).ready() gebeurtenis is feitelijk de gebeurtenis die wordt afgevuurd wanneer alle pagina-componenten zijn geladen en gereed zijn. Lees er meer over: http://docs.jquery.com/Tutorials:Introducing_$ (document) .ready ()

Bewerken - Dit gedeelte gaat meer in op het parallelle of niet-gedeelte:

Standaard, en vanuit mijn huidige inzicht, draait browser meestal elke pagina op 3 manieren: HTML-parser, Javascript / DOM en CSS.

De HTML-parser is verantwoordelijk voor het parseren en interpreteren van de opmaaktaal en moet dus in staat zijn om naar de andere 2 componenten te bellen.

Bijvoorbeeld wanneer de parser deze regel tegenkomt:

<a href="#" onclick="alert('test');return false;" style="font-weight:bold">a hypertext link</a>

De parser maakt 3 oproepen, twee naar Javascript en één naar CSS. Ten eerste maakt de parser dit element en registreert het in de DOM-naamruimte, samen met alle attributen die betrekking hebben op dit element. Ten tweede zal de parser bellen om de onclick-gebeurtenis aan dit specifieke element te binden. Ten slotte zal het opnieuw een aanroep doen naar de CSS-thread om de CSS-stijl op dit specifieke element toe te passen.

De uitvoering is van boven naar beneden en één thread. Javascript kan multi-threaded lijken, maar feit is dat Javascript single threaded is. Dit is de reden waarom bij het laden van externe javascript-bestanden de ontleding van de hoofd-HTML-pagina is opgeschort.

De CSS-bestanden kunnen echter tegelijkertijd worden gedownload, omdat CSS-regels altijd worden toegepast. Dit betekent dat elementen altijd opnieuw worden geschilderd met de meest recente CSS-regels die zijn gedefinieerd, waardoor het blokkering wordt opgeheven.

Een element is pas beschikbaar in de DOM nadat het is geparseerd. Dus wanneer met een specifiek element wordt gewerkt, wordt het script altijd achter, of in het venster onloadgebeurtenis geplaatst.

Script zoals dit zal een fout veroorzaken (op jQuery):

<script type="text/javascript">/* <![CDATA[ */
  alert($("#mydiv").html());
/* ]]> */</script>
<div id="mydiv">Hello World</div>

Omdat wanneer het script wordt geparseerd, #mydiv element is nog steeds niet gedefinieerd. In plaats daarvan zou dit werken:

<div id="mydiv">Hello World</div>
<script type="text/javascript">/* <![CDATA[ */
  alert($("#mydiv").html());
/* ]]> */</script>

OF

<script type="text/javascript">/* <![CDATA[ */
  $(window).ready(function(){
                    alert($("#mydiv").html());
                  });
/* ]]> */</script>
<div id="mydiv">Hello World</div>

260
2017-11-25 08:48



1) HTML is gedownload.

2) HTML wordt progressief geparseerd. Wanneer een verzoek om een ​​activum wordt bereikt, probeert de browser het activum te downloaden. Een standaardconfiguratie voor de meeste HTTP-servers en de meeste browsers is om slechts twee verzoeken parallel te verwerken. IE kan opnieuw worden geconfigureerd om parallel een onbeperkt aantal items te downloaden. Steve Souders heeft meer dan 100 aanvragen tegelijkertijd op IE kunnen downloaden. De uitzondering is dat scriptverzoeken parallelle activabezoeken in IE blokkeren. Dit is de reden waarom het ten zeerste wordt aanbevolen om alle JavaScript in externe JavaScript-bestanden te plaatsen en het verzoek net vóór de afsluitende body-tag in de HTML in te dienen.

3) Nadat de HTML is geparseerd, wordt de DOM gerenderd. CSS wordt parallel aan de weergave van de DOM weergegeven in bijna alle gebruikersagenten. Daarom wordt sterk aanbevolen om alle CSS-code in externe CSS-bestanden te plaatsen die zo hoog mogelijk worden aangevraagd in het gedeelte <head> </ head> van het document. Anders wordt de pagina weergegeven tot het voorkomen van de CSS-verzoekpositie in de DOM en begint de weergave opnieuw vanaf de bovenkant.

4) Alleen nadat de DOM volledig is gegenereerd en verzoeken om alle items op de pagina zijn opgelost of time-out wordt JavaScript uitgevoerd vanaf de onload-gebeurtenis. IE7, en ik ben niet zeker van IE8, timt geen tijdrovende bezittingen af ​​als er geen HTTP-respons van het activumverzoek wordt ontvangen. Dit betekent dat een item dat door JavaScript inline is aangevraagd voor de pagina, dat wil zeggen JavaScript dat is geschreven in HTML-tags dat niet in een functie is opgenomen, kan voorkomen dat het onload-evenement uren wordt uitgevoerd. Dit probleem kan worden getriggerd als een dergelijke inline-code op de pagina voorkomt en niet wordt uitgevoerd vanwege een botsing tussen naamruimten waardoor een code crasht.

Van de bovenstaande stappen is degene die het meest CPU-intensief is, het ontleden van de DOM / CSS. Als u wilt dat uw pagina sneller wordt verwerkt, schrijft u efficiënte CSS door overbodige instructies te elimineren en CSS-instructies te consolideren in de minste mogelijke elementreferenties. Als u het aantal knooppunten in uw DOM-structuur vermindert, wordt de rendering ook sneller.

Houd er rekening mee dat elk item dat u aanvraagt ​​uit uw HTML of zelfs uit uw CSS / JavaScript-items wordt opgevraagd met een afzonderlijke HTTP-header. Dit verbruikt bandbreedte en vereist verwerking per verzoek. Als u uw pagina zo snel mogelijk wilt laten laden, verlaagt u het aantal HTTP-aanvragen en verkleint u de HTML-waarde. U doet uw gebruikerservaring geen enkele rol door het paginagewicht op 180 k te baseren op HTML alleen. Veel ontwikkelaars abonneren een of andere denkfout dat een gebruiker in 6 nanoseconden een beslissing neemt over de kwaliteit van de inhoud op de pagina en verwijdert vervolgens de DNS-query van zijn server en brandt zijn computer als hij niet tevreden is, dus in plaats daarvan bieden ze de meest prachtige pagina op 250 k HTML. Houd uw HTML kort en krachtig, zodat een gebruiker uw pagina's sneller kan laden. Niets verbetert de gebruikerservaring als een snelle en responsieve webpagina.


33
2017-12-02 15:52



Open uw pagina in Firefox en ontvang de HTTPFox-add-on. Het zal je alles vertellen wat je nodig hebt.

Vond dit op archivist.incuito:

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

Wanneer u een pagina voor het eerst opvraagt, wordt uw   browser verzendt een GET-verzoek naar de   server, die de HTML retourneert naar de   browser. De browser begint dan   ontleden van de pagina (mogelijk vóór alles   van het is teruggegeven).

Wanneer het een verwijzing naar een vindt   externe entiteit zoals een CSS-bestand, een   beeldbestand, een scriptbestand, een Flash   bestand of iets anders extern   de pagina (of op hetzelfde   server / domein of niet), het bereidt zich voor op   doe daar nog een GET-verzoek voor   bron.

De HTTP-standaard specificeert echter   dat de browser niet meer zou moeten maken   dan twee gelijktijdige verzoeken aan de   hetzelfde domein. Dus het plaatst elke aanvraag   naar een bepaald domein in een wachtrij, en   wanneer elke entiteit wordt geretourneerd, begint deze   de volgende in de wachtrij daarvoor   domein.

De tijd die een entiteit nodig heeft om te zijn   terug afhankelijk van de grootte, de   laad de server is momenteel   ervaren, en de activiteit van   elke afzonderlijke machine tussen de   machine met de browser en de   server. De lijst met deze machines   kan in principe anders zijn voor   elk verzoek, voor zover mogelijk   afbeelding zou van de VS naar mij kunnen reizen   in het Verenigd Koninkrijk over de Atlantische Oceaan, terwijl   een andere van dezelfde server komt uit   via de Pacific, Azië en Europa,   wat langer duurt. Dus je krijgt misschien een   volgorde zoals de volgende, waar a   pagina heeft (in deze volgorde) referenties   tot drie scriptbestanden en vijf afbeeldingen   bestanden, alle verschillende maten:

  1. GET script1 en script2; wachtrijaanvraag voor script3 en afbeeldingen1-5.
  2. script2 arriveert (het is kleiner dan script1): GET script3, wachtrij   images1-5.
  3. script1 arriveert; GET image1, wachtrijafbeeldingen2-5.
  4. image1 arriveert, GET image2, wachtrijafbeeldingen3-5.
  5. script3 kan niet aankomen vanwege een netwerkprobleem - KRIJG script3 opnieuw   (automatisch opnieuw proberen).
  6. image2 arriveert, script3 is nog steeds niet hier; KRIJG image3, wacht beelden4-5.
  7. afbeelding 3 arriveert; KRIJG image4, wacht rij image5, script3 is nog onderweg.
  8. image4 arriveert, GET image5;
  9. image5 komt aan.
  10. script3 arriveert.

Kortom: elke oude bestelling, afhankelijk van   wat de server doet, wat de   de rest van het internet doet het, en   of er al dan niet fouten zijn   en moet opnieuw worden opgehaald. Dit zou   lijkt een rare manier van doen   dingen, maar het zou vrij letterlijk   onmogelijk zijn voor internet (niet   alleen het WWW) om met enige mate te werken   van betrouwbaarheid als het dit niet was gedaan   manier.

Ook de interne wachtrij van de browser   mogelijk worden geen entiteiten in de volgorde opgehaald   ze verschijnen op de pagina - dat is het niet   verplicht voor elke standaard.

(Oh, en vergeet caching niet, beide in   de browser en in caching-proxies   gebruikt door ISP's om de belasting op de   netwerk.)


12
2017-12-02 15:56



Als u dit vraagt ​​omdat u uw website wilt versnellen, ga dan naar de Yahoo-pagina Praktische tips voor het versnellen van uw website. Het heeft een heleboel praktische tips voor het versnellen van uw website.


6
2017-11-25 09:00



Dynatrace AJAX-editie toont u de exacte volgorde van laden, parseren en uitvoeren van pagina's.


1
2017-12-02 18:52



AFAIK, de browser (in ieder geval Firefox) vraagt ​​elke resource aan zodra deze wordt geparseerd. Als het een img-tag tegenkomt, vraagt ​​het die afbeelding aan zodra de img-tag is geparseerd. En dat kan zelfs zijn voordat het het geheel van het HTML-document heeft ontvangen ... dat wil zeggen dat het nog steeds het HTML-document kan downloaden als dat gebeurt.

Voor Firefox zijn er browserwachtrijen die van toepassing zijn, afhankelijk van hoe ze zijn ingesteld over: config. Het zal bijvoorbeeld niet proberen om meer dan 8 bestanden tegelijkertijd van dezelfde server te downloaden ... de extra verzoeken worden in de wachtrij geplaatst. Ik denk dat er limieten per domein zijn, per proxylimiet en andere zaken, die op de Mozilla-website zijn gedocumenteerd en kunnen worden ingesteld in about: config. Ik heb ergens gelezen dat IE dergelijke limieten niet kent.

Het jQuery-ready-evenement wordt zo snel afgevuurd het hoofd HTML-document is gedownload en de DOM is geparseerd. Vervolgens wordt de laadgebeurtenis gestart zodra alle gekoppelde bronnen (CSS, afbeeldingen, enz.) Ook zijn gedownload en geparseerd. Het wordt duidelijk gemaakt in de documentatie van jQuery.

Als je de volgorde wilt bepalen waarin alles is geladen, denk ik dat de meest betrouwbare manier om dit te doen is via JavaScript.


1
2018-03-28 20:27



Het gekozen antwoord lijkt niet van toepassing op moderne browsers, tenminste niet op Firefox 52. Wat ik heb waargenomen is dat de verzoeken voor het laden van bronnen zoals css, javascript worden uitgegeven voordat de HTML-parser het element bereikt, bijvoorbeeld

<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>

Wat ik ontdekte dat de begintijd van aanvragen voor het laden van CSS- en JavaScript-bronnen niet werd geblokkeerd. Lijkt erop dat Firefox een HTML-scan heeft en identificeer de belangrijkste bronnen (img-bron is niet inbegrepen) voordat de HTML wordt ontleed.


0
2017-12-21 08:25