Performance optimieren: Den Rendering-Pfad verstehen

Der Rendering-Pfad bestimmt maßgeblich den Speed einer Webseite. Durch die Minimierung des Renderings und der dazugehörigen Ressourcen lassen sich deutliche Steigerung der Ladezeit erzielen.

Mehrere Prozesse laufen während des Aufrufens einer Webseite im Hintergrund. Alle Ressourcen wie HTML, CSS und JavaScript werden vom Server zum Browser übertragen und dort zu einer Seite zusammengefügt werden.

Die einzelnen Schritte, die durchlaufen werden müssen, bis der Browser in der Lage ist, eine Webseite anzuzeigen, wird auch als Kritischen Rendering-Pfad bezeichnet. Die Verkürzung dieses Pfades kann die Ladezeit einer Seite entscheidend verkürzen.

Der Kritische Rendering-Pfad

Bevor eine Webseite angezeigt werden kann, müssen zunächst die einzelnen Bytes, die vom Server geliefert werden in sogenannte Token umgewandelt werden, wie zum Beispiel in ein <style>-Tag. Aus den einzelnen Tags entseht im Anschluss eine Baumstruktur, das sogenannte Document Object Model (DOM). Ähnlich funktioniert dies auch bei CSS: Hier werden die einzelnen Token in ein CSS Object Model (CSSOM) überführt.

Aus DOM und CSSOM kann der Browser dann den Render Tree erstellen – das ist eine Baumstruktur, die nur solche Elemente enthält, die für das Rendern der betreffenden Seite benötigt werden. Nicht sichtbare Knoten wie beispielsweise Skript-Tags, Meta Tags oder auch per CSS ausgeblendete HTML-Knoten bleiben außen vor.

Ist der Render Tree einmal fertig erstellt, schließt sich im Browser die Layout-Phase an, die auch als Reflow bezeichnet wird. In dieser Phase wird die exakte Position aller dargestellten Elemente auf der Seite festgelegt. Dabei spielen die Anordnung der Elemente, deren Verschachtelung und auch der verfügbare Anzeigebereich eine Rolle.

Als Ergebnis der Layout-Phase entsteht ein Box-Modell. Position und Größe sowie Pixelpositionen gehen als Input in die folgende Phase ein, die als Painting oder Rasternbezeichnet wird.

Die Dauer für die bis jetzt genannten Phasen hängt natürlich stark vom Umfang und der Komplexität der zu verarbeitenden Ressourcen ab. Umso größer und verschachtelter HTML, CSS und JavaScript sind, desto länger dauert es, bis der Browser die Inhalte letztendlich anzeigen kann.

 

Wie CSS das Rendern blockieren kann

Grundsätzlich gilt: Das CSS einer Webseite sollte so schnell wie möglich geladen werden, weil die Seite in der Regel vorher nicht angezeigt werden kann.

Der Grund dafür ist einfach verständlich: Würde eine Seite ohne geladenes und verarbeitetes CSS angezeigt, sähe das Ergebnis in etwa aus wie im folgenden Beispiel:

 

Eine solche Darstellung wird auch als Flash of Unstyled Content (FOUC) bezeichnet. Damit es nicht dazu kommt, wartet der Browser mit der Darstellung der Seite, bis das CSS verfügbar ist und sowohl das DOM als auch das CSSOM vorliegen.

Um bestimmte CSS-Dateien davon abzuhalten, das Rendern zu blockieren, kann man sie mit einem Medientyp versehen. Dieser zeigt an, wann das CSS wirklich benötigt wird, etwa bei der Darstellung der Print-Ausgabe oder für bestimmte Geräte. Nur dann, wenn eine Situation vorliegt, in welcher das CSS auch benötigt wird, blockiert die betreffende Datei mit dem passenden Medientypen das Rendern. Ein Beispiel für einen Verweis auf eine CSS-Datei mit bestimmten Medientyp ist

<link href=“/print-css.css“ rel=“stylesheet“ media=“print“>

 

Wie JavaScript das Rendern blockieren kann

Per JavaScript lassen sich Knoten im DOM und CSSOM verändern. Anders gesagt: JavaScript kann sowohl das HTML als auch das CSS einer Seite manipulieren. So können zum Beispiel bestimmte HTML-Tags entfernt oder auch Attribute einzelner Tags angepasst werden, um auf diese Weise eine dynamische Anpassung der Seite im Browser zu bewirken.

Script-Tags im Quellcode einer Seite führen dazu, dass der HTML-Parser den Aufbau des DOMs unterbricht und vorübergehend die Kontrolle an die JavaScript-Engine übergibt. Erst wenn diese fertig ist, setzt der HTML-Parser seine Arbeit fort. Das zeigt: Durch das zwischenzeitliche Ausführen von JavaScript kann sich die Zeitspanne verlängern, die zur finalen Erstellung des DOMs benötigt wird.

Auch zwischen CSS und JavaScript besteht eine Wechselwirkung: Weil per JavaScript auch das CSSOM verändert werden kann, findet die Ausführung des JavaScripts erst statt, wenn der Aufbau des CSSOM fertig ist. Somit entsteht eine Abhängigkeitskette zwischen HTML, JavaScript und CSS:

• Das CSS bzw. das CSSOM muss geladen sein, damit das JavaScript ausgeführt werden kann
• Das JavaScript unterbricht ggf. das Parsen des HTML-Codes

Während Inline-JavaScript-Code immer zum Unterbrechen des HTML-Parsens führt, kann es bei extern eingefügten JavaScript-Dateien durch den Zusatz async vermieden werden. Damit wird dem Browser signalisiert, dass das JavaScript nicht exakt an der Stelle ausgeführt werden muss, an welcher sich der Verweis befindet. Der Aufbau des DOM wird damit nicht durch das JavaScript aufgehalten.

 

Wie kann man den Kritischen Rendering-Pfad messen?

Die meisten Browser bringen eine eingebaute Lösung mit, die es ermöglicht, die einzelnen Schritte oder Meilensteine zu messen, die beim Aufbau einer Seite durchlaufen werden. Zu diesem Zweck gibt es die sogenannte Navigation Timing API, mit der im Browser Daten gesammelt und bei Bedarf an den Server geschickt werden können. Dazu muss man einfach etwas JavaScript-Code in die zu testende Seite einbinden und erhält als Ergebnis – je nach Implementierung – verschiedene Kennzahlen.

Der folgende Code sorgt zum Beispiel dafür, dass nach dem load-Event der Seite von der aktuellen Zeit der Zeitstempel abgezogen wird, zu dem die aufgezeichnete Navigation begonnen hat. Das Ergebnis wird danach ausgegeben.

window.addEventListener("load", function() {

let now = new Date().getTime();

let loadingTime = now - performance.timing.navigationStart;

document.querySelector(".output").innerText = loadingTime + " ms"; }, false);

Man erhält einen Wert einen Wert in Millisekunden, den man als Vergleichsbasis nutzen kann.

Dies ist nur eine von vielen Anwendungsmöglichkeiten der Navigation Timing API. Nachfolgend sind die wichtigsten Zeitstempel zusammengefasst, die man auf diese Weise messen kann:

• domLoading: Dieser Zeitstempel steht am Beginn des Renderingprozesses. Der Browser wird im Anschluss damit beginnen, die empfangenen Bytes in Zeichen und Token umzuwandeln.
• domInteractive: Dieser Zeitstempel wird gesetzt, wenn der HTML-Code geparst und der DOM aufgebaut ist.
• domContentLoaded: Wenn der DOM bereit ist und kein JavaScript durch CSS blockiert ist, kann im Anschluss der Rendering Tree erstellt werden.
• domComplete: Die Verarbeitung inklusive des Herunterladens aller Ressourcen wie Bilder ist abgeschlossen.
• loadEvent: Das ist der Letzte Schritt beim Laden einer Seite: Der Browser gibt das onload-Event aus.

 

Den kritischen Rendering-Pfad optimieren

Um zu erklären, wie das Laden einer Seite durch Optimierung des Kritischen Rendering-Pfades beschleunigt werden kann, folgen zunächst einige wichtige Definitionen:

• Die Länge des kritischen Rendering-Pfades bestimmt sich sowohl durch die zum Abruf aller kritischen Ressourcen benötigten Zahl der Server-Abfragen (Umläufe) sowie die dazu benötigte Zeitdauer.
• Unter einer Kritischen Ressource versteht man eine Ressource, die das Rendern einer Seite blockiert.
• Kritische Bytes beschreiben, wie viele Bytes für das erste Rendern einer Seite übertragen werden müssen. Sie bestimmen sich durch die Dateigröße aller Kritischen Ressourcen.

 

Generell empfehlen sich zur Optimierung des Kritischen Rendering-Pfades die folgenden Maßnahmen:

• Den Kririschen Rendering-Pfad analysieren und verstehen: Welche Kritischen Ressourcen werden benötigt, wie hängen diese zusammen, wie groß sind sie und welche Netzwerkumläufe bzw. Serverabfragen müssen durchgeführt werden?
• Wie kann die Anzahl der Kritischen Ressourcen reduziert werden? Werden alle Ressourcen benötigt, können sie asynchron geladen werden etc.?
• Dafür sorgen, dass alle Kritischen Ressourcen möglichst früh geladen werden. Eine Möglichkeit dazu ist die Anweisung <link rel=“preload“>, die man in den Head des HTMLs einfügen kann. Damit lassen sich bestimmte Ressourcen wie zum Beispiel Fonts vorab laden, so dass sie zur Verfügung stehen, wenn sie zum Rendern einer Seite benötigt werden.
• Dateigröße der Kritischen Ressourcen minimieren: Dies kann zum Beispiel durch komprimierte Übertragung per gzip vom Server zum Client erreicht werden.
• Caching Kritischer Ressourcen: Wenn Kritische Ressourcen wie zum Beispiel bestimmte JavaScript- oder CSS-Dateien mit einer ausreichend langen Caching-Dauer versehen sind, müssen sie nicht bei jedem wiederkehrenden Besuch der Seite neu geladen werden, sondern werden im Browser zwischengespeichert.
• Zahl der Netzwerkumläufe bzw. der Serverrequests reduzieren: Dies kann zum Beispiel durch das Zusammenfassen mehrerer CSS- oder JavaScript-Dateien zu größeren Dateien erreicht werden.
• Lange Ausführung von JavaScript vermeiden: Wenn der Browser JavaScript-Code lange Zeit ausführen muss, hindert ihn das daran, das DOM und das CSSOM zu erstellen. Sämtliche Funktionalität, die nicht zum Rendern benötigt wird, sollte daher auf später verschoben werden. Notfalls kann eine Initialisierungslogik in mehrere Phasen aufgeteilt werden, damit sich der Browser zwischenzeitlich um das Rendern der Seite kümmern kann.
• CSS-Aufrufe in den Head integrieren: Damit CSS-Ressourcen frühzeitig geladen werden können, sollten diese im Head des HTML-Dokuments per <link> angezogen werden.
• Keine CSS-Importe: Das Importieren von Stylesheet-Informationen aus anderen Stylesheet-Dokumenten per @import verursacht zusätzliche Netzwerkumläufe. Dazu kommt, dass die importierten CSS-Ressourcen erst erkannt werden, nachdem das anfordernde CSS selbst geparst wurde.
• Kritisches CSS sollte nach Möglichkeit inline verwendet, also direkt in den HTML-Code integriert werden. Damit kann die Länge des Kritischen Rendering-Pfades verkürzt werden, weil weniger Netzwerkumläufe erforderlich sind und nur noch das HTML eine Kritische Ressource darstellt.

 

Tools zur Analyse des Kritischen Rendering-Pfads

Neben der oben bereits genannten Navigation Timing API bietet sich zur Analyse des Kritischen Pfads von Webseiten vor allem Lighthouse an – ein Tool, das von Google entwickelt wurde. Lighthouse läuft lokal auf dem Rechner des Nutzers und kann zum Beispiel als Erweiterung für den Chrome-Browser installiert werden.

Lighthouse zeigt unter anderem Kritische Ressourcen an, die das Rendern einer Seite blockieren. Auf diese Weise erhält man wertvolle Ansatzpunkte dazu, wie der Kritische Rendering-Pfad optimiert werden kann:

 

Auch Google PageSpeed Insights liefert Informationen zu Ressourcen, die das Rendern blockieren.

Darüber hinaus bieten sich zur Analyse des Kritischen Rendering-Pfads solche Tools an, die erfassen können, ob die auf einer Webseite verwendeten Ressourcen komprimiert übertragen und gecacht werden. Eines dieser Tools ist WebPagetest.

 

Fazit

Die Optimierung des Kritischen Rendering-Pfads ist eine der vielversprechendsten Möglichkeiten, die Ladezeit von Webseiten zu senken. Neben der Zahl der Kritischen Ressourcen spielt vor allem deren Abhängigkeit untereinander eine Rolle.

Mit Hilfe geeigneter Tools lässt sich der Kritische Rendering-Pfad verstehen und analysieren, um daraus Ansatzpunkte zur Optimierung abzuleiten.