Lighthouse-Warnung 'Eliminate render-blocking resources' beheben
Beseitigen Sie render-blockierende Ressourcen und verbessern Sie die Core Web Vitals
'Eliminate render-blocking resources' in Kürze
Wenn ein Browser im <head> auf render-blockierendes CSS oder JavaScript stößt, stoppt er alles. Es werden keine Pixel gerendert, bis diese Ressourcen vollständig heruntergeladen und ausgeführt wurden. Genau das sagt Ihnen die Lighthouse-Warnung 'Eliminate render-blocking resources': Etwas in Ihrem <head> verzögert den ersten Paint.
Beheben Sie diese Lighthouse-Warnung, indem Sie diese render-blockierenden Ressourcen entfernen oder zurückstellen (defer). Laut dem 2025 Web Almanac bestehen nur 15 % der mobilen Seiten dieses Audit. Das bedeutet, dass 85 % des Webs unnötige Rendering-Verzögerungen aufweisen.
Was ist die Lighthouse-Warnung 'Eliminate render-blocking resources'?
Zuletzt überprüft von Arjen Karel im März 2026
Was verursacht die Warnung Eliminate render-blocking resources in Lighthouse? Lighthouse markiert Seiten, die eines der folgenden Elemente aufweisen:
- Ein Script-Tag im Head, das nicht zurückgestellt wird.
Skripte im Head der Seite sind standardmäßig render-blockierend, wenn sie nicht über das Attribut defer oder async verfügen. - Ein verlinktes Stylesheet, das mit den Gerätemedien übereinstimmt.
Ein <link rel="stylesheet"> blockiert das Rendering der Seite, wenn es nicht deaktiviert ist und mit den Medien des Browsers übereinstimmt. Zum Beispiel blockiert <link rel="stylesheet" media="print"> das Rendering auf Bildschirmgeräten nicht.
Zu viele render-blockierende Ressourcen wirken sich höchstwahrscheinlich direkt auf den First Contentful Paint (FCP) und den Largest Contentful Paint (LCP) aus. Vodafone reduzierte render-blockierendes JavaScript und verzeichnete eine LCP-Verbesserung von 31 %, was zu einer Umsatzsteigerung von 8 % führte.
Laut dem Web Performance Calendar laden 67,7 % der Websites mindestens einen render-blockierenden Drittanbieter. Allein Google Fonts ist für render-blockierende Anfragen auf über 5,8 Millionen Websites verantwortlich.
Was verursacht 'render-blocking resources'?
Render-blockierende Ressourcen sind immer Stylesheets und JavaScripts im Head der Seite. Das bedeutet, dass sie nur durch Ihr CMS, Ihren Webentwickler oder durch ein Plugin hinzugefügt werden können. Wenn Sie versuchen, den Ursprung einer render-blockierenden Ressource zu finden, suchen Sie an diesen Stellen:
- Das Template. Das Template Ihrer Website ist die erste Anlaufstelle. Finden Sie die Stelle, an der sich der <head>-Code befindet, und suchen Sie nach hartcodierten Styles und Skripten.
- Das CMS. Manchmal benötigt das CMS selbst bestimmte Skripte (zum Beispiel jQuery), um ordnungsgemäß zu funktionieren.
- Plugins. Plugins sind berüchtigt dafür, Styles und Skripte in die Seite einzuschleusen. Selbst wenn ein Plugin nur auf einer Seite verwendet wird, lädt es seine Ressourcen oft auf jeder Seite.
Das JavaScript-Kapitel des Web Almanac 2024 (die aktuellste Ausgabe mit Daten auf Skriptebene) ergab, dass zwar 87 % der Seiten async bei mindestens einem Skript verwenden, aber nur 49 % der einzelnen Script-Tags dieses Attribut tatsächlich aufweisen. Und nur 13 % der Skripte verwenden defer. Die meisten Skripte im Web werden immer noch ohne eines dieser Attribute geladen, was bedeutet, dass sie das Rendering blockieren.
So beheben Sie 'Eliminate render-blocking resources'
Um render-blockierende Ressourcen zu beheben, müssen Sie sicherstellen, dass sie das Rendering nicht mehr blockieren. Die beste Lösung besteht darin, die Ressource vollständig zu entfernen. Alte, ungenutzte Skripte und Stylesheets, die sich noch im <head> befinden, sind häufiger, als Sie denken. Wenn Sie sie nicht entfernen können, stellen Sie sie zurück (defer).
JavaScript zurückstellen (defer)
JavaScript kann zurückgestellt werden, indem dem Script-Tag das Attribut defer oder async hinzugefügt wird.
<!-- deferred: lädt parallel herunter, wird nach dem HTML-Parsing der Reihe nach ausgeführt --> <script defer src="script.js"></script> <!-- async: lädt parallel herunter, wird sofort ausgeführt, sobald es bereit ist (beliebige Reihenfolge) --> <script async src="script.js"></script>
Für die meisten Skripte ist defer die sicherere Wahl, da die Ausführungsreihenfolge beibehalten wird. Verwenden Sie async für Skripte, die völlig unabhängig sind, wie z.B. Analytics. Wenn Sie ES-Module (<script type="module">) verwenden, erhalten Sie das Defer-Verhalten automatisch. Modul-Skripte blockieren niemals das Rendering.
Einen vollständigen Leitfaden zu allen Möglichkeiten der Steuerung des JavaScript-Timings finden Sie unter 16 Methoden zum Zurückstellen von JavaScript. Wenn Sie verstehen möchten, wie sich async und defer unterschiedlich auf die Core Web Vitals auswirken, haben wir auch dazu einen eigenen Artikel.
Stylesheets zurückstellen (defer)
Das Zurückstellen von Stylesheets ist kniffliger als das Zurückstellen von Skripten. Wenn ein Stylesheet zurückgestellt wird, wird die Seite zunächst ohne diese Styles gerendert, dann wendet der Browser sie an, sobald sie geladen sind. Dies verursacht Flackern und Layout Shifts. Aus diesem Grund müssen Sie zurückgestellte Stylesheets mit Inline Critical CSS kombinieren.
Schritt 1: Inlinen Sie Ihr Critical CSS. Critical CSS ist der minimale Satz an Styles, der benötigt wird, um den sichtbaren Teil der Seite zu rendern. Inlinen Sie es direkt in ein <style>-Tag im <head>. Dadurch erhält der Browser alles, was er benötigt, um den "Above-the-fold"-Inhalt zu rendern, ohne auf eine externe Datei warten zu müssen. Das manuelle Extrahieren von Critical CSS ist mühsam. Sie können unseren Critical CSS Generator verwenden, um dies zu automatisieren.
<style>/* Critical CSS hier */</style>
Schritt 2: Laden Sie den Rest mit niedriger Priorität. Fügen Sie für das nicht-kritische Stylesheet fetchpriority="low" hinzu, um dem Browser mitzuteilen, dass diese Ressource nicht mit kritischen Inhalten konkurrieren soll:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
In älteren Artikeln wird möglicherweise ein media="print"-Hack empfohlen, der beim Laden zu media="all" wechselt. Ich empfehle das nicht. Es missbraucht das media-Attribut für etwas, wofür es nicht entwickelt wurde, es hängt von einem anfälligen onload-Handler ab, und wenn dieser Handler fehlschlägt, werden Ihre Styles niemals angewendet. Die Verwendung von fetchpriority="low" ist der korrekte, semantische Ansatz: Es teilt dem Browser ohne Tricks genau mit, was Sie meinen.
Für Stylesheets, die Sie auf der aktuellen Seite überhaupt nicht benötigen (zum Beispiel Styles, die nur auf einem bestimmten Seitentyp verwendet werden), ist die sauberste Lösung, das ungenutzte CSS von dieser Seite vollständig zu entfernen.
Reduzieren Sie die Auswirkungen render-blockierender Ressourcen
Manchmal können Sie render-blockierende Ressourcen nicht eliminieren. Möglicherweise haben Sie keinen Zugriff auf das Template oder Ihr CMS benötigt bestimmte Skripte. Es gibt einige Möglichkeiten, die Auswirkungen zu reduzieren:
- Minifizieren und komprimieren Sie Ihre Styles und Skripte.
Kleinere Ressourcen wirken sich weniger stark auf die Ladeleistung aus als größere Ressourcen. Stellen Sie sicher, dass die Gzip- oder Brotli-Komprimierung auf Ihrem Server aktiviert ist. - Vermeiden Sie das Verketten kritischer Anfragen.
Wenn ein render-blockierendes Stylesheet ein weiteres Stylesheet über@importlädt, haben Sie eine Request Chain (Anfragekette) erstellt. Die zweite Datei kann erst heruntergeladen werden, wenn die erste vollständig geladen und geparst wurde. Verwenden Sie stattdessen separate<link>-Tags, damit beide parallel heruntergeladen werden. - Entladen Sie Ressourcen pro Seite.
Wenn eine Ressource nicht von einer Seite entfernt werden kann, bedeutet das nicht, dass sie auf allen Seiten erforderlich ist. WordPress-Plugins neigen dazu, allen Seiten Skripte und Styles hinzuzufügen, selbst wenn das Plugin nur auf einigen wenigen aktiv ist. - Priorisieren Sie das Wichtige.
Verwenden Sie Ressourcenpriorisierung, um sicherzustellen, dass kritische Ressourcen zuerst geladen werden und nicht-kritische Ressourcen nicht um Bandbreite konkurrieren.
In den Monitoring-Daten von CoreDash verbesserte sich der FCP bei Websites, die alle render-blockierenden Ressourcen eliminierten, im Durchschnitt um 420 ms.
CoreDash has MCP built in.
Connect it to Claude or any AI agent. Ask it why your INP spiked last Tuesday.
See how it works
