Den kritischen Pfad verstehen

Der kritische Rendering-Pfad bezieht sich auf die Schritte, die erforderlich sind, bis das Rendering der Webseite im Browser beginnt. Zum Rendern von Seiten benötigen Browser das HTML-Dokument selbst sowie alle wichtigen Ressourcen, die zum Rendern des Dokuments erforderlich sind.

Das Abrufen des HTML-Dokuments im Browser wurde im vorherigen Modul Allgemeine HTML-Leistungsaspekte behandelt. In diesem Modul sehen wir uns jedoch genauer an, was der Browser nach dem Herunterladen des HTML-Dokuments zum Rendern der Seite tut.

Progressives Rendering

Das Web ist von Natur aus verteilt. Im Gegensatz zu nativen Anwendungen, die vor der Verwendung installiert werden, können Browser nicht darauf angewiesen sein, dass Websites alle Ressourcen haben, die zum Rendern der Seite erforderlich sind. Daher können Browser Seiten sehr gut schrittweise rendern. Systemeigene Apps haben in der Regel eine Installationsphase und dann eine Ausführungsphase. Bei Webseiten und Webanwendungen sind jedoch die Linien zwischen diesen beiden Phasen weitaus weniger klar, weshalb Browser entsprechend entworfen wurden.

Sobald der Browser über Ressourcen zum Rendern einer Seite verfügt, wird er normalerweise damit beginnen. Daher muss die Entscheidung getroffen werden, wann gerendert werden soll: Wann ist es zu früh?

Wenn der Browser so schnell wie möglich rendert, wenn er nur etwas HTML enthält, aber noch bevor CSS oder das erforderliche JavaScript vorhanden ist, sieht die Seite für das endgültige Rendering kurzzeitig fehlerhaft aus und ändert sich erheblich. Das ist eine schlechtere Erfahrung, als anfangs eine Zeit lang einen leeren Bildschirm anzuzeigen, bis der Browser mehr Ressourcen für ein erstes Rendering hat, das eine bessere Nutzererfahrung bietet.

Wenn der Browser andererseits wartet, bis alle Ressourcen verfügbar sind, anstatt ein sequenzielles Rendering auszuführen, muss der Nutzer lange warten. Dies ist häufig unnötig, wenn die Seite zu einem viel früheren Zeitpunkt verwendbar war.

Der Browser muss die Mindestanzahl von Ressourcen kennen, auf die er warten muss, um eine offensichtlich fehlerhafte Nutzererfahrung zu vermeiden. Andererseits sollte der Browser auch nicht länger als nötig warten, bevor er dem Nutzer Inhalte präsentiert. Die Abfolge der Schritte, die der Browser vor dem ersten Rendern durchführt, wird als kritischer Rendering-Pfad bezeichnet.

Wenn Sie den kritischen Rendering-Pfad verstehen, können Sie die Webleistung verbessern, da Sie das anfängliche Seiten-Rendering nicht mehr als nötig blockieren. Gleichzeitig darf das Rendering aber nicht zu früh erfolgen. Entfernen Sie dazu die erforderlichen Ressourcen für dieses erste Rendering aus dem kritischen Rendering-Pfad.

Der (kritische) Rendering-Pfad

Der Rendering-Pfad umfasst die folgenden Schritte:

• Dokumentobjektmodell (DOM) aus HTML erstellen
• CSS-Objektmodell (CSSOM) aus CSS erstellen
• JavaScript anwenden, das das DOM oder CSSOM ändert
• Die Rendering-Baumstruktur aus DOM und CSSOM erstellen
• Stil- und Layoutvorgänge auf der Seite ausführen, um zu sehen, welche Elemente wo hineinpassen
• Zeichnen Sie die Pixel der Elemente im Arbeitsspeicher.
• Die Pixel setzen sich zusammen, falls sich einige davon überlappen.
• Zeichnen Sie alle resultierenden Pixel physisch auf den Bildschirm.

Erst wenn alle diese Schritte abgeschlossen sind, sieht der Nutzer Inhalte auf dem Bildschirm.

Dieser Renderingprozess findet mehrmals statt. Das erste Rendering löst diesen Prozess aus. Sobald jedoch mehr Ressourcen verfügbar sind, die sich auf das Rendering der Seite auswirken, führt der Browser diesen Prozess – oder auch nur Teile davon – noch einmal aus, um zu aktualisieren, was der Nutzer sieht. Der kritische Rendering-Pfad konzentriert sich auf den zuvor beschriebenen Prozess für das erste Rendering und hängt von den dafür erforderlichen kritischen Ressourcen ab.

Welche Ressourcen befinden sich im kritischen Rendering-Pfad?

Der Browser muss warten, bis einige wichtige Ressourcen heruntergeladen wurden, bevor das erste Rendering abgeschlossen werden kann. Zu diesen Ressourcen gehören:

• Teil des HTML-Codes.
• Der CSS-Code, der das Rendering blockiert, im <head>-Element.
• JavaScript im <head>-Element, das das Rendering blockiert.

Ein wichtiger Punkt ist, dass der Browser HTML Streaming verarbeitet. Sobald der HTML-Code einer Seite vom Browser abgerufen wird, beginnt er mit der Verarbeitung. Der Browser kann dann – und das tut es – häufig entscheiden, sie gut zu rendern, bevor der Rest der HTML einer Seite empfangen wird.

Wichtig ist, dass der Browser normalerweise nicht auf das erste Rendering wartet:

• Der gesamte HTML-Code.
• Schriftarten
• Bilder
• JavaScript, das nicht das Rendering blockiert, außerhalb des <head>-Elements (z. B. <script>-Elemente am Ende des HTML-Codes).
• Nicht renderndes CSS außerhalb des <head>-Elements oder CSS mit einem media-Attributwert, der nicht für den aktuellen Darstellungsbereich gilt.

Schriftarten und Bilder werden vom Browser oft als Inhalte betrachtet, die bei nachfolgenden erneuten Seiten-Renderings eingefügt werden, sodass sie das anfängliche Rendering nicht aufhalten müssen. Dies kann jedoch bedeuten, dass im ersten Rendering Leerräume vorhanden bleiben, während Text verborgen bleibt, während Schriftarten verwendet wurden, oder bis Bilder verfügbar sind. Noch schlimmer ist, wenn für bestimmte Inhaltstypen nicht genügend Platz reserviert ist, insbesondere wenn im HTML-Code keine Bildabmessungen angegeben sind. Das Layout der Seite kann sich beim Laden dieser Inhalte später verschieben. Dieser Aspekt der Nutzererfahrung wird mit dem Messwert Cumulative Layout Shift (CLS) gemessen.

Das <head>-Element ist entscheidend für die Verarbeitung des kritischen Rendering-Pfads. So viel, dass das Thema im nächsten Abschnitt ausführlicher behandelt wird. Die Optimierung des Inhalts des <head>-Elements ist ein wichtiger Aspekt der Webleistung. Zum besseren Verständnis des kritischen Rendering-Pfads reicht es jedoch aus, dass das <head>-Element Metadaten zu der Seite und ihren Ressourcen enthält, aber keinen tatsächlichen Inhalt, den der Nutzer sehen kann. Sichtbare Inhalte sind im <body>-Element enthalten, das auf das <head>-Element folgt. Bevor der Browser einen Inhalt rendern kann, benötigt er sowohl die zu rendernden Inhalte als auch die Metadaten für das Rendering.

Allerdings sind nicht alle Ressourcen, auf die im Element <head> verwiesen wird, für das ursprüngliche Rendern der Seite unbedingt erforderlich. Der Browser wartet daher nur auf die Ressourcen, die tatsächlich vorhanden sind. Um zu ermitteln, welche Ressourcen sich im kritischen Rendering-Pfad befinden, müssen Sie wissen, welche CSS und JavaScript-Elemente das Rendering und den Parser blockieren.

Ressourcen, die das Rendering blockieren

Einige Ressourcen sind so wichtig, dass der Browser das Rendern der Seite pausiert, bis sie erledigt sind. CSS fällt standardmäßig in diese Kategorie.

Wenn ein Browser CSS erkennt – egal, ob es sich um Inline-CSS in einem <style>-Element oder eine extern referenzierte Ressource handelt, die durch ein <link rel=stylesheet href="...">-Element angegeben wird –, rendert der Browser keine weiteren Inhalte, bis der Download und die Verarbeitung dieses CSS abgeschlossen sind.

Nur weil eine Ressource das Rendering blockiert, bedeutet das nicht zwangsläufig, dass der Browser sonst nichts weiter tun kann. Browser versuchen, so effizient wie möglich zu sein. Wenn ein Browser feststellt, dass er eine CSS-Ressource herunterladen muss, fordert er dies an und pausiert das Rendering, verarbeitet jedoch weiterhin den Rest des HTML-Codes und sucht in der Zwischenzeit nach weiteren Arbeiten.

Ressourcen wie CSS, die das Rendering blockieren, blockieren das gesamte Rendering der Seite, nachdem sie erkannt wurden. Ob ein CSS-Code das Rendering blockiert oder nicht, hängt also davon ab, ob der Browser ihn erkannt hat. Einige Browser (anfangs Firefox und jetzt auch Chrome) blockieren das Rendern von Inhalten unterhalb der Ressource, die das Rendering blockiert. Für den kritischen Pfad, der das Rendering blockiert, sind also in der Regel Ressourcen im <head> wichtig, die das Rendering blockieren, da sie das Rendering der gesamten Seite blockieren.

Eine neuere Innovation ist das Attribut blocking=render, das in Chrome 105 hinzugefügt wurde. Dadurch können Entwickler ein <link>-, <script>- oder <style>-Element explizit als Rendering-blockierend markieren, bis das Element verarbeitet wurde. Der Parser kann das Dokument aber in der Zwischenzeit weiter verarbeiten.

Parserblockierende Ressourcen

Ressourcen, die Parser blockieren, sind solche, die den Browser daran hindern, über das weitere Parsen des HTML-Codes nach anderen Aufgaben zu suchen. JavaScript blockiert standardmäßig den Parser (es sei denn, es ist ausdrücklich als asynchron oder verzögert gekennzeichnet), da es das DOM oder das CSSOM bei der Ausführung ändern kann. Daher kann der Browser erst dann weitere Ressourcen verarbeiten, wenn er die vollständigen Auswirkungen des angeforderten JavaScript auf den HTML-Code einer Seite erkannt hat. Synchrones JavaScript blockiert daher den Parser.

Ressourcen, die den Parser blockieren, blockieren auch effektiv das Rendering. Da der Parser eine Ressource, die das Parsen blockiert, erst dann fortsetzen kann, wenn sie vollständig verarbeitet wurde, kann er nicht auf den Inhalt zugreifen und ihn danach nicht rendern. Der Browser kann während der Wartezeit jeden bisher empfangenen HTML-Code rendern. Was jedoch der kritische Rendering-Pfad betrifft, bedeuten alle Ressourcen, die den Parser blockieren, im <head> praktisch, dass der gesamte Seiteninhalt blockiert wird.

Das Blockieren des Parsers kann hohe Leistungskosten verursachen – viel mehr als nur das Blockieren des Renderings. Aus diesem Grund versuchen Browser, diese Kosten zu reduzieren, indem sie einen sekundären HTML-Parser verwenden, den sogenannten Preload Scanner, um anstehende Ressourcen herunterzuladen, während der primäre HTML-Parser blockiert ist. Sie ist zwar nicht so gut wie das tatsächliche Parsen des HTML-Codes, ermöglicht aber zumindest, dass die Netzwerkfunktionen im Browser vor dem blockierten Parser arbeiten. Dadurch ist es weniger wahrscheinlich, dass er in Zukunft wieder blockiert wird.

Blockierende Ressourcen identifizieren

Viele Tools zur Leistungsüberwachung identifizieren Ressourcen, die das Rendering und den Parser blockieren. WebPageTest markiert Ressourcen, die das Rendering blockieren, mit einem orangefarbenen Kreis links neben der URL der Ressource:

Alle Ressourcen, die das Rendering blockieren, müssen heruntergeladen und verarbeitet werden, bevor das Rendering gestartet werden kann. Dies wird durch die durchgehende dunkelgrüne Linie im Wasserfall angegeben.

Lighthouse hebt auch Ressourcen hervor, die das Rendering blockieren, jedoch auf subtilere Weise und nur dann, wenn die Ressource das Rendern der Seite tatsächlich verzögert. Dies kann hilfreich sein, um falsch positive Ergebnisse zu vermeiden, wenn Sie das Rendering blockieren. Wenn Sie dieselbe Seiten-URL wie in der vorherigen WebPageTest-Abbildung über Lighthouse ausführen, wird nur eines der Stylesheets als Ressource zum Blockieren des Renderings identifiziert.

Den kritischen Rendering-Pfad optimieren

Zur Optimierung des kritischen Rendering-Pfads müssen Sie die Zeit bis zum Empfang des HTML-Codes (dargestellt durch den Messwert Time to First Byte (TTFB)) reduzieren, wie im vorherigen Modul beschrieben, und auch die Auswirkungen von Ressourcen reduzieren, die das Rendering blockieren. Diese Konzepte werden in den nächsten Modulen näher betrachtet.

Der kritische inhaltsbezogene Rendering-Pfad

Lange Zeit befasst sich der kritische Rendering-Pfad mit dem anfänglichen Rendering. Inzwischen sind jedoch mehr nutzerorientierte Messwerte zur Leistung im Web entstanden. Diese sind fraglich, ob der Endpunkt des kritischen Rendering-Pfads der allererste Paint oder eine der inhaltsreicheren Farben sein soll, die danach folgen.

Alternativ können Sie sich auch auf die Zeit bis zum Largest Contentful Paint (LCP) – oder sogar First Contentful Paint (FCP) – im Rahmen eines inhaltsreichen Renderingpfads (oder des Schlüsselpfads, wie andere es nennen) konzentrieren. In diesem Fall müssen Sie möglicherweise Ressourcen einbeziehen, die nicht unbedingt blockieren – wie es die typische Definition des kritischen Rendering-Pfads gab –, die aber zum Rendern von Contentful Paints erforderlich sind.

Unabhängig von Ihrer genauen Definition dessen, was Sie als „kritisch“ definieren, ist es wichtig zu verstehen, was das anfängliche Rendering und die wichtigsten Inhalte ausmacht. Beim First Paint wird die erste mögliche Möglichkeit gemessen, alles für den Nutzer zu rendern. Idealerweise sollte dies eine Aussagekraft (z. B. eine Hintergrundfarbe) sein. Aber auch wenn sie nicht inhaltlich nicht inhaltlich ist, kann es dennoch sinnvoll sein, dem Nutzer etwas zu präsentieren. Dies ist ein Argument zum Messen des kritischen Rendering-Pfads, wie er traditionell definiert wurde. Gleichzeitig kann auch gemessen werden, wann dem Nutzer der Hauptinhalt präsentiert wird.

Inhaltsbasierte Rendering-Pfad identifizieren

Viele Tools können LCP-Elemente und deren Rendering identifizieren. Neben dem LCP-Element hilft Lighthouse auch bei der Identifizierung von LCP-Phasen und der jeweils benötigten Zeit, damit Sie besser erkennen können, worauf Sie Ihre Optimierungsmaßnahmen am besten konzentrieren sollten:

Bei komplexeren Standorten hebt Lighthouse auch Ketten kritischer Anfragen in einer separaten Prüfung hervor:

Bei dieser Lighthouse-Prüfung werden alle Ressourcen beobachtet, die mit einer hohen Priorität geladen werden. Dazu gehören Webschriftarten und andere Inhalte, die Chrome als Ressource mit hoher Priorität einstuft, auch wenn sie das Rendering nicht blockiert.

Wissen testen

Nächster Schritt: Laden von Ressourcen optimieren

In diesem Modul ging es um die Theorie zum Rendern einer Webseite im Browser und darum, was für das anfängliche Rendering einer Seite erforderlich ist. Im nächsten Modul erfahren Sie, wie Sie diesen Renderingpfad optimieren können, indem Sie das Laden von Ressourcen optimieren.