Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)-js-Tutorial-php.cn

Der Inhalt dieses Artikels ist eine detaillierte Erklärung (Bilder und Texte) des Browser-Parsing- und Rendering-Prozesses. Ich hoffe, dass er für Freunde in Not hilfreich ist Du.

Funktionsweise des Browsers

Die übergeordnete Struktur des Browsers

Die Hauptkomponenten des Browsers sind:

1 Leiste, Vor-/Zurück-Taste, Lesezeichenmenü usw. Abgesehen von der Anzeige der von Ihnen angeforderten Seite im Hauptfenster des Browsers gehört jeder andere Teil der Anzeige zur Benutzeroberfläche.

2. Browser-Engine – überträgt Anweisungen zwischen der Benutzeroberfläche und der Rendering-Engine.

3. Präsentations-Engine – verantwortlich für die Anzeige des angeforderten Inhalts. Wenn der angeforderte Inhalt HTML ist, ist er für das Parsen des HTML- und CSS-Inhalts und die Anzeige des analysierten Inhalts auf dem Bildschirm verantwortlich.

4. Netzwerk – wird für Netzwerkaufrufe wie HTTP-Anfragen verwendet. Seine Schnittstelle ist plattformunabhängig und bietet eine zugrunde liegende Implementierung für alle Plattformen.

5. Benutzeroberflächen-Backend – wird zum Zeichnen grundlegender Widgets wie Kombinationsfelder und Fenster verwendet. Es stellt eine gemeinsame Schnittstelle bereit, die plattformunabhängig ist, während unter der Haube die Benutzeroberflächenmethoden des Betriebssystems verwendet werden.

6. JavaScript-Interpreter. Wird zum Parsen und Ausführen von JavaScript-Code verwendet.

7. Datenspeicherung. Dies ist die Persistenzschicht. Der Browser muss verschiedene Daten auf der Festplatte speichern, beispielsweise Cookies. Die neue HTML-Spezifikation (HTML5) definiert eine „Webdatenbank“, eine vollständige (aber leichte) In-Browser-Datenbank.

Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)

Es ist erwähnenswert, dass im Gegensatz zu den meisten Browsern jede Registerkarte des Chrome-Browsers einer Rendering-Engine-Instanz entspricht. Jede Registerkarte ist ein unabhängiger Prozess.

2. Hauptprozess

Die Rendering-Engine ruft zunächst den Inhalt des angeforderten Dokuments von der Netzwerkschicht ab, und die Größe des Inhalts ist im Allgemeinen auf 8000 begrenzt Blöcke.

Dann ist der grundlegende Prozess wie folgt:

Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)

Die Rendering-Engine beginnt, das HTML-Dokument zu analysieren und jedes Tag einzeln in den „Inhalt“ umzuwandeln Baum“ DOM-Knoten. Stildaten in externen CSS-Dateien und Stilelementen werden ebenfalls analysiert. Diese Stilinformationen mit visuellen Anweisungen in HTML werden verwendet, um eine weitere Baumstruktur zu erstellen: den Rendering-Baum.

Der Rendering-Baum enthält mehrere Rechtecke mit visuellen Eigenschaften wie Farbe und Größe. Die Reihenfolge, in der diese Rechtecke angeordnet sind, ist die Reihenfolge, in der sie auf dem Bildschirm erscheinen.

Nachdem der Präsentationsbaum erstellt wurde, tritt er in die „Layout“-Verarbeitungsphase ein, was bedeutet, dass jedem Knoten die genauen Koordinaten zugewiesen werden, an denen er auf dem Bildschirm erscheinen soll. Der nächste Schritt ist das Zeichnen – die Rendering-Engine durchläuft den Rendering-Baum und die Backend-Ebene der Benutzeroberfläche zeichnet jeden Knoten.

Es sollte betont werden, dass es sich um einen schrittweisen Prozess handelt. Um ein besseres Benutzererlebnis zu erreichen, ist die Rendering-Engine bestrebt, Inhalte so schnell wie möglich auf dem Bildschirm anzuzeigen. Es muss nicht warten, bis das gesamte HTML-Dokument analysiert ist, bevor mit dem Aufbau des Rendering-Baums und dem Einrichten des Layouts begonnen wird. Die Rendering-Engine analysiert und zeigt Teile des Inhalts an, während sie weiterhin den Rest des Inhalts vom Netzwerk empfängt und verarbeitet.

Hauptprozessbeispiel:

webkitDetaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)

3. Die Reihenfolge der Verarbeitung von Skripten und Stylesheets

Das Modell des Netzwerks ist synchronisiert. Der Autor der Webseite möchte, dass der Parser das Skript sofort analysiert und ausführt, wenn er auf das Tag <script> trifft. Das Parsen des Dokuments wird angehalten, bis die Ausführung des Skripts abgeschlossen ist. Wenn das Skript extern ist, wird der Parsing-Prozess angehalten, bis die Ressource synchron aus dem Netzwerk abgerufen wird, bevor fortgefahren wird. Dieses Modell wird seit vielen Jahren verwendet und ist auch in den HTML4- und HTML5-Spezifikationen spezifiziert. Autoren können das Skript auch als „verzögern“ markieren, sodass die Dokumentanalyse nicht gestoppt wird, sondern vor der Ausführung gewartet wird, bis die Analyse abgeschlossen ist. HTML5 fügt eine Option hinzu, um Skripte als asynchron zu markieren, damit sie von anderen Threads analysiert und ausgeführt werden können. 2. VorparsingSowohl WebKit als auch Firefox haben diese Optimierung durchgeführt. Während das Skript ausgeführt wird, analysieren andere Threads den Rest des Dokuments und suchen und laden zusätzliche Ressourcen, die über das Netzwerk geladen werden müssen. Auf diese Weise können Ressourcen auf parallelen Verbindungen geladen werden, was die Gesamtgeschwindigkeit erhöht. Bitte beachten Sie, dass der Preparser den DOM-Baum nicht verändert und diese Arbeit dem Hauptparser überlässt; der Preparser analysiert nur Verweise auf externe Ressourcen (wie externe Skripte, Stylesheets und Bilder). 3. StylesheetStylesheets hingegen haben ein anderes Modell. Theoretisch ändert die Anwendung eines Stylesheets den DOM-Baum nicht, es scheint also nicht nötig zu sein, auf das Stylesheet zu warten und das Parsen des Dokuments zu stoppen. Dies bringt jedoch ein Problem mit sich, nämlich dass das Skript während der Analysephase des Dokuments Stilinformationen anfordert. Wenn die Stile zu diesem Zeitpunkt noch nicht geladen und analysiert wurden, erhält das Skript eine falsche Antwort, was natürlich zu vielen Problemen führt. Dies mag wie ein untypischer Fall erscheinen, kommt aber tatsächlich sehr häufig vor. Firefox deaktiviert alle Skripte während des Lade- und Analysevorgangs von Stylesheets. WebKit hingegen blockiert ein Skript nur dann, wenn es versucht, auf eine Stileigenschaft zuzugreifen, die möglicherweise von einem noch nicht geladenen Stylesheet betroffen ist. 4. Präsentationsbaumkonstruktion Während der DOM-Baum erstellt wird, erstellt der Browser auch eine andere Baumstruktur: den Präsentationsbaum. Dabei handelt es sich um einen Baum visueller Elemente in der Reihenfolge, in der sie erscheinen, und um eine visuelle Darstellung des Dokuments. Damit können Sie Dinge in der richtigen Reihenfolge zeichnen. Firefox nennt Elemente im Rendering-Baum „Frames“. Der von WebKit verwendete Begriff ist Renderer oder Rendering-Objekt. Der Renderer weiß, wie er sich selbst und seine untergeordneten Elemente anordnet und zeichnet. 4. Layout Wenn der Renderer erstellt und dem Rendering-Baum hinzugefügt wird, enthält er keine Positions- und Größeninformationen. Der Vorgang der Berechnung dieser Werte wird als Layout oder Neuanordnung bezeichnet. HTML verwendet ein flussbasiertes Layoutmodell, was bedeutet, dass geometrische Informationen in den meisten Fällen in nur einem Durchgang berechnet werden können. Elemente später im Fluss haben im Allgemeinen keinen Einfluss auf die Geometrie von Elementen früher im Fluss, sodass das Layout das Dokument von links nach rechts und von oben nach unten durchlaufen kann. Es gibt jedoch Ausnahmen, z. B. HTML-Tabellenberechnungen, die mehr als einen Durchlauf erfordern. Das Koordinatensystem wird relativ zum Grundrahmen unter Verwendung der oberen und linken Koordinaten erstellt. Layout ist ein rekursiver Prozess. Es beginnt beim Root-Renderer (entsprechend dem <html>-Element des HTML-Dokuments) und durchläuft dann rekursiv einen Teil oder die gesamte Frame-Hierarchie und berechnet Geometrieinformationen für jeden Renderer, der berechnet werden muss. Der Root-Renderer ist links bei 0,0 positioniert und seine Abmessungen entsprechen dem Ansichtsfenster (also dem sichtbaren Bereich des Browserfensters). Alle Renderer verfügen über eine „Layout“- oder „Reflow“-Methode, und jeder Renderer ruft die Layout-Methode seiner untergeordneten Elemente auf, die angelegt werden müssen. 5. ZeichnenIn der Zeichnungsphase durchläuft das System den Rendering-Baum und ruft die „Paint“-Methode des Renderers auf, um den Inhalt des Renderers anzuzeigen auf dem Bildschirm. Die Zeichenarbeit erfolgt über die Grundkomponenten der Benutzeroberfläche. Zusammenfassung des persönlichen Verständnisses1. Parser und VoranalysemechanismusDie Rendering-Engine erhält den Inhalt des angeforderten Dokuments von der Netzwerkschicht , und beginnt dann mit der Analyse des HTML-Dokuments und konvertiert jedes Tag nacheinander in einen DOM-Knoten im DOM-Baum (Inhaltsbaum) . Außerdem werden die Stildaten in externen CSS-Dateien und Stilelementen analysiert. Diese Stilinformationen mit visuellen Anweisungen in HTML werden verwendet, um eine weitere Baumstruktur zu erstellen: Renderbaum (Rendering-Baum) . Nachdem der Präsentationsbaum erstellt wurde, erstellt und zeichnet die Präsentations-Engine den Präsentationsbaum. Das Parsen der Rendering-Engine umfasst HTML-Parsing und CSS-Parsing. Der Ausgabe-„Analysebaum“ des HTML-Parsers ist eine Baumstruktur, die aus DOM-Elementen und Attributknoten besteht Document Object Model (Abkürzung für Document Object Model). Es handelt sich um eine Objektdarstellung eines HTML-Dokuments und eine Schnittstelle zwischen externen Inhalten (z. B. JavaScript) und HTML-Elementen. Der Wurzelknoten des Parse-Baums ist das „Document“-Objekt. Der CSS-Parser analysiert die Stildaten in CSS-Stildateien und Stilelementen in einen CSS-Regelbaum, und der Browser kombiniert den CSS-Regelbaum und den DOM-Baum, um einen Rendering-Baum zu generieren. JavaScript Interpreter wird zum Parsen und Ausführen von JavaScript-Code verwendet. Im Allgemeinen gehen wir davon aus, dass der Browser den Inhalt des HTML-Dokuments von der Netzwerkschicht empfängt und dann mit dem Parsen des Dokuments beginnt, um einen DOM-Baum zu generieren Starten Sie einen neuen Thread, um sie herunterzuladen, und bauen Sie den DOM-Baum weiter auf. Der Browser erstellt den Rendering-Baum basierend auf dem DOM-Baum und schließlich zeichnet der Browser das Rendering-Buch auf die Benutzeroberfläche. In der obigen Beschreibung ist es wichtig darauf hinzuweisen, dass das Parsen und Rendern von HTML-Dokumenten ein schrittweiser Prozess ist. Um ein besseres Benutzererlebnis zu erreichen, ist die Rendering-Engine bestrebt, Inhalte so schnell wie möglich auf dem Bildschirm anzuzeigen. Es muss nicht warten, bis das gesamte HTML-Dokument analysiert ist, bevor mit dem Aufbau des Rendering-Baums und dem Einrichten des Layouts begonnen wird. Die Rendering-Engine analysiert und zeigt Teile des Inhalts an, während sie weiterhin den Rest des Inhalts vom Netzwerk empfängt und verarbeitet. Browser-Voranalyse. Sowohl WebKit als auch Firefox implementieren diese Optimierung. Während das Skript ausgeführt wird, analysieren andere Threads den Rest des HTML-Dokuments und identifizieren und laden zusätzliche Ressourcen, die über das Netzwerk geladen werden müssen. Auf diese Weise können Ressourcen auf parallelen Verbindungen geladen werden, was die Gesamtgeschwindigkeit erhöht. Beachten Sie, dass der Preparser den DOM-Baum nicht ändert und diese Arbeit dem Hauptparser überlässt; der Preparser löst nur Verweise auf externe Ressourcen (wie externe Skripte, Stylesheets und Bilder) auf. Das Pre-Parsing des Browsers kann die Blockierung des Renderings verlangsamen. Wenn der Preloader beispielsweise beim Parsen des Dokuments das Tag <code><script src="last.js"></script> erkennt, lädt er die Datei last.js und legt sie im Browser-Cache ab Wenn der Browser beim Parsen auf dieses <script>-Tag stößt, wird last.js sofort ausgeführt, ohne auf den Abruf von Ressourcen aus dem Netzwerk zu warten, da der Preloader die Datei last.js bereits geladen hat, was die Blockierung des Renderings verlangsamt . 2. Verarbeitungsreihenfolge und Blockierungsanalyse von CSS und JS Während des Parsing- und Rendering-Prozesses von HTML-Dokumenten werden externe Stylesheets und Skripte nacheinander ausgeführt und gleichzeitig geladen . JS-Skripte blockieren das Parsen von HTML-Dokumenten, einschließlich der Erstellung von DOM-Bäumen und der Erstellung von Rendering-Bäumen; CSS-Stylesheets blockieren die Erstellung von Rendering-Bäumen, der DOM-Baum wird jedoch weiterhin erstellt (es sei denn, es wird ein Skript-Tag gefunden und css Die Datei wurde noch nicht geladen), sie wird jedoch nicht gerendert und auf der Seite gezeichnet. Wenn der Parser beim Parsen des HTML-Dokuments auf das Tag <script> trifft, wird das Skript sofort analysiert und ausgeführt. Das Parsen des HTML-Dokuments wird blockiert, bis das Skript ausgeführt wird. Wenn das Skript extern ist, wird der Analyseprozess angehalten, bis die Ressource aus dem Netzwerk abgerufen und analysiert und ausgeführt wird. Anschließend wird der nachfolgende Inhalt analysiert. Theoretisch ändert die Anwendung eines Stylesheets den DOM-Baum nicht, es scheint also keine Notwendigkeit zu geben, auf das Stylesheet zu warten und das Parsen des Dokuments zu stoppen. Dies bringt jedoch ein Problem mit sich, nämlich dass das Skript während der Analysephase des Dokuments Stilinformationen anfordert. Wenn die Stile zu diesem Zeitpunkt noch nicht geladen und analysiert wurden, erhält das Skript eine falsche Antwort, was natürlich zu vielen Problemen führt. Dies mag wie ein untypischer Fall erscheinen, kommt aber tatsächlich sehr häufig vor. Firefox deaktiviert alle Skripte während des Lade- und Analysevorgangs von Stylesheets. WebKit hingegen blockiert ein Skript nur dann, wenn es versucht, auf eine Stileigenschaft zuzugreifen, die möglicherweise von einem noch nicht geladenen Stylesheet betroffen ist. Aber egal welche Situation die Blockierung verursacht, die geladenen externen Ressourcen werden weiterhin geladen, wie z. B. externe Skripte, Stylesheets und Bilder. Das Parsen von HTML-Dokumenten kann blockiert werden, das Laden externer Ressourcen jedoch nicht. Das Laden externer CSS-Stylesheets blockiert die Ausführung externer Skripte, aber nicht das Laden externer Skripte. Dies kann über „Netzwerk – Wasserfall“ im Chrome-Debugging-Tool überprüft werden. Es ist jedoch zu beachten, dass die maximale Anzahl gleichzeitiger Verbindungen (gleicher Domänenname) von Chrome 6 beträgt. <img src="https://img.php.cn/upload/image/735/259/113/1553564420431875.png" title="1553564420431875.png" alt="Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)"/><img src="https://img.php.cn/upload/image/787/151/313/1553564435804019.png" title="1553564435804019.png" alt="Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)"/>Wie Sie den beiden Screenshots oben entnehmen können, wird die Skriptdatei jquery.min.js parallel zu Stildateien wie geladen B. „bootstrap.css“. Da es in Chrome jedoch eine Obergrenze von 6 gleichzeitigen Verbindungen gibt, wird das Laden von „bootstrap.min.js“-Skripten, „xxx.css“-Stilen und anderen Dateien erst dann gestartet, wenn die vorherigen Dateien geladen sind sind verfügbare Anschlüsse. <img src="https://img.php.cn/upload/image/165/943/699/1553564449350799.png" title="1553564449350799.png" alt="Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)"/>Nachdem wir die oben genannten Informationen verstanden haben, können wir die Seite entsprechend optimieren, z. B. CSS-Dateien komprimieren, CDN verwenden, Ressourcen unter mehreren Domainnamen verteilen und CSS-Dateien zusammenführen. Reduzieren Sie die Anzahl der HTTP-Anfragen usw., um die Ladegeschwindigkeit von CSS zu verbessern und die Blockierungszeit beim Parsen und Rendern von HTML-Dokumenten zu reduzieren. <blockquote>Der Browser erlaubt nur sechs TCP-Verbindungen pro Ursprung auf HTTP 1.Das Limit des Browsers für die Anzahl gleichzeitiger Anfragen gilt für denselben Domänennamen. Daher kann die CDN-Beschleunigungstechnologie verwendet werden, um die Reaktionsgeschwindigkeit von Benutzern, die auf die Website zugreifen, zu verbessern, sodass das Laden von Ressourcen mithilfe von CDN nicht die Anzahl der gleichzeitigen Verbindungen unter dem aktuellen Domänennamen belegt, wodurch die Blockierungszeit verkürzt wird. WebseitenleistungDas Verständnis des Prozesses des Parsens und Renderns von HTML-Dokumenten ist für die Analyse der Webseitenleistung von großer Bedeutung. Es kann uns dabei helfen, die Schlüsselfaktoren zu finden, die sich auf die Webseitenleistung auswirken . Wir wissen beispielsweise, dass die Ausführung externer JS-Skripte das Parsen von Dokumenten blockiert und schwere Plug-Ins von Drittanbietern die Ladegeschwindigkeit der Homepage beeinträchtigen. Wenn dies die Benutzererfahrung beeinträchtigt, müssen wir die Kosten berücksichtigen Der Einsatz dieses Drittanbieter-Plug-Ins ist zu hoch. Können stattdessen andere Lightweight-Plug-Ins verwendet werden oder können nur einige der Module verwendet werden? Nehmen Sie Datatables als Beispiel: <img src="https://img.php.cn/upload/image/387/658/286/1553564472228457.png" title="1553564472228457.png" alt="Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)"/>Das obige Bild ist ein Netzwerk-Screenshot einer Projektseite 700 ms. Sie müssen wissen, warum die Seite so geladen wird. Was macht der Browser während dieser leeren Zeit? Wir analysieren das Zeitleistendiagramm, um die spezifischen Informationen des Browsers während dieses Zeitraums wie folgt anzuzeigen: <img src="https://img.php.cn/upload/image/207/651/704/1553564490386393.png" title="1553564490386393.png" alt="Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)"/>Anhand des Zeitleistendiagramms können wir sehen, dass der Browser innerhalb des Zeitintervalls von 250 ms bis 900 ms den Skriptcode datatables.min.js ausführt Das Parsen des Dokuments dauert etwa 700 ms, was dem Leerraum im Netzwerkdiagramm entspricht. Wir betrachten weiterhin die Gesamtzeit, die zum Fertigstellen der Seite benötigt wird, und bewerten die Auswirkung von 700 ms wie folgt: <img src="https://img.php.cn/upload/image/185/928/648/1553564507392416.png" title="1553564507392416.png" alt="Detaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text)"/>Wie Sie sehen können, Die Gesamtzeit, die zum Vervollständigen der Seite benötigt wird, beträgt 1,66 Sekunden. Es ist ersichtlich, dass die Ausführungszeit von datatables.min.js einen großen Teil ausmacht. Sie sollten sorgfältig überlegen, ob Sie dieses Plug-In verwenden müssen Verwenden Sie andere leichtgewichtige Plug-Ins, um es zu ersetzen, oder ob Sie das Plug-In optimieren können. Nicht benötigte Module oder auf die Verwendung von Plug-Ins verzichten. Referenz-1 Der Browser empfängt den HTML-Code, der ein vollständiges Dokument oder ein Block sein kann, und beginnt mit der Analyse. Der Parsing-Prozess besteht darin, zuerst den DOM-Baum zu erstellen, dann den Rendering-Baum basierend auf dem DOM-Baum zu erstellen und schließlich zeichnet der Browser den Rendering-Baum auf die Seite. Der Prozess zum Erstellen eines Dom-Baums besteht darin, ihn von oben nach unten basierend auf dem HTML-Code aufzubauen. Wenn eine Skriptdatei geladen/ausgeführt wird, blockiert sie die nachfolgende Dom-Baumkonstruktion (Javascript kann den Dom-Baum ändern). Wenn eine CSS-Datei gefunden wird, wird die Konstruktion des Rendering-Baums blockiert, dh der DOM-Baum wird weiterhin erstellt (es sei denn, es wird ein Skript-Tag gefunden und die CSS-Datei ist immer noch nicht geladen), dies wird jedoch nicht der Fall sein gerendert und auf der Seite gezeichnet. Unabhängig davon, welche Datei blockiert ist, wird die geladene Datei weiterhin geladen, z. B. andere CSS-/JS-/Bilddateien im HTML-Dokument. Außerdem wird Javascript nach dem Laden ausgeführt, und der Ausführungsprozess blockiert auch den Aufbau des Baums. Andere Inhalte werden nach Abschluss der Ausführung analysiert, anstatt andere Inhalte nach der Ausführung zu laden. Autor: Jiabing Link: https://www.zhihu.com/questio...Referenz-2 Zuallererst: Open-Source-Browser laden HTML-Seiten im Allgemeinen mit 8 KB pro Block herunter. Dann analysiert es die Seite, um einen DOM-Baum zu generieren. Wenn es auf CSS-Tags oder JS-Skript-Tags stößt, startet es einen neuen Thread, um diese herunterzuladen, und fährt mit dem Aufbau des DOM fort. Nach dem Herunterladen wird das CSS in einen CSS-Regelbaum analysiert und der Browser kombiniert den CSS-Regelbaum und den DOM-Baum, um einen Renderbaum zu generieren. Hinweis: Durch den Aufbau des CSS-Objektmodells (CSSOM) wird die Ausführung von JavaScript blockiert. Die Ausführung von JavaScript blockiert auch den Aufbau des DOM. Nach dem Herunterladen von JavaScript können Sie das DOM über die DOM-API und den Stilbereich des Renderbaums über die CSSOM-API ändern. Jede Änderung führt dazu, dass der Renderbaum neu gestaltet und neu gezeichnet wird. Solange das DOM geändert wird oder die Form oder Größe des Elements geändert wird, wird Reflow ausgelöst, indem einfach die Farbe des Elements geändert wird (Aufruf der API der nativen GUI des Betriebssystems zum Zeichnen). Autor: Chen Jin Link: https://www.zhihu.com/questio...Dieser Artikel ist hier, es gibt noch mehr spannende Dinge für den Inhalt, Sie Sie können der Spalte <a href="http://www.php.cn/course/list/17.html" target="_blank">JavaScript Video Tutorial auf der chinesischen PHP-Website folgen! </script>

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Prozesses des Browser-Parsens und Renderns von HTML-Dokumenten (Bild und Text). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!