SEO-News

Kritischer Rendering-PfadDie Ladezeit einer Webseite wird durch den Kritischen Rendering-Pfad bestimmt. Durch die Optimierung dieses Pfades und der mit ihm verbundenen Ressourcen lassen sich deutliche Verbesserungen des Page Speeds erzielen.

Beim Laden einer Webseite laufen im Hintergrund zahlreiche Prozesse ab. Die einzelnen für den Aufbau der Seite benötigten Ressourcen wie HTML, CSS und JavaScript müssen 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.

Hinweis: Die nachfolgenden Beschreibungen und Optimierungsvorschläge stützen sich im Wesentlichen auf die hervorragende Dokumentation von Google zu diesem Thema. An einigen Stellen wurden Erweiterungen vorgenommen, andere Ausführungen wurden verkürzt, um den Beitrag übersichtlicher zu gestalten.

 

Kritischer Rendering-Pfad - die einzelnen Schritte

Bevor eine Webseite angezeigt werden kann, müssen zunächst die einzelnen Zeichen oder Bytes, die vom Server geliefert werden, geparst und in sogenannte Token umgewandelt werden wie zum Beispiel in ein <div>-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.

Die folgenden Darstellung zeigt exemplarisch ein DOM, ein CSSOM und den daraus resultierenden Render Tree:

 

DOM, CSSOM und Render Tree

Bild: Google

 

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 Rastern bezeichnet 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:

 

Flash of Unstyled Content (FOUC) - 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.

Im folgenden Beispiel gibt es zwei Kritische Ressourcen, nämlich das HTML und CSS. Es finden zwei Netzwerkumläufe statt, um die Kritischen Ressourcen abzufragen. Die Kritischen Bytes haben eine Größe von 9 Kilobytes.

 

Kritischer Rendering-Pfad: Beispiel

Bild: Google

 

Gleichzeitig kann man sehen, wie der Rendering-Prozess an verschiedenen Stellen nicht fortgesetzt wird ("idle"), weil auf das Netzwerk gewartet werden muss.

Etwas komplexer ist das folgende Beispiel. Hier wird zusätzlich ein JavaScript geladen. Erst nach dem Ausführen des JavScripts kann das DOM erzeugt werden:

 

Kritischer Rendering-Pfad mit blockierendem JavaScript

Bild: Google

 

Anders sieht es aus, wenn man das JavaScript als async kennzeichnet. Das führt dazu, dass das DOM bereits vor dem Ausführen das JavaScripts erstellt werden kann:

 

Kritischer Rendering-Pfad mit asynchron ausgeführtem JavaScript

 

Bild: Google

 

Dies führt zu einer Verkürzung des Kritischen Rendering-Pfades. Die Zahl der Kritischen Ressourcen sinkt von drei auf zwei.

Noch schneller kann die Seite gerendert werden, wenn das geladene CSS das Rendern der Seite nicht blockiert. Angenommen, das CSS diene lediglich zur Darstellung der Druckansicht. In diesem Fall genügt es für den Browser, das DOM zu laden, um die Seite anzeigen zu können. Das CSSOM kann danach erstellt werden:

 

Kritischer Rendering-Pfad mit asynchronem JavaScript sowie zweckgebundenem CSS

Bild: Google

 

Der Kritische Rendering-Pfad hat sich weiter verkürzt, die Anzahl der Kritischen Ressourcen ist auf eine gesunken.

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:

 

Lighthouse: Ergebnisdarstellung

 

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.

 


Christian Kunz

Von Christian Kunz

SEO-Experte. Sie benötigen Beratung für Ihre Webseite? Klicken Sie hier.



Anzeige von Clixado

Artikelveröffentlichungen auf starken Magazinen und Blogs

Wir kooperieren mit unzähligen Verlagen und Bloggern und können daher auf über 4000 Blogs zu fast allen Themengebieten Artikelplätze anbieten:

    - Nachhaltiger Linkaufbau, kein SEO-Netzwerk
    - Hohe Sichtbarkeitswerte, keine expired Domains
    - Einmalzahlung, keine Vertragsbindung

Für jede Artikelveröffentlichung erstellen wir hochwertigen Content mit mindestens 400 Wörtern und publizieren den Artikel mit einem DoFollow-Bachlink zu deiner Seite auf einem Magazin oder Blog deiner Wahl.

Frag uns unverbindlich nach Beispielen






Verwandte Beiträge

SEO-Newsletter bestellen

Mit dem SEO-Newsletter erhältst Du einmal pro Monat eine Übersicht der wichtigsten SEO-Meldungen auf SEO Südwest sowie Ankündigungen wichtiger SEO-Veranstaltungen. Zum Abonnieren des SEO-Newsletters ist die Einwilligung in die Datenschutzhinweise erforderlich. Zum Bestellen genügt die Angabe der E-Mail-Adresse. Per Klick auf den entsprechenden Button unten kann das Abonnement jederzeit gekündigt werden.
Ich stimme den Nutzungsbedingungen zu
 

SEO-Checkliste

SEO-Checkliste

 

Anzeigen







SEO-Beratung

Suchmaschinenoptimierung und SEO-Beratung für Karlsruhe, Baden und die Pfalz

 

06340/351-943

 

info(at)seo-suedwest.de

SEO-Schulung 2019

SEO-Schulung

Ganztägige Schulung "SEO-Grundlagen". Jetzt anmelden

Jetzt vernetzen

SEO-Glossar

SEO-Glossar

 

SEO-Kalender 2018

SEO-Kalender 2018

 

Onsite-Optimierung

Onsite-Optimierung

 

SEO- und Suchmaschinenblogs

Bekannt aus

Website Boosting


Internet World Business

SEO United


The SEM Post


Webselling

SEO selber machen

SEO selber machen

Sprecher auf

Auszeichnungen

iBusiness Top-100-Liste SEO-Dienstleister

SEO Südwest: Platz 5 bei den SEO-Wahlen 2014 zum besten deutschen SEO-Blog

 

SEO-united.de Tipp 12/15

SEO-Tipps und SEO-Tricks

IMAGE 'Noindex' oder robots.txt - wann ist welches Instrument das richtige?
Freitag, 09. Februar 2018
Um zu steuern, welche Seiten von Google und anderen Suchmaschinen gecrawlt und indexiert werden... Weiterlesen...
IMAGE Lighthouse: ein Top-Tool für die Performancemessung von Webseiten und PWAs
Montag, 16. Oktober 2017
Lighthouse ist ein Tool, mit dem man die Performance und die Nutzerfreundlichkeit von Progressive... Weiterlesen...
IMAGE Tipp: Reddit für den Aufbau von Backlinks nutzen
Samstag, 17. Januar 2015
Die Social-News-Plattform Reddit erlaubt den Aufbau von guten Backlinks - wenn man sich an... Weiterlesen...

News aus dem Blog

IMAGE SEO: Linkbuilding gehört dazu
Donnerstag, 09. August 2018
Ohne den konstanten und nachhaltigen Aufbau hochwertiger Links bringen die besten Onpage-Maßnahmen... Weiterlesen...
IMAGE Google Webmaster Hangout: A visit at the Google Zurich office
Donnerstag, 05. Juli 2018
I was invited to Google Zurich to take part in a new episode of the Webmaster Office Hangout. I was... Weiterlesen...
IMAGE Neuer SEO-Contest: Punktesystem soll für mehr Fairness und Chancen sorgen
Montag, 30. Juli 2018
Im Rahmen eines neuen SEO-Contests kämmpfen wieder zahlreiche Publisher und Webseitenanbieter um... Weiterlesen...

 Eine Auswahl zufriedener Kunden

Rebel - Bad Küche Raum
Schöne Haare Karlsruhe
kr3m
feel-perfect.eu - Die Nährstoffexperten border=
Flintec IT GmbH
ESM Academy
Ringladen

Verbinden und Informationen zu SEO Südwest

Impressum und Datenschutz

Social Networks und RSS-Feed