Sprachen

Kritisches CSS

Critical CSS – Styles oberhalb des Folds extrahieren, inline einfügen und den Rest zurückstellen, um den ersten Paint zu beschleunigen. Warum Google die Technik als fortgeschritten und optional einstuft, welche Nachteile tatsächlich entstehen und wie du feststellst, ob CSS überhaupt dein Engpass ist.

Erstveröffentlicht: 3. Juli 2026 · Zuletzt aktualisiert: 22. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Critical CSS ist eine Performance-Technik: Extrahiere das CSS, das für einen ausgewählten View oberhalb des Folds benötigt wird, füge es in den Head ein und stelle den Rest des Stylesheets asynchron zurück. CSS ist standardmäßig renderblockierend, daher kann diese Aufteilung den ersten Paint beschleunigen. Eine universelle Höhe oberhalb des Folds gibt es nicht – Gerät, Ausrichtung, Zoom und Seitenzustand verändern sie. Google betrachtet Critical CSS als fortgeschrittene, optionale Technik und sagt, dass die meisten Websites ihre Ziele ohne sie erreichen sollten. Die Nachteile sind real: Inline-CSS wird bei wiederholten Besuchen nicht gecacht, die kritische Trennung bricht bei Template- oder Zustandsänderungen, eine CSP-Richtlinie für style-src kann den Inline-Block vollständig blockieren und die Preload-/Onload-Zurückstellung kann Wettläufe oder Layout Shifts verursachen. Diagnostiziere zuerst, ob CSS – nicht JavaScript oder Server-Antwortzeit – dein Render-Engpass ist. Die SEO-Wirkung ist indirekt über Core Web Vitals/LCP, kein direkter Rankingfaktor; Bing-spezifische Anleitung gibt es nicht.

TL;DR — Critical CSS = Styles oberhalb des Folds extrahieren, inline in den <head> einfügen und den Rest des Stylesheets asynchron zurückstellen (rel="preload" plus onload-Tausch, <noscript>-Fallback oder loadCSS). Es funktioniert, weil CSS standardmäßig das Rendern blockiert. Der Genauigkeitskern: Google beschreibt dies als fortgeschritten und optional, nicht als Standardempfehlung – „Die meisten Websites sollten alle unsere empfohlenen Performance-Ziele erreichen können, ohne diese Technik zu implementieren.“ Halte die inline eingefügte Datenmenge klein. Die Nachteile sind real: Inline-CSS wird über Seitenladevorgänge hinweg nicht gecacht (wiederholte Besuche können langsamer sein), die kritische/nicht kritische Trennung bricht bei Templateänderungen, und die Zurückstellung kann einen Wettlauf auslösen oder FOUC/CLS verursachen. Diagnostiziere zuerst – bestätige, dass CSS (nicht JavaScript oder Serverzeit) tatsächlich der Engpass ist. Achte auf die Fallstricke, die eine schnelle Demo nicht zeigt: Eine CSP-style-src-Richtlinie kann deinen inline eingefügten <style>-Block vollständig blockieren, „bei der Aufzeichnung ungenutzt“ bedeutet nicht „über Themes/Personalisierung/Zustände hinweg sicher zurückzustellen“, und Inline-CSS löst das Timing beim Laden von Schriften nicht. Der SEO-Effekt ist indirekt über Core Web Vitals/LCP. Es gibt keine Bing-spezifische Anleitung.

Was Critical CSS tatsächlich ist

Das Problem, das es löst, ist renderblockierendes CSS. Googles web.dev ist eindeutig: “By default, CSS is treated as a render-blocking resource, which means that the browser won’t render any processed content until the CSSOM is constructed.” (Übersetzung) „Standardmäßig wird CSS als renderblockierende Ressource behandelt; der Browser rendert also keine verarbeiteten Inhalte, bevor der CSSOM erstellt ist.“ Quelle. Das ist der ganze Grund für die Technik – der Browser weigert sich zu zeichnen, bis er deine Styles hat, daher verzögert alles, was CSS verzögert, auch den ersten Paint. (Die vollständige Pipeline darunter findest du im Critical Rendering Path-Hub, unter den dieser Artikel fällt, und in seinem Begleiter renderblockierende Ressourcen.)

Critical CSS greift das auf, indem es dein CSS in zwei Teile teilt. web.dev definiert es so: “Critical CSS is a technique that extracts the CSS for above-the-fold content in order to render content to the user as fast as possible.” (Übersetzung) „Critical CSS ist eine Technik, die das CSS für Inhalte oberhalb des Folds extrahiert, um Inhalte für den Nutzer so schnell wie möglich zu rendern.“ Und der Mechanismus: “Inlining extracted styles in the <head> of the HTML document eliminates the need to make an additional request to fetch these styles. The remainder of the CSS can be loaded asynchronously.” (Übersetzung) „Wer extrahierte Styles im <head> des HTML-Dokuments inline einfügt, benötigt keine zusätzliche Anfrage für diese Styles; das übrige CSS lässt sich asynchron laden.“ Zum Zitat springen

Evidence for this claim Critical CSS extracts and inlines above-the-fold styles so the remaining CSS can load asynchronously. Scope: web.dev definition and implementation outline for critical CSS. Confidence: high · Verified: web.dev: Extract critical CSS

Eine Sache stellt web.dev klar, die viele sekundäre Anleitungen beschönigen: Es gibt keine einzige, universelle Höhe oberhalb des Folds – Gerätegröße, Ausrichtung, Browser-Chrome, Zoomstufe und Seitenzustand (geöffnetes Menü, geladene Personalisierung, Fehlerzustand) verändern, was tatsächlich in die „kritische“ Menge gehört. Behandle Critical CSS als Entscheidung für einen ausgewählten anfänglichen Viewport/Zustand, nicht als feste Pixelgrenze, und validiere gegen deine echten Breakpoints und Zustände – nicht gegen einen einzigen Desktop-Screenshot.

Es sind also zwei Aufgaben, in dieser Reihenfolge:

  1. Inline: das minimale CSS oberhalb des Folds in den <head> einfügen – kein zusätzlicher Roundtrip vor dem ersten Paint.
  2. Zurückstellen: den Rest des Stylesheets asynchron laden, damit er diesen ersten Paint nie blockiert.

Genau so habe ich es in meinen Vorträgen zur Seitenerfahrung aufgeteilt. In meinem Deck Was als Nächstes für die Seitenerfahrung kommt (SMX Next 2021) teile ich die CSS-Arbeit in zwei Buckets: einen frühen/kritischen Pfad (ungenutztes CSS entfernen → CSS minifizieren → Critical CSS inline einfügen) und einen späten/zurückgestellten Pfad (nicht kritisches CSS zurückstellen). Dieselbe Form wie bei web.dev, nur in der Reihenfolge, in der ich darüber nachdenke.

So wird es implementiert

Schritt 1 – Critical CSS inline einfügen. Lighthouse selbst empfiehlt, die für den ersten Paint erforderlichen kritischen Styles innerhalb eines <style>-Blocks im Kopf der HTML-Seite inline einzufügen. Googles Zielgröße für diese Inline-Datenmenge lautet auf derselben Seite: Halte Inhalte oberhalb des Folds unter 14 KB (komprimiert), damit sie in den ersten Netzwerk-Roundtrip passen. Betrachte diese Zahl als historische Transportempfehlung, nicht als zeitlose Spezifikation – die Quellseite stammt aus dem Jahr 2019 und geht der heutigen breiten Verbreitung von HTTP/2 und HTTP/3 voraus, wodurch sich die Rechnung für den ersten Roundtrip verändert. Es ist weiterhin die von Googles eigener Dokumentation genannte Zahl; wenn du sehr genau optimierst, prüfe sie aber gegen dein aktuelles Protokoll und Serververhalten, statt 14 KB als Evangelium zu behandeln.

Schritt 2 – den Rest zurückstellen. Das von web.dev empfohlene Muster zum Zurückstellen nicht kritischen CSS ist ein Preload mit einem onload-Tausch plus <noscript>-Fallback:

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

web.dev empfiehlt für die Produktion, CSS-zurückstellende Funktionen wie loadCSS zu verwenden, die dieses Verhalten kapseln und browserübergreifend gut funktionieren, statt den Tausch selbst zu bauen. Wenn du stattdessen mit JavaScript zurückstellst, weist web.dev darauf hin, dass das Warten auf die Ausführung von JavaScript vor dem Laden nicht kritischen CSS zu Verzögerungen beim Rendern führen kann, wenn Nutzer scrollen – deshalb wird preload verwendet, um den Download früher zu starten.

Werkzeuge. Critical CSS wird selten von Hand extrahiert. Googles Referenzimplementierung ist das critical-npm-Paket (Addy Osmani) – „ein Tool, das CSS oberhalb des Folds extrahiert, minifiziert und inline einfügt.“ Alternativen sind Penthouse und CriticalCSS sowie zahlreiche SaaS-/Plugin-Generatoren für WordPress und Shopify. Um die kritischen Regeln selbst zu finden, verweist Google auf den Coverage-Tab in Chrome DevTools, um nicht kritisches CSS und JS zu identifizieren.

Wenn du ein Plugin oder einen Generator (WP Rocket, Autoptimize und ähnliche) verwendest, nimm den UI-Rundgang eines Anbieters oder einen Vorher-/Nachher-Screenshot der Punktzahl nicht als Plattformgarantie – diese Seiten vermischen Produktversionen und Ergebnisse bestimmter Websites ungeprüft, und die Punktedifferenzen werden nicht unabhängig reproduziert. Bevor du dem Tool in der Produktion vertraust: Bestätige das Verhalten anhand der aktuellen Dokumentation und Versionsnummer des Plugins und lege dieselbe Testmatrix an, die du für eine eigene Implementierung verwenden würdest – kalte und wiederholte Ladevorgänge, deine echten Breakpoints/Themes/Zustände und deine CSP-Richtlinie, falls du eine verwendest.

Beachte, dass Critical CSS nur eine der Lösungen für renderblockierendes CSS ist. Die anderen sind, Stylesheets mit dem media-Attribut einzugrenzen (damit sie heruntergeladen werden, aber den Paint nicht blockieren) und von vornherein weniger CSS auszuliefern – web.defs Artikel zu renderblockierendem CSS stützt sich tatsächlich eher auf den Media-Attribut-Ansatz als auf Inline-CSS. Google hat also mehr als eine offizielle Empfehlung, je nachdem, welches Dokument du liest.

Googles tatsächliche Position (der Genauigkeitskern)

Das ist der Teil, den fast jeder konkurrierende Artikel vergräbt, und der ganze Grund, warum ich diesen Artikel schreiben wollte. Google stellt Critical CSS nicht als Standardempfehlung dar. Sein Codelab formuliert das Risiko deutlich: “This codelab describes an advanced performance technique that can improve performance, but can also lead to bugs if not implemented properly.” (Übersetzung) „Dieses Codelab beschreibt eine fortgeschrittene Technik zur Performance-Verbesserung, die bei falscher Implementierung auch Fehler verursachen kann.“ Quelle. Und in zwei verschiedenen Dokumenten sagt Google, dass die meisten Websites sich nicht darum bemühen sollten: “Most sites should be able to achieve all of our recommended performance targets without implementing this technique.” (Übersetzung) „Die meisten Websites sollten alle unsere empfohlenen Performance-Ziele erreichen können, ohne diese Technik zu implementieren.“ Quelle.

Evidence for this claim web.dev presents critical CSS as an advanced technique that can cause bugs and says most sites can meet performance targets without it. Scope: web.dev codelab guidance; not a universal recommendation. Confidence: high · Verified: web.dev: Extract and inline critical CSS

Selbst der Vorteil kommt mit einer Warnung. web.dev weist darauf hin, dass Inline-CSS auch Nachteile hat, weil es den Browser daran hindert, das CSS für die Wiederverwendung bei späteren Seitenladevorgängen zu cachen; daher sollte man es sparsam einsetzen – und beim Übertreiben gilt: Wenn alles priorisiert wird, ist nichts priorisiert. Füge zu viel inline ein, blähst du das HTML auf, das du schnell ausliefern willst.

Die ehrliche Einordnung lautet also: Critical CSS ist eine echte, dokumentierte und manchmal leistungsstarke Technik – und eine fortgeschrittene, optionale Lösung für den letzten Ausweg, die Google zufolge die meisten Websites nicht brauchen, um ihre Ziele zu erreichen. Behandle sie auch so.

Die echten Nachteile

Unabhängige Performance-Ingenieure waren hier die lautesten Stimmen, und ihre Aussagen decken sich mit Googles eigenen Vorbehalten.

Verlust des Caches bei wiederholten Besuchen. Matt Zeunert von DebugBear sagt es klar: Critical CSS kann bei verschiedenen Seitenladevorgängen deiner Website nicht wiederverwendet werden. Nachfolgende Seitenaufrufe können dadurch tatsächlich langsamer sein als ohne Critical CSS. Ein normales externes Stylesheet wird einmal gecacht und überall wiederverwendet; Inline-CSS wird in jeder HTML-Antwort erneut heruntergeladen.

Wartungs- und Regressionsrisiko. Harry Roberts’ konträre Abhandlung ist die meistzitierte Position, und seine Warnung lautet: Critical CSS nachträglich einzubauen ist schwierig und fehleranfällig: Sobald du CSS als deinen Engpass identifiziert hast, „musst du es so halten … Eine falsche Entscheidung kann alles zunichtemachen.“ Es gibt keine automatische erneute Validierung – eine Template- oder Designänderung kann deine kritische/nicht kritische Trennung unbemerkt kaputtmachen.

Wettläufe beim Zurückstellen. Roberts weist außerdem darauf hin, dass der Preload-/Onload-Tausch beim Timing nach hinten losgehen kann: Wenn das Parsen deines <head> 1 s dauert und das asynchrone Abrufen deines nicht kritischen CSS 0,5 s, wird das CSS 0,5 s vor deiner eigentlichen Bereitschaft wieder in eine synchrone Datei verwandelt. Und wenn nicht kritisches CSS spät eintrifft, riskierst du einen Flash of Unstyled Content und Layout Shift.

Oft ist es überhaupt nicht der Engpass. Roberts’ Kernaussage: Critical CSS hilft nur, wenn CSS dein größter renderblockierender Engpass ist – und das ist es ziemlich oft nicht. DebugBear stimmt zu: Prüfe vor dem Inline-Einfügen, ob CSS tatsächlich das Problem ist, denn wenn weiterhin renderblockierender JavaScript-Code vorhanden ist, wird Inline-CSS wahrscheinlich nicht helfen, und „oft ist es nicht die wirkungsvollste Optimierung.“

Produktionsfallen: CSP, Zustand und Schriften

Drei weitere Fehlermodi, die in einer schnellen Demo nicht auftauchen, aber nach dem Livegang zuschlagen:

Eine CSP-Richtlinie kann deinen inline eingefügten <style>-Block vollständig blockieren. Eine Content-Security-Policy-style-src-Richtlinie kann einen inline eingefügten kritischen <style>-Block blockieren, sofern die Richtlinie ihn nicht ausdrücklich erlaubt – normalerweise über eine Nonce oder einen passenden Hash. MDN dokumentiert die Verletzungsfälle und die Mechanismen für Nonce/Hash. Greif nicht zu unsafe-inline, um den Konsolenfehler verschwinden zu lassen; das schwächt die Richtlinie für die gesamte Website und ist keine Standardlösung. Verdrahte die Nonce-/Hash-Erzeugung im Werkzeug zur Extraktion des Critical CSS und prüfe nach dem Ausliefern die Browserkonsole auf Verstöße.

„Bei der Aufzeichnung ungenutzt“ ist nicht dasselbe wie „sicher zurückzustellen“. Der Coverage-Tab zeigt dir, welches CSS während eines aufgezeichneten Laufs ausgeführt wurde. Eine sichere Trennung muss die Reihenfolge der Kaskade und die Regeln für deine responsiven Breakpoints, Theme-Varianten, personalisierten Inhalte, Fokuszustände, geöffneten Menüs/Modals und Fehlerzustände erhalten – nicht nur das, was zufällig in diesem einen Durchlauf gerendert wurde. Roberts stellt dieselbe Frage aus einem anderen Blickwinkel: Welchen Viewport und welche Elemente außerhalb des Bildschirms oder ohne Interaktion (Dropdowns, Flyouts) muss deine Extraktion tatsächlich abdecken?

Es löst dein Schriftenproblem nicht und kann zusätzliche Renderarbeit erzeugen. Das Inline-Einfügen von Element-Styles macht eine Webschrift nicht selbst früher auffindbar und garantiert auch nicht, dass Text rechtzeitig gerendert wird – das Auffinden der Schrift, preload, font-display und Fallback-Metriken sind separate Abhängigkeiten, die Critical CSS nicht berührt. Und ein inline eingefügtes Subset, gefolgt von einem größeren Stylesheet, kann zusätzliche Style-Neuberechnung, Layout und Paint bedeuten; eine kürzere Abrufverzögerung bedeutet nicht automatisch weniger gesamte Renderarbeit. Miss beides, nicht nur den Netzwerk-Wasserfall.

So diagnostizierst du, ob du es überhaupt brauchst

Beginne angesichts all dessen nicht mit „Critical CSS hinzufügen“, sondern mit „bestätigen, dass CSS mein Render-Engpass ist“, und höre dort nicht auf. Vier Tore müssen alle erfüllt sein, bevor sich die Umsetzung lohnt:

1. CSS ist ein nachgewiesener Blocker, keine Vermutung.

  • Öffne den PageSpeed-Insights-/Lighthouse-Bericht. Seit Lighthouse 13 ist das alte Audit „Renderblockierende Ressourcen beseitigen“ in die Insight zu renderblockierenden Anfragen verschoben worden – ältere Artikel mit dem alten Auditnamen sind daher veraltet.
  • Verwende den Coverage-Tab in Chrome DevTools, um zu sehen, wie viel deines CSS (und JS) beim ersten Paint tatsächlich ungenutzt ist.
  • Trenne die Ursachen. Wenn dein Engpass renderblockierendes JavaScript oder eine langsame Serverantwort (TTFB) ist, wird Inline-CSS das nicht beheben – du würdest das falsche Problem optimieren.

2. Du kannst eine tatsächlich stabile Abdeckung der Extraktion aufbauen – über deine echten Breakpoints, Themes, Personalisierung und interaktiven Zustände hinweg, nicht nur für einen Desktop-Screenshot (siehe die Fallen oben).

3. Die Kosten für wiederholte Ansichten und CSP sind akzeptabel. Inline-CSS wird nicht gecacht; wäge das gegen die Tiefe deiner typischen Sitzung ab. Wenn du eine CSP-style-src-Richtlinie verwendest, muss die Nonce-/Hash-Erzeugung vor dem Livegang in die Pipeline integriert werden, nicht erst danach entdeckt werden.

4. Du wirst es tatsächlich pflegen. Generiere es bei jeder Template- oder Designänderung neu und führe die vollständige Testmatrix erneut aus – kalte und wiederholte Ladevorgänge, jede von dir unterstützte Route, jeden Viewport und jeden Zustand – nicht nur einen kurzen Blick nach dem Deployment.

Wenn alle vier Tore erfüllt sind, ist Critical CSS die Wartungskosten wert. Wenn eines davon nicht erfüllt ist, sind die günstigeren Lösungen – ungenutztes CSS entfernen, minifizieren, nicht kritische Stylesheets mit media eingrenzen – die bessere Wahl.

Eine aktuelle Besonderheit von 2026

Ein aktueller Stolperstein: Es gibt einen offenen, ungelösten Bericht, dass genau das Muster <link rel="preload" as="style">, das Googles Dokumentation zum Zurückstellen von CSS empfiehlt, nach einem Lighthouse-/PSI-Punktupdate wieder als renderblockierend markiert wurde. GitHub Issue #17031 dokumentiert, dass vorgeladenes CSS in Lighthouse 13.0.1 grün erschien und in 13.3.0 als renderblockierend markiert wurde. Zum jetzigen Zeitpunkt gibt es keine öffentliche Lösung von Google; behandle es daher als in Entwicklung. Die praktische Lehre bleibt aber: Wenn PSI dein korrekt zurückgestelltes CSS markiert, kann das Audit selbst falsch sein. Lies den Bericht kritisch, statt automatisch anzunehmen, dass deine Implementierung kaputt ist.

Hilft Critical CSS bei SEO?

Indirekt und in bescheidenem Umfang. Zwei Dinge müssen getrennt werden:

  • CSS ist kein direkter Rankingfaktor. Google beschreibt durch Martin Splitt CSS-Klassennamen so: „Ich glaube nicht, dass uns das interessiert, weil die CSS-Klassennamen eben genau das sind.“ Das bezieht sich ausdrücklich auf Klassennamen, widerlegt aber den weiter gefassten Mythos, dass deine CSS-Entscheidungen als Ranking-Eingabe gelesen werden.
  • Geschwindigkeit ist über Core Web Vitals ein (kleines) Signal. Critical CSS kann den ersten Paint verbessern, dadurch LCP verbessern und damit eine Core-Web-Vitals-Metrik beeinflussen, die in Googles Signale für die Seitenerfahrung einfließt. Das ist die gesamte SEO-Verbindung: ein schnellerer Paint, kein Bonus für die Technik an sich.

Der SEO-Fall für Critical CSS ist also genau so stark wie seine Auswirkung auf das LCP deiner Website – und diese ist laut Google und der Performance-Community häufig kleiner, als Anbieterwerkzeuge zur Vermarktung der Technik vermuten lassen.

Und was ist mit Bing?

Nichts Bing-Spezifisches. Anders als Google, das mehrere web.dev-Seiten und ein Codelab zu dieser Technik hat, konnte ich kein eigenes Bing-/Microsoft-Dokument zu Critical CSS finden. Bings allgemeine Hinweise zu Seitenerfahrung gelten weiterhin: Dinge schnell halten und kritische Inhalte erreichbar halten. Ein Bing-Gegenstück zum Critical-CSS-Codelab von web.dev gibt es aber nicht. Wer behauptet, Bing habe eine konkrete Critical-CSS-Empfehlung, erfindet sie.

Wo das einzuordnen ist

Diese Seite ist unter dem Hub Critical Rendering Path eingeordnet – Critical CSS ist eine Taktik, um diesen Pfad zu verkürzen – und ist das praktische Gegenstück zu renderblockierenden Ressourcen. Der Nutzen, falls einer entsteht, zeigt sich bei Largest Contentful Paint (LCP), First Contentful Paint (FCP) und dem umfassenderen Set der Core Web Vitals. Für das größere Performance-Bild siehe den Web-Performance-Cluster.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.