Lighthouse-Warnung 'Eliminate render-blocking resources' beheben
Beseitigen Sie render-blockierende Ressourcen und verbessern Sie die Core Web Vitals
'Eliminate render-blocking resources' kurz gesagt
Wenn ein Browser im <head> auf render-blockierendes CSS oder JavaScript stößt, stoppt er alles. Es werden keine Pixel gemalt, bis diese Ressourcen vollständig heruntergeladen und ausgeführt sind. Das ist es, was Ihnen die Warnung 'Eliminate render-blocking resources' in Lighthouse sagt: Etwas in Ihrem <head> verzögert den ersten Paint (First Paint).
Beheben Sie diese Lighthouse-Warnung, indem Sie diese render-blockierenden Ressourcen entfernen oder verzögern. Laut dem Web Almanac 2025 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 entweder Folgendes aufweisen:
- Ein Script-Tag im Head, das nicht verzögert (deferred) wird.
Skripte im Head der Seite sind standardmäßig render-blockierend, wenn sie nicht das defer- oder async-Attribut haben. - Ein verlinktes Stylesheet, das mit den Gerätemedien (device media) ü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 Verbesserung des LCP um 31 %, was sich in einer Umsatzsteigerung von 8 % niederschlug.
Laut dem Web Performance Calendar laden 67,7 % der Websites mindestens einen render-blockierenden Drittanbieter (Third Party). 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 von Ihrem CMS, Ihrem 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 der erste Ort, an dem Sie suchen sollten. Finden Sie die Stelle, an der sich der <head>-Code befindet, und suchen Sie nach hardcodierten Stilen und Skripten.
- Das CMS. Manchmal benötigt das CMS selbst einige Skripte (zum Beispiel jQuery), um richtig zu funktionieren.
- Plugins. Plugins sind dafür berüchtigt, Stile und Skripte in die Seite zu injizieren. Selbst wenn ein Plugin nur auf einer Seite verwendet wird, lädt es oft seine Ressourcen auf jeder Seite.
Das JavaScript-Kapitel des Web Almanac 2024 (die neueste Ausgabe mit Daten auf Skriptebene) ergab, dass zwar 87 % der Seiten async für mindestens ein Skript verwenden, aber nur 49 % der einzelnen Script-Tags es tatsächlich haben. Und nur 13 % der Skripte verwenden defer. Die meisten Skripte im Web werden immer noch ohne eines der beiden Attribute geladen, was bedeutet, dass sie das Rendering blockieren.
Wie man 'Eliminate render-blocking resources' behebt
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, verzögern Sie sie (defer).
JavaScript verzögern
JavaScript kann durch Hinzufügen des defer- oder async-Attributs zum Script-Tag verzögert werden.
<!-- deferred: lädt parallel herunter, wird nach dem HTML-Parsing ausgeführt, in der richtigen Reihenfolge --> <script defer src="script.js"></script> <!-- async: lädt parallel herunter, wird sofort ausgeführt, wenn es bereit ist (in beliebiger 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 Analytics. Wenn Sie ES-Module (<script type="module">) verwenden, erhalten Sie das Defer-Verhalten automatisch. Modul-Skripte blockieren das Rendering nie.
Einen vollständigen Leitfaden zu allen Möglichkeiten der Steuerung des JavaScript-Timings finden Sie unter 16 Methoden zum Verzögern von JavaScript. Wenn Sie verstehen möchten, wie async und defer die Core Web Vitals unterschiedlich beeinflussen, haben wir auch dazu einen eigenen Artikel.
Stylesheets verzögern
Stylesheets zu verzögern ist kniffliger als Skripte zu verzögern. Wenn ein Stylesheet verzögert wird, wird die Seite zunächst ohne diese Stile gerendert, dann wendet der Browser sie an, sobald sie geladen sind. Dies verursacht Flackern und Layoutverschiebungen (Layout Shifts). Deshalb müssen Sie verzögerte Stylesheets mit Inline-Critical-CSS kombinieren.
Schritt 1: Inlinen Sie Ihr Critical CSS. Critical CSS ist der minimale Satz an Stilen, der benötigt wird, um den sichtbaren Teil der Seite zu rendern. Inlinen Sie ihn direkt in einem <style>-Tag im <head>. Dies gibt dem Browser alles, was er braucht, um den Above-the-fold-Inhalt zu malen, ohne auf eine externe Datei warten zu müssen. Das Extrahieren von Critical CSS von Hand 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">
Möglicherweise finden Sie ältere Artikel, die einen media="print"-Hack empfehlen, der beim Laden auf media="all" umschaltet. Ich empfehle dies nicht. Es missbraucht das media-Attribut für etwas, wofür es nicht gedacht war, es hängt von einem fragilen onload-Handler ab, und wenn dieser Handler fehlschlägt, werden Ihre Stile nie angewendet. Die Verwendung von fetchpriority="low" ist der richtige, semantische Ansatz: Es sagt dem Browser genau, was Sie meinen, ohne Tricks.
Für Stylesheets, die Sie auf der aktuellen Seite überhaupt nicht benötigen (zum Beispiel Stile, die nur auf einem bestimmten Seitentyp verwendet werden), ist die sauberste Lösung, das ungenutzte CSS vollständig von dieser Seite zu entfernen.
Die Auswirkungen von render-blockierenden Ressourcen reduzieren
Manchmal können Sie render-blockierende Ressourcen nicht eliminieren. Sie haben möglicherweise 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 Stile und Skripte.
Kleinere Ressourcen haben geringere Auswirkungen auf die Ladeleistung als größere Ressourcen. Stellen Sie sicher, dass gzip- oder brotli-Komprimierung auf Ihrem Server aktiviert ist. - Vermeiden Sie das Verketten kritischer Anforderungen (chaining critical requests).
Wenn ein render-blockierendes Stylesheet ein anderes Stylesheet über@importlädt, haben Sie eine Anforderungskette (request chain) erstellt. Die zweite Datei kann nicht heruntergeladen werden, bis die erste vollständig geladen und geparst ist. 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, Skripte und Stile auf allen Seiten hinzuzufügen, selbst wenn das Plugin nur auf einigen wenigen aktiv ist. - Priorisieren Sie, was wichtig ist.
Verwenden Sie die Ressourcenpriorisierung (resource prioritization), um sicherzustellen, dass kritische Ressourcen zuerst geladen werden und nicht-kritische Ressourcen nicht um Bandbreite konkurrieren.
In den Monitoring-Daten von CoreDash verzeichneten Websites, die alle render-blockierenden Ressourcen eliminierten, eine durchschnittliche Verbesserung ihres FCP um [CD:placeholder] ms.
Ask AI why your INP spiked.
CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.
See How It Works
