Lernen Sie den Rendering-Prozess von HTML-Seiten kennen, um sich auf die Optimierung der Front-End-Leistung vorzubereiten (Fortsetzung)

Gestern Abend habe ich einen Aufsatz über den Browser-Rendering-Prozess geschrieben, ihn aber nur anhand eines kleinen Code-Schnipsels erklärt. Er wurde nicht über einen Browser getestet, war also nicht überzeugend genug und wies noch viele Mängel auf. Heute habe ich ihn im Browser getestet und die Ergebnisse mit Ihnen geteilt. Der Testprozess kann etwas chaotisch sein, und ich hoffe, Sie haben dafür Verständnis.

Getestete Browser : Chrome v24.0.1312.52 m, Firefox v18.0, Opera v12.12.

Wenn im WebKit-Kernel eine Webseite angezeigt wird, gibt es einen Parser, der das HTML-Dokument analysiert, dann einen Renderbaum generiert und schließlich die Seite rendert. Dies wird in einem Thread erledigt, beides geschieht also nicht gleichzeitig.

Ich habe es in zwei Fälle aufgeteilt und sie in unterschiedlichen Browsern getestet.

Die Testergebnisse zeigen, dass in Chrome der Speicherort der Stildatei die Downloadzeit des Bildes beeinflusst, während in den beiden anderen Browsern kein Unterschied zwischen den beiden Situationen besteht. Nachfolgend wird der Testvorgang im Detail beschrieben.

Test 1: Die Stildatei befindet sich im Kopf und die anderen beiden Skriptdateien befinden sich jeweils eine am Anfang und eine am Ende des Textkörpers.

Getesteter Code:

Nachdem ich die Seite im Browser geöffnet hatte, machte ich schnell einen Screenshot der Webseite, wie unten gezeigt (klicken Sie, um ein größeres Bild anzuzeigen, unten dasselbe):

Wie aus der obigen Abbildung ersichtlich ist, wurde das Dokument test.htm geladen, auf der Seite wird noch nichts angezeigt, example.css befindet sich im ausstehenden Zustand, aber last.js unten wurde geladen. Dies bedeutet, dass Chrome es vorab geladen, heruntergeladen und im Browser-Cache abgelegt hat. Obwohl last.js geladen wurde, wurde es noch nicht ausgeführt, da die davor liegende Stildatei die Ausführung des Skripts blockieren würde.

Als nächstes wird, wenn example.css geladen ist, Hallo! auf dem Bildschirm angezeigt. Der Browser-Screenshot sieht wie folgt aus :

Aus der Netzwerkanforderung ist ersichtlich, dass example.css geladen wurde und other.js sich im Wartezustand befindet, die drei Bilder unter dem Skript-Tag jedoch zu diesem Zeitpunkt bereits heruntergeladen wurden. Dies liegt an der Vorladefunktion des Browsers. Da die Browserdarstellung jedoch durch das other.js-Skript blockiert wird, werden diese drei Bilder und das darauf angezeigte „Hi again“ nicht angezeigt. Darüber hinaus wurde der Code in last.js zu diesem Zeitpunkt nicht ausgeführt.

Als nächstes, wenn other.js geladen ist, erstellt der Browser den Renderbaum, zeigt „Hi again“ an und zeigt das Bild an. Da last.js zuvor heruntergeladen wurde, wird last.js sofort ausgeführt. Der gesamte Rendering-Prozess ist abgeschlossen. Wie in der folgenden Abbildung dargestellt:

Daraus können wir ersehen, dass Chrome die Skriptressourcen im Textkörper vorlädt (Stildateien werden nicht getestet). Das vom JavaScript-Skript dynamisch geladene JS hat keinen Einfluss auf den Download der Bilddatei, aber auf die Darstellung des darunterliegenden Bildes.

2. Testergebnisse in Firefox

Nachdem Sie die Seite in Firefox geöffnet haben, machen Sie schnell einen Screenshot, wie unten gezeigt:

Dies ist offensichtlich ein Unterschied zu Chrome. Auf der Seite wird „Hallo!“ angezeigt, aber die Hintergrundfarbe ist weiß, was darauf hinweist, dass die Stildatei noch nicht heruntergeladen wurde. Es wird in Chrome erst angezeigt, wenn die Stildatei geladen ist.

Wenn die gesamte Seite geladen ist, sieht der Screenshot wie folgt aus:

Aus dem Wasserfallfluss der Anfrage können wir erkennen, dass der Browser ähnlich wie Chrome last.js vorlädt. Anders als Chrome lädt Firefox das Bild nicht vor, sondern wartet, bis other.js geladen ist, bevor es geladen wird.

In Firefox haben Stildateien keinen Einfluss auf die Dokumentdarstellung (das häufigste Phänomen ist, dass die Webseite zunächst chaotisch und ohne Stil angezeigt wird, nach dem Herunterladen der Stildateien jedoch normal angezeigt wird). Im Textkörper blockiert die von JavaScript dynamisch geladene JS-Datei den Download der dahinter liegenden Bilder.

3. Im Opera-Browser

Nach dem Testen in Opera stellte sich heraus, dass der Opera-Browser „regelkonformer“ ist. Alle Ressourcen werden nacheinander geladen, und es gibt kein sogenanntes Vorladen. Nachfolgend sehen Sie ein Bild des Gesamteffekts:

In Opera blockieren Stildateien das Rendern von Seiten, ähnlich wie bei Chrome. Der Anforderungs-Wasserfallfluss von Opera zeigt jedoch, dass alle Ressourcen auf der Seite schrittweise geladen werden und other.js vor last.js geladen wird. Kein Vorladen.

Test 2: Die Stildatei steht am Anfang des Textkörpers und der Speicherort der Skriptdatei ist derselbe wie in Test 1.

 Code kopieren
 Der Code lautet wie folgt:

 <!doctype html>
 <html>
 <Kopf>
 <title>Testseite</title>
 </Kopf>
 <Text>
 <link rel="stylesheet" type="text/css" href="beispiel.aspx?sleep=3" />
 <div>
 Hallo!

 <Skripttyp="text/javascript">
 Dokument.schreiben("<script src='other.aspx?sleep=5'></scr" + "ipt>");
 </Skript>

 <div>
 Hallo nochmal!</div>
 <img src="images/marx.jpg" alt="Marx" />
 <img src="images/engels.jpg" alt="Engels" />
 <img src="images/Lenin.jpg" alt="Lenin" />

 <script src="last.aspx" type="text/javascript"></script>

 </body>
 </html>

 Nach dem Testen stellte ich fest, dass die Ergebnisse in Firefox und Opera dieselben waren wie in Test 1, in Chrome jedoch leicht unterschiedlich. In Test 1 wurde das Bild erst heruntergeladen, wenn die Stildatei im Kopf geladen war, in Test 2 wurde es jedoch parallel mit der Stildatei heruntergeladen, wie unten gezeigt: 

Zusammenfassen :

Vorladen ist möglich, aber nicht in Opera. Die Bilder von Chrome können parallel zu den Stildateien im Textkörper heruntergeladen werden, jedoch nicht parallel zu den Stildateien im Kopf. Das Skript wird ausgeführt, nachdem die vorhergehende Stildatei geladen wurde. In Chrome und Opera blockieren nicht geladene Ressourcen die Darstellung der dahinter liegenden Elemente. Bei Firefox ist dies jedoch nicht der Fall. Die Testergebnisse können mit der Browserversion zusammenhängen.

Finden Sie, dass es nach dem Lesen all dessen etwas verwirrend ist? Ich möchte es so klar wie möglich ausdrücken, aber aufgrund meines begrenzten Niveaus kann ich nur dies tun. Ich hoffe, Sie können mich auf unangemessene Punkte hinweisen. Sie können es auch selbst versuchen.

(Ende)^_^