Geschrieben von

Critical Rendering Path verstehen

Performance

Auf den Punkt gebracht

  • Eine schnelle Seitenladegeschwindigkeit bringt nicht nur SEO-Vorteile, sondern auch eine bessere Nutzererfahrung
  • Eine Seite sollte unter 1 Sekunde laden
  • 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

Warum PageSpeed wichtig ist

  • SEO: Längst hat Google angekündigt, dass der PageSpeed einer Seite zum Ranking-Faktor gehört. Zudem hat eine bessere Ladegeschwindigkeit positive Auswirkungen auf das Crawling der Inhalte.
  • Positive Nutzererfahrung: Heute muss alles schnell gehen! Nutzer erwarten das auch von Webseiten. Eine schnelle Ladegeschwindigkeit führt zu kleineren Absprungraten und längerer Verweildauer. 47 % der Nutzer erwarten, dass eine Seite innerhalb von 2 Sekunden lädt und 40 % verlassen die Seite innerhalb von 3 Sekunden, wenn diese nicht vollständig geladen wird (Quelle).
  • Mehr Umsätze: Bereits 100 ms können entscheidend sein, um 1 % mehr Umsatz zu generieren (Amazon-Beispiel). Eine Verzögerung von 1 Sekunde führt schon zu 7 % weniger Conversions, 16 % weniger Kundenzufriedenheit und 11 % weniger Seitenaufrufe (Quelle).

Wie schnell muss eine Seite laden (in Zahlen)?

Laut John Müller sollte eine Webseite zwischen 2 und 3 Sekunden geladen werden, damit Sie als „Schnell“ eingestuft wird.

Aus Usability-Sicht ist eine Seitenladegeschwindigkeit unter 1 Sekunde maßgebend, um den Fokus des Nutzers auf der Webseite zu behalten. Laut Nielsen kann die Wahrnehmung der Zeit aus Nutzer-Sicht folgendermaßen dargestellt werden:

  • 0-100 ms: Keine Verzögerung spürbar
  • 100-300 ms: Leicht spürbare Verzögerung
  • 300ms-1000ms: Spürbare Verzögerung, jedoch bleibt der Arbeitsfluss ungebrochen
  • 1000+ ms: Leichte gedankliche Abschweifung
  • 10000+ ms: Die Aufgabe wird unterbrochen

Oberstes Ziel sollte es also sein, die Ladegeschwindigkeit unter 100 ms zu bringen. Das ist gar nicht so leicht, wenn man nun bedenkt, was alles passieren muss, bevor eine Seite im Browserfenster dargestellt werden kann (Parsing, Erstellung Baumstruktur, Layout, Painting, etc.). Man kann jedoch dem Nutzer das Gefühl geben, dass die Seite schneller lädt als sie es eigentlich tut.

Objektive und subjektive Zeit

Was ist der Unterschied?

  • Objektive Zeit: Die objektive Zeit wird in Einheiten gemessen: Tage, Stunden, Sekunden, etc. Beispiel: Wir fahren mit dem Zug von München nach Salzburg und diese dauert 1 Stunde und 40 Minuten. Das können wir an unserer Uhr ablesen.
  • Subjektive Zeit: Die subjektive Zeit ist abhängig vom persönlichen Empfinden. Um beim obigen Beispiel zu bleiben: Wenn wir die ganze Fahrt lang auf unsere Uhr starren, spüren wir wie lange 1 Stunde und 40 Minuten dauern. Lesen wir während der Fahrt jedoch ein Buch, hören Musik oder schauen uns eine Serie an, so kommen wir ebenfalls in 1 Stunde und 40 Minuten in Salzburg an. Jedoch mit einem Unterschied: Wir haben die Fahrt nicht so lange empfunden. Es kommt uns vor, als ob wir nur 30 Minuten unterwegs waren, weil wir mit anderen Dingen beschäftigt waren. Jeder hatte sicher mal so ein Erlebnis, wo die Zeit wie im Flug vergeht.

Viele PageSpeed-Analyse-Tools analysieren die Seitenladeschwindigkeit der Webseiten und geben diese in Sekunden wieder (objektive Zeit). Dabei wird ermittelt, wie lange die Seite braucht, bis sie vollständig geladen wurde. Bei einer Seite, wo viele Ressourcen geladen werden müssen, kann das schon einige Sekunden in Anspruch nehmen (nehmen wir an unsere Seite braucht 5 Sekunden). Wir können dem Nutzer aber dennoch das Gefühl geben, dass unsere Seite innerhalb von 2 Sekunden lädt (subjektive Zeit). Wie? Indem wir zuerst nur alle Inhalte und Ressourcen laden, die für den ersten sichtbaren Bereich (Above the fold) notwendig sind. Mit der Optimierung des Critical Rendering Paths können wir gezielt die subjektiv empfundene Zeit des Nutzers ansprechen.

Critical Rendering Path Definition

Für den Nutzer ist es wichtig, wann er mit der Webseite interagieren kann. 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:

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.

Last modified: 31. Januar 2019