Der Critical Rendering Path ist die Abfolge von Aufgaben, die der Browser ausführt, um eine Seite zunächst auf dem Bildschirm zu rendern, d.h. HTML-, CSS- und JavaScript-Code herunterzuladen, zu verarbeiten und in echte Pixel umzuwandeln und auf dem Bildschirm darzustellen.
Die Optimierung des Critical Rendering Path ist der Prozess der Minimierung der Zeit, die der Browser benötigt, um jeden Schritt der Sequenz auszuführen, wobei der Anzeige von Inhalten, die mit der aktuellen Benutzeraktion in Zusammenhang stehen, Priorität eingeräumt wird.
Ein Großteil dieses Prozesses bezieht sich auf den Teil der Seite, der sichtbar ist, ohne im Browserfenster nach unten zu scrollen. Dieser Abschnitt wird auch als Above the Fold bezeichnet. Für eine bessere Benutzbarkeit sollte der ATF so bald wie möglich gerendert werden, und dies kann durch die Reduzierung der Anzahl der Netzwerk-Roundtrips auf ein Minimum erreicht werden. Die Ressourcen, die zum Rendern des ATF benötigt werden, gelten als kritisch, und die Optimierung des Above the Fold bedeutet, die Auswirkungen kritischer Ressourcen auf die Renderzeit der ersten Seite zu minimieren.
In diesem Beitrag gehen wir durch die Optimierungssequenz des Critical Rendering Path.
- Zunächst gebe ich einen allgemeinen Überblick über die Aufgaben, die der Browser beim Rendern des Inhalts einer Seite ausführt.
- Anschließend werde ich die wichtigsten Aktionen analysieren, die wir zur Optimierung des Critical Rendering Path durchführen können.
- Schließlich werde ich einige nützliche (und beliebte) WordPress-Optimierungs-Plugins auflisten.
Die Abfolge des Critical Rendering Path
Hier ist die Abfolge der Schritte, die der Browser durchführt, um eine Seite zu rendern:
- Zuerst lädt der Browser das HTML-Markup herunter, parst es und baut das DOM
- Dann wird das CSS-Markup heruntergeladen und verarbeitet und das CSS-Objektmodell erstellt.
- Es kombiniert DOM- und CSSOM-Knoten, die zum Rendern der Seite im Render-Baum benötigt werden, der eine Baumstruktur aller sichtbaren Knoten darstellt.
- Es berechnet die Abmessungen und die Position jedes Objekts auf der Seite
- Schließlich malt es Pixel auf den Bildschirm
Das DOM
Wie in Googles Leitfaden zur Optimierung des Critical Rendering Path erläutert, baut der Browser das Dokumentobjektmodell in einer vierstufigen Sequenz auf:
- Zunächst liest der Browser die Zeilenbytes und übersetzt sie in einzelne Zeichen.
- Dann wandelt es die in geschweiften Klammern eingeschlossenen Zeichenfolgen in Tokens um
- Diese Token werden in Knotenobjekte umgewandelt
- Knotenobjekte sind in einer baumartigen Datenstruktur verknüpft, die HTML-Inhalte, Eigenschaften und alle Beziehungen zwischen Knoten enthält. Diese Struktur ist das Dokument-Objektmodell.
Wichtig dabei ist, dass der Browser das DOM inkrementell aufbaut. Dies gibt uns die Möglichkeit, die Darstellung der Seite durch die Schaffung effizienter DOM-Strukturen zu beschleunigen.
Die CSSOM
Wenn der Parser auf ein link-Tag stößt, das auf ein externes CSS-Stylesheet verweist, blockiert er das Parsen und sendet eine Anforderung für diese Ressource aus. Sobald die CSS-Datei empfangen wurde, beginnt der Browser mit dem Aufbau einer Baumdatenstruktur aus CSS-Knoten.
- Der Browser liest die Zeilenbytes der .css-Datei und übersetzt sie in einzelne Zeichen
- Es wandelt die in geschweiften Klammern eingeschlossenen Zeichenfolgen in Token um
- Diese Token werden in Knotenobjekte umgewandelt
- Knotenobjekte sind in einer baumartigen Datenstruktur verknüpft, die die CSS-Eigenschaften jedes Knotens sowie die Beziehungen zwischen den Knoten enthält. Diese Struktur ist das CSS-Objektmodell (CSSOM).
Im Gegensatz zur DOM-Konstruktion ist die CSSOM-Konstruktion nicht inkrementell. Der Browser kann einen Teil eines Stylesheets nicht verwenden, da Stile im selben Stylesheet verfeinert und neu deklariert werden können. Aus diesem Grund blockiert der Browser den Rendering-Prozess, bis er das gesamte CSS empfangen und analysiert hat. Dies bedeutet, dass CSS eine Rendering-Blockierung darstellt.
Der Render Tree
Der Browser kombiniert DOM und CSSOM im Render Tree, der die endgültige Baumstruktur darstellt, die alle Knoten und Eigenschaften enthält, die zum Rendern der Seite auf dem Bildschirm verwendet werden.
“Der Render Tree enthält nur die Knoten, die zum Rendern einer Seite erforderlich sind. Infolgedessen werden unsichtbare Knoten ausgelassen.”
Der Browser verwendet den Renderbaum, um die Abmessungen und die Position der Nodes als Input für den Painting-Prozess zu berechnen.
Layout und Paint
In der Layoutphase berechnet der Browser die Abmessungen und die Position jedes Knotens des Render-Trees. In dieser Phase durchquert der Browser den Render-Tree ausgehend von seiner Wurzel und erzeugt ein Box-Modell. Diese Informationen werden schließlich dazu verwendet, jeden Knoten des Rendern-Trees in tatsächliche Pixel auf dem Bildschirm umzuwandeln.
Critical Rendering Path Optimierung
Die zur Ausführung des gesamten Prozesses erforderliche Zeit kann variabel sein. Sie hängt von vielen Faktoren ab, wie z.B. der Dokumentgröße, der Anzahl der Anfragen, den verwendeten Stilen, dem Benutzergerät usw.
Eine der wichtigsten Google-Empfehlungen ist die Priorisierung von sichtbarem Inhalt, um Above the Fold so schnell wie möglich zu erstellen, und enthält zwei Hauptregeln, die zu befolgen sind:
- Strukturiere den HTML-Code so, dass der kritische, Above the Fold stehende Inhalt zuerst geladen wird.
- Reduzierung der von HTML-, CSS- und JS-Ressourcen verwendeten Datenmenge
Wie in Googles Leitfaden PageSpeed gut erklärt wird, sind zusätzliche Netzwerk-Roundtrips zwischen Server und Browser erforderlich, wenn die zum Rendern der ATF erforderliche Datenmenge das anfängliche Staufenster (14,6kb) überschreitet. In Mobilfunknetzen mit hohen Latenzen würde dies das Laden der Seite erheblich verzögern (lies mehr über Latenz).
Der Browser baut das DOM inkrementell auf, und dies gibt uns die Möglichkeit, die zum Rendern des ATF erforderliche Zeit zu reduzieren, indem wir den HTML-Code so strukturieren, dass der obige Teil zuerst geladen und der Rest der Seite verschoben wird.
Aber die Optimierung endet nicht mit dem Aufbau einer effektiven DOM-Struktur. Es ist vielmehr ein Prozess der Verbesserung und Messung, der die gesamte Sequenz des Critical Rendering Path umfasst.
Lasst uns detaillierte werden.
Ressourcendimensionen minimieren
Wir können die Datenmenge, die der Browser herunterladen wird, reduzieren, indem wir HTML-, CSS- und JavaScript-Ressourcen verkleinern, komprimieren und zwischenspeichern:
- Unter Minifizierung versteht man das Entfernen unnötiger Zeichen wie Kommentare und Leerzeichen aus dem Quellcode. Diese Zeichen sind für die Entwicklung wichtig, aber für das Rendering der Seite sind sie nutzlos.
- Komprimierung ist die Fähigkeit von Webservern und Clients, die Größe der übertragenen Dateien zu reduzieren, um die Geschwindigkeit und Bandbreitennutzung zu verbessern.
- Caching: Jeder Browser verfügt über eine Implementierung eines HTTP-Caches. Was wir tun müssen, ist sicherzustellen, dass jede Serverantwort die richtigen HTTP-Header zur Verfügung stellt, um dem Browser mitzuteilen, wann und wie lange er die angeforderten Ressourcen zwischenspeichern soll.
CSS optimieren
Jetzt wissen wir, dass der Browser warten muss, bis er den CSS-Code geholt und verarbeitet hat, bevor er die Seite rendern kann (CSS ist Render-Blocking). Aber nicht alle CSS-Ressourcen sind render-blockierend.
CSS kann an bestimmte Bedingungen angepasst werden, und wir können es mit Hilfe von Medientypen und Medienabfragen optimieren. Wenn du eine Webseite auf dem Bildschirm betrachtest, sendet der Browser eine Anfrage nach einem Printmedientyp, aber er blockiert nicht das Rendern der Seite für diese Ressource.
Nimm das folgende link-Tag:
<link rel="stylesheet" href="style.css" />Das referenzierte Stylesheet dieses Tags gilt unter allen Bedingungen, unabhängig vom aktuellen media-typ, der Bildschirmauflösung, der Geräteausrichtung usw. Das bedeutet, dass die CSS-Ressource immer render-blockierend ist.
Glücklicherweise können wir unter bestimmten Bedingungen eine Anfrage für eine CSS-Ressource senden. Wir könnten Druckstile in eine separate Datei verschieben und das media-Attribut verwenden, um dem Browser mitzuteilen, dass das angegebene Stylesheet nur beim Seitenaufbau geladen werden soll und die Darstellung auf dem Bildschirm nicht blockiert werden muss:
<link rel="stylesheet" href="print.css" media="print" />Der Browser lädt immer noch das print.css-Stylesheet herunter, aber es blockiert die Darstellung nicht. Außerdem muss der Browser weniger Daten für die Haupt-CSS-Datei herunterladen, was uns helfen würde, den Download zu beschleunigen. Wir können jede beliebige Medienabfrage auf dem link-Attribut angeben, so dass wir das CSS in mehrere Dateien aufteilen und diese bedingt laden können:
<link rel="stylesheet" href="style.css" media="screen" />
<link rel="stylesheet" href="portrait.css" media="orientation:portrait" />
<link rel="stylesheet" href="widescreen.css" media="(min-width: 42rem)" />Stelle sicher, dass deine Stile zum Rendern der Seite tatsächlich benötigt werden. Wenn dies nicht der Fall ist, kannst du dem Media-Tag-Attribut einen entsprechenden Wert hinzufügen und die Blockierung des Renderings aufheben.
Medientypen und Abfragen können uns helfen, das Rendern der Seite zu beschleunigen, aber wir können noch viel mehr tun.
- Minify CSS: Leerzeichen und Kommentare helfen uns nur beim Lesen von CSS-Deklarationen. Durch das Entfernen von Kommentaren und Whitespace aus dem Stylesheet können wir die Anzahl der Bytes einer CSS-Datei erheblich reduzieren.
- Kombiniere mehrere CSS-Dateien: Dies würde die Anzahl der HTTP-Requests reduzieren. Diese Aktion ist bei mobilen Verbindungen von Bedeutung, bei denen die Leistung durch hohe Latenzzeiten beeinträchtigt wird (lies mehr über Latenzzeiten).
- Inline critical CSS: Einige Stile sind insofern kritisch, als sie erforderlich sind, um den oberen Teil der Seite darzustellen. Sie sollten kritische Inline-Formate immer direkt im HTML-Markup berücksichtigen, um zusätzliche HTTP-Anforderungen zu vermeiden. Vermeide jedoch das Einfügen großer CSS-Dateien, da dies zusätzliche Roundtrips erfordern kann, um die Seite Above the Fold darzustellen, was zu einer PageSpeed-Warnung führen würde.
Du kannst deine Seite schnell und einfach verbessern, indem du deinen Code direkt von deinem MyKinsta Dashboard aus minifizierst. Nutze einfach die für dich angebotene Funktion zur Code-Minifizierung, um die automatische Änderung von CSS und Javascript mit einem Klick zu aktivieren.
Beschleunigung von Layout- und Zeichenprozessen
Die Zeit, die der Browser für das Layout des Dokuments benötigt, hängt von der Anzahl der zu layoutender DOM-Elemente und von der Komplexität dieser Layouts ab.
- Wenn du viele DOM-Elemente hast, kann es lange dauern, bis der Browser deren Position und Abmessungen berechnet hat: Vermeide das Layout, wann immer es möglich ist.
- Bevorzuge das neue Flexbox-Modell, da es schneller ist als die alte Flexbox und schwebende Layouts.
- Vermeide erzwungenes synchrones Layout mit JavaScript
Die Größe und Position von Rechenelementen erfordert Zeit und verringert die Leistung. Eine möglichst einfache Gestaltung des DOM und der Verzicht auf den Einsatz von JavaScript zur Vorwegnahme des Layout-Prozesses würde dem Browser helfen, das Rendering der Seite zu beschleunigen (lies mehr zur Layout-Optimierung).
Streng mit dem Layout verbunden ist der Paint-Prozess, der wahrscheinlich die zeitaufwendigste Phase in der Sequenz des Critical Rendering Path ist, denn jedes Mal, wenn man das Layout eines Elements oder eine nicht-geometrische Eigenschaft ändert, löst der Browser ein Painting-Ereignis aus. Wenn man die Dinge in dieser Phase so einfach wie möglich gestaltet, könnte der Browser den Malprozess beschleunigen. So würde z.B. eine Box-Shadow-Eigenschaft, die eine Art von Berechnungen erfordert, länger zum Zeichnen benötigen als eine einfarbige Randfarbe.
Die Optimierung des Malprozesses ist möglicherweise nicht so einfach, und man sollte die Entwicklerwerkzeuge des Browsers nutzen, um zu messen, wie lange der Browser braucht, um jedes Malereignis auszulösen. Weitere Informationen zu diesem Thema bietet Google’s Rendering Performance Guide.
JavaScript-Blockierung aufheben
Wenn der Browser auf ein Skript-Tag trifft, muss er das Parsen des HTML-Codes beenden. Inline-Skripts werden genau an der Stelle ausgeführt, an der sie sich im Dokument befinden, und blockieren die DOM-Konstruktion, bis die JS-Engine fertig läuft. Mit anderen Worten: Inline-JavaScript kann das anfängliche Rendern der Seite erheblich verzögern. Aber JavaScript ermöglicht auch die Manipulation von CSS-Eigenschaften, so dass der Browser die Skriptausführung pausieren muss, bis er das Herunterladen und den Aufbau des CSSOM abgeschlossen hat. Dies bedeutet, dass JavaScript die Parser blockiert.
Im Falle von externen JS-Dateien muss der Parser auch warten, bis die Ressource aus dem Cache oder vom Remote-Server geholt wurde, was die Zeit bis zum ersten Rendern der Seite stark verlangsamen könnte.
Was können wir jedoch tun, um die Zeit zu minimieren, die der Browser zum Laden und Ausführen von JavaScript benötigt?
- JavaScript asynchron laden: Das boolesche
asyncAttribut desskript-Tags weist den Browser an, das Skript möglichstasyncauszuführen, ohne die DOM-Konstruktion zu blockieren. Der Browser sendet die HTTP-Anforderung für das Skript und fährt mit dem Parsen des DOM fort. Das Skript blockiert auch nicht die CSSOM-Konstruktion, d.h. es blockiert auch nicht den Critical Rendering Path (weitere Informationen über Skript-Tag-Attribute findest du in den MDN-Docs). - Defer JavaScript: Das boolesche
defer-Attribut desscript-Tags weist den Browser an, das Script auszuführen, nachdem das Dokument geparst wurde, aber bevor dasDOMContentLoaded-Ereignis ausgelöst wird. Dieses Attribut darf nicht verwendet werden, wenn das src-Attribut nicht vorhanden ist, d.h. bei Inline-Skripten (lies mehr über Mozilla-Hacks) - Inline-JavaScript verschieben: Viele Skripte manipulieren weder das DOM noch das CSSOM, so dass es für sie keinen guten Grund gibt, das Parsen zu blockieren. Leider können wir keine async- und defer-Attribute für Inline-Skripte verwenden, so dass die einzige Möglichkeit, sie nach dem Laden des Dokuments zu laden, darin besteht, sie nach unten zu verschieben. Der Vorteil ist, dass Inline-Skripte keine zusätzlichen HTTP-Anforderungen erfordern. Allerdings würden Inline-Skripte, die in mehreren Seiten verwendet werden, zu redundantem Code führen.
Zusammenfassung der Optimierungsregeln
Das ist eine Menge Zeug, nicht wahr? Atmen wir erst einmal durch und schreiben eine Liste der bisher beschriebenen Optimierungsaktionen auf.
- HTML-, CSS- und JavaScript-Ressourcen verkleinern, komprimieren und zwischenspeichern.
- Minimieren der Verwendung von Render-Blocking-Ressourcen (insbesondere CSS)
- Use media queries on
linktags - Split stylesheets and inline critical CSS
- Combine multiple CSS files
- Use media queries on
- Minimierung des Einsatzes von Parser-Blockier-Ressourcen (JavaScript)
defer-Attribut in den Skript-Tags verwendenasync-Attribut in den Skript-Tags verwenden- Inline-JavaScript und
skript-Tags an den unteren Rand des Dokuments verschieben
Nun, da wir die grundlegenden Konzepte der Critical Rendering Path Optimierung kennen, können wir einen Blick auf einige beliebte Optimierungs-Plugins von WordPress werfen.
Optimierung des Critical Rendering Path in WordPress
WordPress-Benutzer können eine Reihe von Plugins nutzen, die fast jeden Aspekt des Optimierungsprozesses abdecken. Du kannst ein Plugin mit vollem Funktionsumfang installieren, oder du kannst mehrere Plugins auf einmal installieren, die jeweils spezifische Optimierungsfunktionen bieten.
“Wenn deine Webseite bei Kinsta gehostet wird, brauchst du kein Caching-Plugin, da bei Kinsta keine WordPress-Caching-Plugins benötigt werden.”
W3 Total Cache
Dieses einzelne Plugin deckt fast jede Phase des Optimierungsprozesses des Critical Rendering Path ab. Auf den ersten Blick kann die Plugin-Konfiguration überwältigend sein, aber sobald du mit der Sequenz des Critical Rendering Path besser vertraut bist, wirst du in der Lage sein, die Vorteile eines leistungsstarken Performance-Toolsets zu nutzen.
Hier ist eine Liste einiger Plugin-Funktionen:
- HTML (Beiträge und Seiten), CSS und JavaScript-Caching im Speicher, auf der Festplatte oder im CDN
- Zwischenspeicherung von Feeds, Suchergebnissen, Datenbankobjekten, WordPress-Objekten und Fragmenten
- HTML (Beiträge und Seiten) Minifikation (HTML)
- JavaScript- und CSS-Minifizierung
- JavaScript-Optimierung mit
asyncunddefer - Browser-Caching mit Cache-Kontrolle, zukünftigen Expire-Headern und Entity-Tags
- HTTP (gzip)-Komprimierung
- Google PageSpeed-Ergebnisse auf dem WordPress-Dashboard
Dies sind nur einige der vielen Features von W3TC. Du kannst mehr über alle Funktionen, Einstellungen und Optionen des Plugins in dieser ausführlichen Anleitung lesen.
WP Super Cache
WP Super Cache ist ein weiteres beliebtes Plugin für die Webseiten-Performance.
Er verfügt über eine gute Anzahl von Optimierungsfunktionen, ist aber weniger umfangreich als der vorherige W3 Total Cache und mag für Anfänger und fortgeschrittene Benutzer erschwinglicher aussehen.
Im Wesentlichen bietet es Caching-Funktionen und HTTP-Komprimierung, aber es fehlt die Ressourcenminimierung und JavaScript-Optimierung mit async– und defer-Attributen. Mehr als eine Million aktive Installationen beweisen jedoch, dass das Plugin einen Versuch wert ist.
Autoptimize
Mit über 1.000.000 aktiven Installationen ist Autoptimize eines der beliebtesten kostenlosen Plugins für die Minifizierung.
Es wird mit einer Optionsseite geliefert, die in mehrere Abschnitte unterteilt ist, auf denen der Seiten-Administrator die HTML-, CSS- und JavaScript-Minifikation separat konfigurieren kann.
Du kannst auch unabhängige Skripte oder Stylesheets aggregieren und Ausnahmen für bestimmte Ressourcen festlegen. Darüber hinaus ermöglicht Autoptimize die Zwischenspeicherung von minimierten Ressourcen auf der Festplatte oder im CDN und die Speicherung optimierter Assets als statische Dateien. Um die besten Einstellungen für Ihre WordPress-Site zu finden, können Sie unserem detaillierten Autoptimize-Leitfaden hier folgen.
Andere Optimierungs-Plugins, die du vielleicht ausprobieren möchtest:
Swift Performance
Swift Performance ist ein weiteres Plugin, das du dir vielleicht ansehen solltest. Hierbei handelt es sich um ein Premium-Plugin, das dir helfen kann, deine Leistungswerte zu steigern, und das speziell entwickelt wurde, damit du versuchen kannst, die 100/100 Google PageSpeed Insights-Ergebnisse zu erreichen.
Einige seiner Hauptmerkmale sind
- Man kann nicht nur CSS- und Javascript-Dateien verkleinern und kombinieren, sondern kann auch on-the-fly wichtige CSS für die Seiten erstellen.
- Intelligentes Caching, sowie AJAX und dynamische Anfragen.
- Eingebaute verlustfreie Bildkomprimierung.
- CDN-Unterstützung.
Einen tieferen Einblick in die WordPress-Optimierungs-Plugins findest du unter Wie man Render-Blockierungen von JavaScript und CSS eliminiert.
Fazit
Die Optimierung des Critical Rendering Path ist ein Prozess der Verbesserung und Messung, der ein klares Verständnis jeder Aufgabe erfordert, die der Browser ausführt, um Code in Pixel umzuwandeln und so eine Seite auf dem Bildschirm zu rendern. Du kannst mehr über den Critical Rendering Path im Optimierungsleitfaden von Google erfahren.
Hier im Kinsta-Blog versuchen wir, jeden Aspekt der Leistungsoptimierung abzudecken. Hier findest du eine Liste weiterer Artikel:
- Netzwerk-Latenzzeit – Vergleich der Auswirkungen auf deine WordPress-Seite
- WordPress CDN – Warum du eines verwenden solltest
- Wie man Bilder für Web und Leistung optimiert
- Wie TTFB reduziert werden kann, um die Ladezeiten von WordPress-Seiten zu verbessern
- Ein tiefer Einblick in das GTmetrix-Geschwindigkeitstest-Tool
- 14 kostenlose Webseiten-Geschwindigkeitstest-Tools für WordPress-Benutzer
- 8 weniger bekannte (aber nützliche) WordPress-Performance-Plugins
- Wie man in Google PageSpeed Insights mit WordPress 100/100 Punkte erzielt
Wie lange dauert es, den Critical Rendering Path deiner Webseiten zu optimieren? Und welche Aspekte des Optimierungsprozesses sind für dich am schwierigsten zu meistern? Lasst es uns in den folgenden Kommentaren wissen.
Carlo is a passionate lover of webdesign and front-end development. He has been playing with WordPress for more than 20 years, also in collaboration with Italian and European universities and educational institutions. He has written hundreds of articles and guides about WordPress, published both on Italian and international websites, as well as on printed magazines. You can find him on LinkedIn.
Schreibe einen Kommentar