Was ist der kritische Rendering-Pfad?

Was ist der kritische Rendering-Pfad?

Der kritische Rendering-Pfad (Critical Rendering Path, CRP) ist die Abfolge von Schritten, mit der ein Browser HTML, CSS und JavaScript in Pixel auf dem Bildschirm verwandelt: DOM aufbauen, CSSOM aufbauen, beides zu einem Render-Baum verbinden, das Layout berechnen und schließlich zeichnen. Alles, was der Browser vor diesem ersten Zeichnen laden und verarbeiten muss, liegt auf dem Pfad. Wer ihn verkürzt, bringt Inhalte schneller zu den Besuchern.

Wie der Browser den Pfad durchläuft

• DOM. Der Browser zerlegt das HTML in Tokens, dann in Knoten und baut daraus das Document Object Model. Das geschieht schrittweise und kann beginnen, bevor die ganze Datei angekommen ist. Laut MDN dauern die späteren Schritte umso länger, je mehr Knoten es gibt.
• CSSOM. Das CSS wird zum CSS Object Model verarbeitet. Anders als das DOM entsteht es nicht schrittweise, denn spätere Regeln können frühere überschreiben.
• Render-Baum. DOM und CSSOM werden kombiniert. Der Baum enthält nur sichtbare Inhalte: Elemente mit display: none samt ihren Nachfahren fehlen, ebenso der head.
• Layout. Der Browser berechnet Größe und Position jedes Elements. Das hängt von der Breite des Viewports ab und läuft daher bei jeder Größenänderung oder Drehung des Geräts erneut.
• Zeichnen (Paint). Der Browser zeichnet die Pixel. Beim Laden wird der ganze Bildschirm gezeichnet, danach nur noch die geänderten Bereiche.

Die Kennzahlen eines Speed-Reports liegen auf diesem Pfad. Der First Contentful Paint ist der Moment, in dem erstmals Inhalt gezeichnet wird. Jede Millisekunde, die der Pfad wartet, geht also direkt in diesen Wert ein.

Was den Pfad blockiert

CSS blockiert das Rendering. Laut MDN hält der Browser das Rendering zurück, bis er das gesamte CSS empfangen und verarbeitet hat. Regeln können überschrieben werden, deshalb lässt sich nichts zeichnen, bevor das CSSOM vollständig ist.

Klassische Skripte blockieren das Parsen. Ein Skript ohne async, defer oder type="module" wird sofort geladen und ausgeführt, bevor der Browser mit dem Parsen der Seite weitermacht (MDN). Lighthouse meldet ein script im Head ohne defer oder async sowie einen Stylesheet-Link, dessen media zum Gerät passt, als renderblockierend. Die beiden Attribute verhalten sich unterschiedlich: defer führt das Skript nach dem Parsen in Dokumentreihenfolge aus, noch vor DOMContentLoaded; async führt es aus, sobald es geladen ist, ohne garantierte Reihenfolge. Wann welches passt, steht unter asynchrones Laden.

Beispiel

Eine Marketing-Seite liefert ein großes Stylesheet für die ganze Website, ein Tag-Manager-Skript im Head und eine Slider-Bibliothek aus. Das erste Zeichnen wartet auf das Stylesheet und darauf, dass das Skript geladen und ausgeführt wird, obwohl der Besucher zunächst nur die Überschrift und das Hero-Bild braucht. Die Lösung hat drei Teile: die wenigen Regeln für den sichtbaren Bereich inline in einen <style>-Block legen, defer bei Skripten setzen, die der erste Bildschirm nicht braucht, und das Hero-Bild per Resource Hint früh anfordern.

<style>/* nur die Regeln für den ersten Bildschirm */</style>
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<script src="/app.js" defer></script>

So verkürzen Sie den Pfad

• Weniger kritische Ressourcen. Entfernen Sie alles, was der erste Bildschirm nicht braucht. Der Tab Coverage in den Chrome DevTools zeigt ungenutztes CSS und JavaScript.
• Kleinere kritische Ressourcen. CSS und JavaScript minifizieren und komprimieren, und das DOM nicht unnötig aufblähen.
• Kritisches CSS inline einbetten und den Rest ohne Blockade laden. Wer Stylesheets per media-Attribut aufteilt, blockiert nur auf die, die zum Gerät passen.
• defer oder async für Skripte, die fürs erste Zeichnen nicht nötig sind.
• Bessere Reihenfolge. Spät entdeckte Dateien wie ein CSS-Hintergrundbild oder eine Schrift per Hint früh starten lassen.

Häufige Fehler

• Das gesamte CSS inline einbetten. Das macht jede Seite schwerer und nimmt dem Stylesheet das Caching; nur das einbetten, was der erste Bildschirm braucht.
• async bei Skripten, die voneinander abhängen. Die Reihenfolge ist nicht garantiert, dort passt defer.
• Ein Skript verzögern, das sichtbare Inhalte aufbaut. Es kann eine leere Fläche hinterlassen oder das Layout später springen lassen.
• CSS-Selektoren auf Geschwindigkeit trimmen. Laut MDN liegt der Gewinn nur im Mikrosekundenbereich; die Zeit ist bei blockierenden Dateien besser angelegt.
• Nur auf einer schnellen Desktop-Verbindung prüfen. Auf einem langsamen Smartphone kostet jede blockierende Anfrage mehr.

Bezug zu Tests und Monitoring

Lab-Audits listen die renderblockierenden Anfragen einer Seite auf, und das Wasserfalldiagramm zeigt, worauf das erste Zeichnen gewartet hat. Um das über die Zeit zu verfolgen, führt LoadFocus Page Speed Monitoring Google-Lighthouse-Audits nach Zeitplan aus, von stündlich bis wöchentlich, aus 25 Cloud-Regionen, mit Benachrichtigungen per E-Mail, Slack oder Microsoft Teams. Der kostenlose Core Web Vitals Checker zeigt LCP, INP und CLS echter Nutzer aus den CrUX-Daten von Google, sodass Sie sehen, ob eine Korrektur bei echten Besuchern angekommen ist. Weitere Frontend-Maßnahmen stehen in der 10-Schritte-Anleitung für schnellere Websites. Die genauen Definitionen finden Sie im MDN-Leitfaden zum Critical Rendering Path.

Häufige Fragen: kritischer Rendering-Pfad

Welche Schritte hat der kritische Rendering-Pfad?

Aus dem HTML das DOM bauen, aus dem CSS das CSSOM bauen, beides zu einem Render-Baum aus sichtbaren Inhalten verbinden, das Layout berechnen und die Pixel zeichnen.

Blockiert JavaScript das Rendering?

Ein klassisches Skript ohne async, defer oder type module blockiert das Parsen des HTML, solange es geladen und ausgeführt wird, und Lighthouse meldet ein solches Skript im Head als renderblockierend. Mit defer oder async entfällt die Blockade.

Warum blockiert CSS das Rendering?

Spätere CSS-Regeln können frühere überschreiben. Der Browser wartet deshalb, bis das CSSOM vollständig ist, bevor er etwas zeichnet.

Was ist kritisches CSS?

Das ist die kleine Menge an Regeln, die zum Zeichnen des ersten Bildschirms nötig ist. Sie steht inline im Head, das übrige CSS wird geladen, ohne das erste Zeichnen zu blockieren.

Wie messe ich den kritischen Rendering-Pfad?

Ein Lighthouse-Audit zeigt die renderblockierenden Anfragen, ein Netzwerk-Wasserfall zeigt, worauf das erste Zeichnen gewartet hat. Wiederholen Sie die Messung aus mehreren Regionen und mit gedrosselter Verbindung.