Render-Blocking Resources
Was sind Render-Blocking Resources?
Render-Blocking Resources sind CSS- oder JavaScript-Dateien, die ein Browser erst laden, analysieren oder ausführen muss, bevor er sichtbare Seiteninhalte darstellen kann. Sie verlängern den kritischen Rendering-Pfad und können dadurch den First Contentful Paint und Largest Contentful Paint verzögern, obwohl der eigentliche HTML-Inhalt bereits übertragen wurde.
Wie Render-Blocking Resources entstehen
Render-Blocking Resources, auf Deutsch einmalig als renderblockierende Ressourcen bezeichnet, entstehen während des Seitenaufbaus im Browser. Der Browser liest das HTML-Dokument von oben nach unten, erstellt daraus das Document Object Model und lädt referenzierte Dateien. Trifft er auf ein relevantes Stylesheet oder ein synchron ausgeführtes Skript, kann die sichtbare Darstellung warten müssen.
CSS blockiert das Rendering, weil der Browser vor der Darstellung wissen muss, welche Farben, Abstände, Schriftgrößen und Positionen gelten. Dafür baut er aus den CSS-Regeln das CSS Object Model auf. Erst die Verbindung aus Document Object Model und CSS Object Model liefert den Render Tree, aus dem der Browser die sichtbaren Elemente berechnet.
Klassisches JavaScript ohne passende Ladeattribute kann zusätzlich den HTML-Parser anhalten. Der Browser lädt und verarbeitet das Skript, bevor er das nachfolgende HTML weiterliest. Greift das Skript auf CSS-Regeln zu, kann auch die Verarbeitung des JavaScripts auf ein noch nicht vollständig geladenes Stylesheet warten.
Welche Dateien das Rendering blockieren
Nicht jede CSS- oder JavaScript-Datei ist automatisch eine Render-Blocking Resource. Maßgeblich sind die Einbindungsart, die Position im Dokument und die Frage, ob die Ressource für den sichtbaren Bereich benötigt wird. Ein Stylesheet mit einer passenden media-Bedingung kann beispielsweise nur unter bestimmten Bildschirmbedingungen blockieren.
Render-Blocking Resources beseitigen
Die richtige Lösung besteht nicht darin, sämtliche CSS- und JavaScript-Dateien zu entfernen. Der Browser benötigt einen Teil des Codes für den sichtbaren Seitenkopf. Ziel ist es, nur das unmittelbar erforderliche CSS früh bereitzustellen und alle übrigen Ressourcen so zu laden, dass sie den ersten Seitenaufbau möglichst wenig verzögern.
Critical CSS gezielt einbinden
Critical CSS enthält ausschließlich die Styles, die für den direkt sichtbaren Bereich einer URL benötigt werden. Dieser kleine CSS-Teil kann in das HTML-Dokument eingebunden werden. Umfangreiche Styles für Footer, Tabs, Pop-ups oder weiter unten liegende Inhalte werden anschließend geladen. Critical CSS muss URL- und Template-spezifisch geprüft werden, weil eine Shop-Kategorie andere sichtbare Elemente besitzt als ein Blogartikel.
JavaScript mit defer laden
Das Attribut defer erlaubt dem Browser, ein externes Skript parallel zum HTML zu laden. Die Ausführung beginnt erst, nachdem das HTML vollständig analysiert wurde. Die Reihenfolge mehrerer mit defer eingebundener Skripte bleibt grundsätzlich erhalten. Diese Methode eignet sich daher für voneinander abhängige Dateien, die nicht für den ersten Seitenaufbau benötigt werden.
JavaScript mit async laden
Das Attribut async lädt JavaScript ebenfalls parallel, führt die Datei jedoch aus, sobald sie verfügbar ist. Mehrere asynchrone Skripte können deshalb in einer anderen Reihenfolge starten als im HTML angegeben. async eignet sich vor allem für unabhängige Funktionen. Bei Skripten mit Abhängigkeiten kann die nicht festgelegte Reihenfolge Fehler auslösen.
Dateien verkleinern und priorisieren
Minifizierung entfernt Kommentare, Leerzeichen und andere für die Ausführung unnötige Zeichen aus CSS und JavaScript. Das verkürzt die Übertragung, beseitigt aber allein keine Render-Blocking Resources. Eine weiterhin synchron eingebundene, minifizierte Datei kann den Rendering-Pfad noch immer blockieren. Prüfe deshalb zuerst die Ladepriorität und anschließend die Dateigröße.
PageSpeed und Core Web Vitals
Der Hinweis auf Render-Blocking Resources gehört zur technischen PageSpeed-Analyse. Blockierende Dateien können den First Contentful Paint verzögern, also den Zeitpunkt des ersten dargestellten Inhalts. Liegt das größte sichtbare Seitenelement im betroffenen Bereich, kann sich auch der Largest Contentful Paint verschlechtern.
Der Unterschied zwischen Render-Blocking Resources und einer großen Seitengröße liegt in der Ursache: Eine umfangreiche Bilddatei erhöht die zu übertragende Datenmenge, während eine kleine CSS-Datei den sichtbaren Aufbau durch ihre Position und Einbindung verzögern kann. Priorisiere deshalb nicht automatisch die größte Datei, sondern die Ressource mit dem stärksten Einfluss auf den kritischen Rendering-Pfad.
Render-Blocking Resources sind zudem nur ein Teil der Ladezeit. Langsame Serverantworten, unkomprimierte Bilder, fehlendes Caching, Weiterleitungsketten und umfangreiche JavaScript-Ausführung können unabhängig davon hohe Werte verursachen. Eine dauerhaft unter einer Sekunde liegende Ladezeit bietet eine gute Orientierung, muss aber immer getrennt für Mobilgeräte, Desktop-Rechner und verschiedene URL-Typen betrachtet werden.
Render-Blocking Resources messen
Messbar ist das zum Beispiel so: Ein Ladezeiten-Check für Desktop und Mobilgeräte zeigt den PageSpeed-Status und technische Optimierungshinweise. Prüfe mindestens Startseite, zentrale Landingpages, Kategorien und Produktseiten, weil jedes Template andere CSS- und JavaScript-Abhängigkeiten besitzen kann.
Führe den Test vor und nach einer Änderung unter vergleichbaren Bedingungen aus. Dokumentiere, welche Datei angepasst wurde, und vergleiche anschließend den sichtbaren Seitenaufbau sowie die betroffenen Messwerte. Der Technik-Crawler der Performance Suite unterstützt dabei, technische Prüfungen und Ladezeitentwicklungen regelmäßig zu überwachen.
Prüfe deine URL direkt auf PageSpeed-Potenziale und blockierende Elemente:
Relevanz für SEO, SEA und GEO
Render-Blocking Resources betreffen SEO, weil sie die Nutzererfahrung und Core Web Vitals beeinflussen können. Die Optimierung ersetzt keine relevanten Inhalte, saubere Indexierung oder interne Verlinkung. Sie stellt sicher, dass vorhandene Inhalte ohne vermeidbare Verzögerung dargestellt werden. Weitere Zusammenhänge behandelt der Leitfaden zu den wichtigsten Maßnahmen der technischen SEO.
Bei SEA beeinflusst die Ladegeschwindigkeit die Erfahrung nach dem Anzeigenklick. Eine Landingpage sollte deshalb nicht nur nach ihrer vollständigen Ladezeit bewertet werden. Relevant ist auch, wann Überschrift, Angebot und Handlungsoption sichtbar und bedienbar werden. Der technische Check muss genau die Zielseiten umfassen, auf die aktive Anzeigen führen.
Für GEO, also Generative Engine Optimization, sind stabile und effizient renderbare Seiten hilfreich, weil Such- und KI-Systeme Inhalte zuverlässig abrufen und verarbeiten müssen. Render-Blocking Resources verhindern das Crawling von HTML nicht grundsätzlich. Umfangreiche clientseitige Abhängigkeiten können die Extraktion relevanter Inhalte jedoch erschweren, wenn zentrale Informationen erst nach komplexen Skriptabläufen erscheinen.
Häufige Fragen zu Render-Blocking Resources
Wie kann ich Render-Blocking Resources erkennen?
Ein Ladezeiten-Test weist CSS- und JavaScript-Dateien aus, die vor der ersten Darstellung verarbeitet werden. Prüfe dabei mehrere Seitentypen und die mobile sowie die Desktop-Version, weil die geladenen Ressourcen und ihre Prioritäten voneinander abweichen können.
Wie kann ich Render-Blocking Resources entfernen?
Binde Critical CSS für den sichtbaren Bereich direkt ein und lade übrige Styles später. JavaScript kann abhängig von seiner Funktion mit 'defer' oder 'async' eingebunden werden. Entferne Dateien nur, wenn vorher geprüft wurde, dass keine Seitenfunktion davon abhängt.
Was ist der Unterschied zwischen defer und async?
'defer' führt Skripte nach dem Einlesen des HTML-Dokuments in ihrer vorgesehenen Reihenfolge aus. 'async' führt ein Skript aus, sobald es geladen wurde. Dadurch eignet sich 'async' vor allem für unabhängige Dateien ohne feste Ausführungsreihenfolge.
Sind alle CSS-Dateien renderblockierend?
CSS-Dateien können das Rendering blockieren, wenn ihre Regeln für das aktuelle Ausgabemedium gelten und vor der Darstellung benötigt werden. Stylesheets mit nicht zutreffenden Media-Bedingungen oder später geladene Styles müssen den ersten sichtbaren Aufbau nicht zwingend verzögern.
Verbessert Minifizierung Render-Blocking Resources?
Minifizierung verkleinert CSS und JavaScript, ändert aber nicht automatisch deren Ladeverhalten. Eine kleine, synchron eingebundene Datei kann weiterhin blockieren. Prüfe deshalb sowohl die Dateigröße als auch Position, Abhängigkeiten und Einbindungsart.
Wie oft sollte ich die Ladezeit meiner Website prüfen?
Prüfe die Ladezeit regelmäßig sowie nach Änderungen an Themes, Plug-ins, Tracking, Consent-Systemen und externen Diensten. Besonders relevant sind Startseiten, Landingpages, Kategorien, Produktseiten und andere Templates mit eigenem CSS- oder JavaScript-Code.
Sie haben noch Fragen?
