Was sind render-blockierende Ressourcen?
Warum bleibt eine Seite manchmal eine Sekunde lang weiß, obwohl das HTML schon da ist? Weil der Browser auf render-blockierende Ressourcen wartet. Das sind Dateien, ohne die er nicht mit dem Zeichnen anfängt.
Der Hauptgrund ist CSS. Laut Google zeichnet der Browser erst, wenn er sowohl die Struktur der Seite als auch alle Stilregeln kennt. Sonst würde die Seite ungestylt aufblitzen und dann umspringen. Dazu kommen Skripte im Kopf der Seite, die der Browser sofort ausführen muss.
Lighthouse markiert genau zwei Fälle als blockierend:
- Skripte im Kopfbereich (head) ohne defer oder async
- Stylesheets, die für alle Geräte gelten, also ohne ein media-Attribut, das gezielt auf etwas anderes zeigt
Warum das für SEO zählt
Render-blockierende Ressourcen verzögern den First Contentful Paint (FCP), also den Moment, in dem überhaupt etwas erscheint. Laut Chrome kann das auch den Largest Contentful Paint (LCP) verschieben, und der ist ein Core Web Vital.
Das Problem ist weit verbreitet. Im Web Almanac 2025 von HTTP Archive bestanden nur wenige Seiten den Lighthouse-Test zu diesem Punkt:
Gerät
Test bestanden
Mobil
15 %
Desktop
13 %
Einen guten FCP unter 1,8 Sekunden hatten 2025 nur 55 % der Mobilseiten und 70 % der Desktopseiten. Einen guten LCP schafften mobil 62 %.
Zwei Beispiele aus der Praxis
Case A · Telekommunikation
Vodafone im A/B-Test
8,3 s → 5,7 s
LCP, Felddaten
+8 %
Umsatz
LCP 31 % besser, Lead-Rate +15 %
Unter anderem weniger render-blockierendes JavaScript, dazu serverseitiges Rendern und Bildoptimierung. Ein Bündel, kein Einzeleffekt.
Case B · Nachrichtenseite
The Economic Times
4,5 s → 2,5 s
LCP, 75. Perzentil
−43 %
Absprungrate
Im Kopf nur noch, was für den ersten Bildschirm nötig ist
Nicht nötige Aufrufe verzögert, Drittanbieter-Skripte nach hinten, Schriften mit font-display: swap. Ebenfalls ein Maßnahmenbündel.
So entschärfst du sie
- Kritisches CSS inline: Die Stile für den ersten Bildschirm direkt ins HTML, den Rest nachladen. In einem Lehrbeispiel von Google sank der FCP so von 1 auf 0,8 Sekunden.
- Skripte mit defer: Laden parallel, laufen nach dem Einlesen der Seite, in fester Reihenfolge.
- Oder mit async: Laufen sofort nach dem Laden, aber ohne feste Reihenfolge. Für unabhängige Skripte wie Analytics.
- media-Attribut: Ein Druck-Stylesheet mit media="print" blockiert nicht.
- Schriften: Mit font-display: swap zeigt der Browser erst eine Ersatzschrift. Laut Web Almanac 2025 nutzt das etwa jede zweite Seite.
- Ausmisten: Ungenutztes CSS und JavaScript entfernen.
In WordPress
Hier übernehmen meist Plugins die Arbeit. WP Rocket erzeugt mit „Remove Unused CSS“ für jede Seite nur das benötigte CSS, und „Delay JavaScript Execution“ lädt Skripte erst bei der ersten Interaktion. Perfmatters bietet Ähnliches, Autoptimize kann kritisches CSS inline setzen. Nimm für ungenutztes CSS nur ein Plugin, sonst kommen sie sich in die Quere.
Häufige Fehler
Fehler 1 · Alles inline packen
Wer das ganze CSS ins HTML schreibt, macht jede Seite schwerer und verliert den Browser-Cache. Google selbst schreibt, dass die meisten Seiten die Zielwerte auch ohne kritisches CSS erreichen. Fang mit den einfachen Hebeln an.
Fehler 2 · async und defer verwechseln
Mit async gibt es keine feste Reihenfolge. Hängt ein Skript von einem anderen ab, etwa von jQuery, kann es dann vor diesem laufen und abbrechen.
Fehler 3 · Nach dem Hinweis statt nach den Messwerten optimieren
Aggressive Einstellungen wie „Delay JS“ verbessern Laborwerte, können aber Slider, Menüs oder das Cookie-Banner brechen. Prüf nach jeder Änderung die Seite als Besucher, nicht nur den Score.
Fehler 4 · Den CSS-Cache vergessen
Wer bei WP Rocket oder Perfmatters das Design ändert, muss das erzeugte CSS neu bauen lassen. Sonst sieht die Seite für Besucher aus wie vorher.
Was du daraus mitnimmst
Häufige Fragen
Was sind render-blockierende Ressourcen?
Dateien, vor allem CSS und Skripte im Kopf einer Seite, die der Browser erst laden und verarbeiten muss, bevor er etwas anzeigt. Solange sie fehlen, bleibt der Bildschirm leer.
Senkt der Hinweis in PageSpeed Insights direkt meinen Score?
Nein. Der Score hängt an den Messwerten wie FCP und LCP. Render-blockierende Ressourcen verschlechtern diese Werte aber oft, deshalb lohnt sich das Beheben trotzdem.
Was ist der Unterschied zwischen async und defer?
Beide laden das Skript, ohne das Einlesen der Seite anzuhalten. Mit defer läuft es danach in der Reihenfolge, in der es im Code steht. Mit async läuft es, sobald es da ist, ohne feste Reihenfolge.
Blockieren Webfonts das Rendern?
Nicht direkt, aber sie können den Text verzögern. Laut Google halten Chrome und Firefox Text bis zu drei Sekunden zurück, wenn die Schrift fehlt. Mit font-display: swap erscheint sofort eine Ersatzschrift.
Was ist der Unterschied zum Main Thread?
Render-blockierende Ressourcen verzögern das erste Bild. Ein überlasteter Main Thread bremst die Seite danach, wenn jemand klickt. Ein großes Skript kann beides verursachen, die Lösungen unterscheiden sich aber.
Quellen
- web.dev: Render blocking CSS
- Chrome for Developers: Eliminate render-blocking resources
- Chrome for Developers: Render-blocking requests
- Chrome for Developers: Lighthouse 13
- HTTP Archive: Web Almanac 2025, Performance
- HTTP Archive: Web Almanac 2025, Fonts
- web.dev: Defer non-critical CSS
- MDN: Das script-Element
- web.dev: Vodafone-Fallstudie
- web.dev: The Economic Times und Core Web Vitals
