Verstehen Sie den Rendering-Prozess von HTML-Seiten als Vorbereitung auf das Erlernen der Front-End-Leistungsoptimierung.

Verstehen Sie den Rendering-Prozess von HTML-Seiten als Vorbereitung auf das Erlernen der Front-End-Leistungsoptimierung.
Ich lerne derzeit etwas über Front-End-Leistungsoptimierung. Es ist notwendig, den Seiten-Rendering-Prozess zu verstehen, um die richtige Lösung zu finden und Leistungsengpässe zu identifizieren. Hier sind einige der Dinge, die ich gesehen und mit Ihnen geteilt habe.
Referenz: Den Renderer verstehen
Die Darstellung der Seite weist die folgenden Merkmale auf :
• Einfädige Ereignisschleife
• Gut definierte, kontinuierliche und geordnete Abläufe (HTML5)
• Tokenisierung und DOM-Baumkonstruktion
• Ressourcen anfordern und vorab laden
• Erstellen Sie den Renderbaum und zeichnen Sie die Seite
Im Einzelnen :
Wenn wir die entsprechenden HTML-Bytes aus dem Netzwerk erhalten, beginnt der Aufbau des DOM-Baums. Verantwortlich hierfür ist der Thread des Browsers zur Aktualisierung der Benutzeroberfläche. Der Aufbau des DOM-Baums wird blockiert, wenn die folgenden Situationen eintreten:
• Der HTML-Antwortstream ist im Netzwerk blockiert
• Es gibt entladene Skripte
•Es wurde ein Skriptknoten gefunden, aber es sind noch entladene Stildateien vorhanden. Der Rendering-Baum wird aus dem DOM-Baum erstellt und wird durch die Stildateien blockiert.
Da es auf einer einfädigen Ereignisschleife basiert, wird die Darstellung der Seite blockiert, wenn diese Skripte oder Stile analysiert, ausgeführt und angewendet werden, auch wenn keine Skript- oder Stilblockierung vorliegt.
Einige Situationen, in denen die Seitendarstellung nicht blockiert wird :
•Definierte Defer- und Async-Attribute
• Keine zum Medientyp passende Stildatei
• Es werden keine Skriptknoten oder Stilknoten vom Parser eingefügt
Lassen Sie uns dies unten anhand eines Beispiels veranschaulichen (vollständiger Code) :

Code kopieren
Der Code lautet wie folgt:

<html>
<Text>
<link rel="stylesheet" href="beispiel.css">
<div>Hallo zusammen!</div>
<Skript>
Dokument.schreiben('<script src="other.js"></scr' + 'ipt>');
</Skript>
<div>Hallo nochmal!</div>
<script src="last.js"></script>
</body>
</html>

Der Code ist leicht verständlich und wenn Sie ihn in einem Browser öffnen, wird sofort die gewünschte Seite angezeigt. Als Nächstes verwenden wir die Zeitlupenwiedergabe, um zu sehen, wie es gerendert wird.

Code kopieren
Der Code lautet wie folgt:

<html>
<Text>
<link rel="stylesheet" href="beispiel.css">
<div>Hallo zusammen!</div>
<Skript>…

Zuerst stößt der Parser auf example.css und lädt es aus dem Netzwerk herunter. Der Vorgang des Herunterladens des Stylesheets ist zeitaufwändig, der Parser wird jedoch nicht blockiert und fährt mit der Analyse fort. Als nächstes stößt der Parser auf ein Skript-Tag, aber da die Stildatei nicht geladen wurde, wird die Ausführung des Skripts blockiert. Der Parser ist blockiert und kann die Analyse nicht fortsetzen.

Der Renderbaum wird auch durch die Stildatei blockiert, sodass kein Browser die Seite zu diesem Zeitpunkt rendern kann. Mit anderen Worten: Wenn die Datei example.css nicht heruntergeladen werden kann, wird „Hi there!“ nicht angezeigt.
Weiter, weiter. . .

Code kopieren
Der Code lautet wie folgt:

<html>
<Text>
<link rel="stylesheet" href="beispiel.css">
<div>Hallo zusammen!</div>
<Skript>
Dokument.schreiben('<script src="other.js"></scr' + 'ipt>');
</Skript>

Sobald die Datei example.css geladen ist, wird der Renderbaum erstellt.
Nachdem das Inline-Skript ausgeführt wurde, wird der Parser sofort von other.js blockiert. Sobald der Parser blockiert ist, empfängt der Browser die Paint-Anforderung und „Hallo!“ wird auf der Seite angezeigt.
Wenn other.js geladen ist, fährt der Parser mit der Analyse nach unten fort. . .

Code kopieren
Der Code lautet wie folgt:

<html>
<Text>
<link rel="stylesheet" href="beispiel.css">
<div>Hallo zusammen!</div>
<Skript>
Dokument.schreiben('<script src="other.js"></scr' + 'ipt>');
</Skript>
<div>Hallo nochmal!</div>
<script src="last.js"></script>

Der Parser wird blockiert, wenn er auf last.js stößt. Anschließend erhält der Browser eine weitere Rendering-Anforderung und auf der Seite wird „Hi again!“ angezeigt. Schließlich wird last.js geladen und ausgeführt.
Um die Blockierung des Renderings zu verringern, verwenden moderne Browser jedoch spekulatives Laden.

Im oben genannten Fall blockieren Skripte und Stildateien die Darstellung der Seite erheblich. Ich vermute, dass der Zweck des Vorladens darin besteht, diese Blockierungszeit zu reduzieren. Wenn das Rendern blockiert ist, geschieht Folgendes:
• Ein leichter HTML- (oder CSS-)Scanner setzt das Scannen im Dokument fort
• Suchen Sie nach den URLs von Ressourcendateien, die möglicherweise in Zukunft verwendet werden
• Laden Sie sie herunter, bevor der Renderer sie verwendet. Beim Guesswork-Preloading können jedoch keine über JavaScript geladenen Ressourcendateien (z. B. document.write()) erkannt werden.

Hinweis : Alle „modernen“ Browser unterstützen diese Methode.
Schauen wir uns das obige Beispiel noch einmal an und raten wir, wie das Vorladen funktioniert.

Code kopieren
Der Code lautet wie folgt:

<html>
<Text>
<link rel="stylesheet" href="beispiel.css">
<div>Hallo zusammen!</div>
<Skript>…

Der Parser gibt example.css zurück und ruft es vom Netzwerk ab. Der Parser wird nicht blockiert und setzt die Analyse fort. Wenn er auf einen Inline-Skriptknoten stößt, wird er blockiert. Da die Stildatei nicht geladen wurde, wird die Ausführung des Skripts blockiert. Der Renderbaum wird außerdem durch das Stylesheet blockiert, sodass der Browser die Renderanforderung nicht erhält und nichts sehen kann. Soweit ist es der gleiche Ansatz wie gerade erwähnt. Doch dann änderten sich die Dinge.

Der spekulative Loader fährt mit dem „Lesen“ des Dokuments fort, findet last.js und versucht, es zu laden. Nächste:

Code kopieren
Der Code lautet wie folgt:

<html>
<Text>
<link rel="stylesheet" href="beispiel.css">
<div>Hallo zusammen!</div>
<Skript>
Dokument.schreiben('<script src="other.js"></scr' + 'ipt>');
</Skript>

Sobald example.css geladen ist, wird der Renderbaum erstellt und Inline-Skripte können ausgeführt werden. Anschließend wird der Parser erneut von other.js blockiert. Nachdem der Parser blockiert wurde, erhält der Browser die erste Renderanforderung und „Hallo!“ wird auf der Seite angezeigt. Dieser Schritt ist derselbe wie der vorherige. Dann:

Code kopieren
Der Code lautet wie folgt:

<html>
<Text>
<link rel="stylesheet" href="beispiel.css">
<div>Hallo zusammen!</div>
<Skript>
Dokument.schreiben('<script src="other.js"></scr' + 'ipt>');
</Skript>
<div>Hallo nochmal!</div>
<script src="last.js"></script>

Der Parser findet last.js, aber da der Preloader es gerade geladen und im Browser-Cache platziert hat, wird last.js sofort ausgeführt. Danach erhält der Browser die Rendering-Anforderung und auf der Seite wird „Hi again“ angezeigt.
Durch den Vergleich der beiden Situationen hoffe ich, dass jeder ein gewisses Verständnis für die Seitendarstellung bekommt und dann einige gezielte Optimierungen vornehmen kann. Guten Abend! (Ende)^_^

<<:  JavaScript-Grundlagen dieser Verweisung

>>:  Ein ausführliches Tutorial zur Installation von Jenkins auf Docker für Anfänger

Artikel empfehlen

Haben Sie die MySQL-Verbindungsabfrage wirklich gelernt?

1. Übersicht über Inner Join-Abfragen Der Inner J...

Detaillierte Erklärung zur Verwendung von Filtereigenschaften in CSS

Das Filterattribut definiert die visuelle Wirkung...

Unterschied zwischen var und let in JavaScript

Inhaltsverzeichnis 1. Bereiche werden in verschie...

MySQL implementiert eine Beispielmethode zum Anmelden ohne Kennwort

Spezifische Methode: Schritt 1: Stoppen Sie den M...

Detaillierte Erklärung zur Verwendung von Rastereigenschaften in CSS

Rasterlayout Dem übergeordneten Element hinzugefü...

Beispiele für häufige Nginx-Fehlkonfigurationen

Inhaltsverzeichnis Fehlender Stammspeicherort Off...