Auf den Punkt gebracht

• Critical Rendering Path ist der Ladeweg, den der Browser durchlaufen muss, um den sichtbaren Bereich darzustellen
• Damit der Browser eine Seite darstellen kann, müssen folgende Prozesse durchlaufen werden: Parsing und Erstellung DOM und CSSOM, Erstellung Baumstruktur, Layout und Painting
• Folgende Schritte sind für die Optimierung des Critical Rendering Paths notwendig: Bytes minimieren, kritische Ressourcen minimieren und Critical Rendering Path Länge reduzieren

Critical Rendering Path Definition

Für den Nutzer ist es wichtig, wann er mit der Webseite interagieren kann (siehe auch “objektive vs. subjektive Zeit”). Daher müssen wir sicherstellen, dass der sofort sichtbare Bereich bevorzugt geladen wird. Critical Rendering Path ist also der Ladeweg, den der Browser durchlaufen muss, um den sichtbaren Bereich darzustellen.

Wie das genau gemacht wird, erfährst du weiter unten. Bevor du jedoch in die Optimierungen einsteigst, solltest du verstehen, wie ein Browser funktioniert und Webseiten lädt. Was zwischen der Eingabe der URL in die Adresszeile und dem Darstellen der Seite im Browser passiert, bekommen wir im Detail überhaupt nicht richtig mit. Erst wenn wir das verstehen, können wir effizient optimieren. Daher ließ dir zunächst diesen Artikel durch.

Wie können wir den Critical Rendering Path optimieren?

Für die Optimierung des Critical Rendering Paths sind folgende Schritte notwendig:

1. Bytes minimieren
2. Kritische Ressourcen minimieren
3. Critical Rendering Path Länge reduzieren
4. Critical CSS und JavaScript auslagern

Bytes minimieren

Je weniger Bytes der Browser verarbeiten muss, desto schneller wird die Seite gerendert. Daher sollten HTML, CSS und JavaScript minimiert, komprimiert und gecacht werden. Zudem sollte man die Anzahl an CSS- und JavaScript-Dateien reduzieren. Nachfolgend gehe ich auf die wichtigsten Optimierungen ein.

• Kommentare entfernen: HTML-, CSS- und JavaScript enthalten sehr oft Kommentare, die zwar für Entwickler hilfreich, aber für Browser unwichtig sind. Die Gesamtgröße der Seite kann reduziert werden, indem man diese Kommentare entfernt.
• Leerzeichen: Ähnlich wie bei den Kommentaren, kann das Entfernen von Leerzeichen in HTML, CSS und JavaScript zu Einsparungen bei der Größe führen.
• Nicht benötigen Code entfernen: Gibt es CSS-Klassen und -Anweisungen, die gar nicht greifen? Gibt es doppelte CSS-Deklarationen? Zum Beispiel könnte in der style.css .header {font-size: 12px} und weiter unten .header {width: 50%} stehen. Hier sollten wir die 2 zu einer Deklaration zusammenfassen, um ein paar Bytes einzusparen.
• Komprimierung: Bei der Komprimierung werden Dateien wie HTML, CSS und JavaScript vom Server in abgespeckter Form an den Browser gesendet, der diese dann wiederum entpackt. Dadurch werden kleinere Dateien versendet, was zu einer besseren Ladegeschwindigkeit führt. Wie man GZIP-Komprimierung aktiviert, kann man hier nachlesen. Alternativ kann man auch Brotli einsetzen.

Die ersten 3 Methoden werden auch als “Minify” bzw. “Minification” bezeichnet. Dabei helfen folgende Tools:

• http://refresh-sf.com/
• https://cssminifier.com/
• https://csscompressor.com/
• https://jscompress.com/
• https://unused-css.com/

Kritische Ressourcen minimieren

Von einer “kritischen Ressource” spricht man, wenn diese das erste Rendern der Seite blockieren kann. Je weniger Ressourcen verwendet werden, desto weniger muss der Browser arbeiten. Vor allem bei CSS- und JavaScript-Dateien ist das kritisch (je weniger Dateien desto besser). Hier sollte man bei CSS die Media-Queries-Abfrage und bei JavaScript das Attribut “async” verwenden.

Was sind CSS Media Queries?
Bei CSS Media Queries handelt es sich um Medienabfragen. Damit kann man steuern wann ein CSS genau ausgespielt werden soll. Sehen wir uns folgende CSS-Angaben an:
<link href="style.css" rel="stylesheet">
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 320px)">
Im ersten Bespiel gibt es keine Medienabfrage, daher wird dieses CSS in allen Medien zur Verfügung gestellt, wodurch das Rendering blockiert wird. Im zweiten Fall wird das CSS nur bei der Druckversion angewendet. Beim Laden der Seite wird dieses CSS das Seiten-Rendering nicht blockieren, wenn es nicht benötigt wird. Die dritte Zeile enthält eine Bedingung, die vom Browser erfüllt werden muss. Nur wenn die Seite min. 320 Pixel breit ist, wird dieses CSS benötigt. In diesem Fall wird dann das Rendering blockiert.

Viele Webseiten stellen ein allgemeines CSS (style.css) und ein Druck-CSS (print.css) zur Verfügung, vergessen aber die Medienabfrage bei der Druckversion. Hier muss dann der Browser 2 renderblockierende CSS bearbeiten (obwohl 1 CSS zum Zeitpunkt des Ladens nicht benötigt wird). Besser wäre es die Druckdatei mit media="print" zu versehen.

Was bedeutet “async” bei JavaScript?
Mit dem async-Attribut lädt der Browser die JS-Ressource parallel zu den anderen Ressourcen. Vor allem externe Skripte sollten mit async gekennzeichnet werden, da viele externe JS-Dateien das Laden der eigenen Seite deutlich verlangsamen können. Bei internen Skripten sollte eine Rücksprache mit den Entwicklern erfolgen, um zu prüfen bei welchen Skript async Sinn macht und bei welchen nicht. Alternative Methoden wäre das JavaScript am Ende zu laden oder mit defer zu arbeiten. Zusammengefasst gibt es also folgende Möglichkeiten:

• Mit asnyc JavaScript asynchron laden
• Mit defer JavaScript verzögert laden
• JavaScript am Ende laden lassen

Critical Rendering Path Länge reduzieren

Um die Länge des CRP zu reduzieren, sollten im besten Fall alle notwendigen Dateien im ersten Roundtrip mitgegeben werden, der ca. 14 KB schwer sein kann.

Was ist damit genau gemeint?
Bevor der Browser anfängt eine Seite zu rendern, geschieht vorher folgendes:

• Nutzer gibt die URL in die Adresszeile ein
• DNS Lookup: Die Domain wird in eine IP-Adresse umgewandelt (ca. 200 Millisekunden)
• TCP Connection (ca. 200 Millisekunden)
• HTTP-Request und HTTP-Response (ca. 200 Millisekunden)
• Server-Antwortzeit (im besten Fall ca. 200 Millisekunden)
• Rendering (im besten Fall ca. 200 Millisekunden)

Für den Critical Rendering Path sollte das alles im besten Fall innerhalb 1 Sekunde passieren, damit die Seite für den Nutzer als “schnell” wahrgenommen wird. Damit wir diese Zeit erreichen können, ist es wichtig, dass wir neben der Optimierung der Server-Antwortzeit sowie von CSS- und JS-Dateien, dafür sorgen, dass alle notwendigen Dateien im ersten Roundtrip (auch Roundtrip Time – Abk. RRT – genannt) mitgegeben werden: Der oben genannte Prozess muss für jede Ressource durchgeführt werden. Der Webseiteninhalt wird dabei in Stücken heruntergeladen. Das erste Stück bzw. Paket, was der Server schickt hat eine maximale Größe von ca. 14 KB. Wenn wir es schaffen unsere Dateien so zu optimieren, dass diese für den kritischen Rendering-Pfad nicht mehr als 14 KB groß sind, können wir die maximal mögliche Seitenladegeschwindigkeit erreichen. Sollte der Critical Rendering Path z.B. 15 KB groß sein, müssen schon 2 Roundtrips stattfinden. Hinweis: Dies gilt für HTTP/1.x, bei HTTP/2 werden alle Dateien innerhalb eines Pakets mitgegeben.

Critical CSS und JavaScript auslagern

Bei diesem Punkt geht es darum die CSS- und JavaScript-Datei zu teilen:

• 1. Teil: Alle Angaben, die für das Laden des kritischen Rendering-Pfades gebraucht werden, sollten inline im Head-Bereich der Seite geladen werden.
• 2. Teil: Alle Angaben, die nicht für das Laden des kritischen Rendering-Pfades gebraucht werden, sollten in eine separate Datei gepackt werden und können am Seitenende geladen werden.

Weitere Tipps zur Optimierung

Neben den oben genannten Techniken nachfolgend noch ein paar weitere Tipps zur Optimierung, die nicht nur auf den kritischen Rendering-Pfad Auswirkungen haben, sondern die allgemeine Performance beeinflussen.

Unnötige Downloads beseitigen

Auf Webseiten werden immer mehr und öfter neue Techniken eingesetzt (z.B. spezielle Bildergalerien), die HTTP-Requests verursachen. Um auf der Webseite unnötige Ressourcen zu identifizieren, sind folgende Schritte sinnvoll:

1. Erstellung Liste aller Ressourcen auf der aktuellen Seite
2. Messung der Leistung der einzelnen Ressourcen
3. Beurteilung, ob die Ressourcen einen Mehrwert bieten

Sicherlich wird man auf Elemente stoßen, die unnötig sind und die Performance der Seite beeinträchtigen. Beispielsweise könnte ein Slider im Einsatz sein, mit dem man sich durch 10 Bilder durchklicken kann. Folgende Fragen kann man sich dabei z.B. stellen:

• Wie schnell laden die Bilder?
• Sind die Bilder optimiert bzw. komprimiert?
• Klicken sich Nutzer wirklich komplett durch oder würden 3 Bilder auch reichen?
• Braucht man den Slider überhaupt noch?
• Bietet diese Technik den Nutzern einen Mehrwert?

Beachte, dass die Liste nicht nur eigene Ressourcen beinhalten soll, sondern auch Tools und Elemente von Drittanbietern (z.B. Social Icons, die sehr oft einiges an HTTP-Requests generieren). Bei der Beurteilung, ob Ressourcen minimiert oder gar eliminiert werden sollten, macht es Sinn auch Messungen wie A/B-Tests durchzuführen, um die Nutzer-Interaktion mit den betroffenen Elementen (z.B. Bildergalerie) zu messen.

Bilder optimieren

Die Bildoptimierung wird hier ausführlich thematisiert.

Webfonts optimieren

Über die Optimierung von Schriftarten kannst du hier mehr erfahren.