Ein Stylesheet ist selten der größte Posten eines Ladevorgangs -- Bilder und JavaScript wiegen deutlich mehr. Trotzdem entscheidet CSS darüber, wann überhaupt etwas zu sehen ist: Solange eine im Dokumentkopf verlinkte Datei nicht geladen und ausgewertet ist, hält der Browser den Bildaufbau an. Auf der mobilen Median-Startseite sind das 77 KB (Web Almanac 2025) CSS, verteilt auf 8 (Web Almanac 2025) Anfragen. Interessant an dieser Zahl ist weniger ihre Höhe als ihre Herkunft: Dieselben acht Dateien liegen meist auf jeder Unterseite, weil sie einmal für die ganze Website zusammengestellt wurden. Die Formularregeln der Kontaktseite halten damit auch den Blogartikel auf, die Stilangaben eines abgeschalteten Bausteins reisen weiter mit, und niemand entfernt sie, weil niemand belastbar sagen kann, wo sie noch gebraucht werden. Dieser Beitrag zeigt, wie sich der ungenutzte Anteil messen lässt, was Critical CSS dabei löst und was nicht, und in welcher Reihenfolge sich Ballast ohne Darstellungsschäden entfernen lässt. In unserer Frontend-Optimierung ist der Stylesheet-Bestand einer der ersten Posten, die wir aufnehmen.
Das Wichtigste in Kürze
- CSS ist klein, aber es blockiert: Jede im Dokumentkopf verlinkte Datei hält den ersten Bildaufbau an, bis sie geladen und ausgewertet ist. Nur 15 Prozent (Web Almanac 2025) der mobilen Seiten bestehen die Lighthouse-Prüfung auf renderblockierende Ressourcen.
- Der Ballast entsteht nicht durch schlechte Regeln, sondern durch Bündel: Ein Satz Stylesheets wird für die ganze Website gebaut und auf jeder Unterseite ausgeliefert. Im 90. Perzentil sind das 268 KB (Web Almanac 2025) CSS mobil und 31 (Web Almanac 2025) Dateien je Startseite.
- Messen geht mit Bordmitteln: Die Abdeckungsansicht der Entwicklerwerkzeuge zählt genutzte und ungenutzte Bytes je Datei (Chrome for Developers), Lighthouse listet Stylesheets ab 2 KiB (Chrome for Developers) möglicher Ersparnis. Beide Werte gelten für genau den Ablauf, den die Messung erfasst hat.
- Critical CSS beschleunigt den sichtbaren Bereich, räumt aber nicht auf: Der Rest wird weiter geladen und ausgewertet. Im Beispiel der Chrome-Dokumentation sank der First Contentful Paint um 0,2 Sekunden (web.dev) und damit um 20 Prozent (web.dev) -- der Ballast blieb dabei im Bündel.
- Entfernen wird planbar, wenn die Struktur mitspielt: Zuschnitt je Vorlage, bedingtes Laden über Medienabfragen und Kaskadenebenen -- in stabilen Fassungen seit Chrome 99 (MDN) -- senken das Risiko, dass eine gelöschte Regel an anderer Stelle fehlt.
Warum aus acht Stylesheets unsichtbarer Ballast wird
Der Weg dorthin ist in fast jedem Projekt derselbe. Am Anfang steht ein Grundgerüst mit einer Datei. Dann kommt ein Baukasten für Landeseiten dazu, der seine Stilangaben pauschal auf jeder Seite anmeldet. Dann eine Erweiterung für Bewertungen, deren Regeln auch dort geladen werden, wo keine Bewertung steht. Dann eine Kampagne mit eigenem Layout, die drei Monate später wieder abgeschaltet wird -- die Stildatei bleibt eingebunden, weil sie in einer Vorlage hängt, die niemand mehr anfasst. Am Ende liegt ein Bündel vor, das die Vereinigungsmenge aller Seiten abdeckt und auf jeder einzelnen Seite ausgeliefert wird. Bei Themes und Baukastensystemen verstärkt sich der Effekt, weil die Stilangaben für Bausteine mitkommen, die in dieser Installation gar nicht zum Einsatz kommen; welche Bremsen daraus im Alltag entstehen, ordnet der Beitrag zu den häufigen Bremsen in WordPress-Installationen ein.
Die Verteilung zeigt, dass das kein Randfall ist. Im 90. Perzentil liefert eine mobile Seite 268 KB (Web Almanac 2025) CSS aus, und auf Startseiten steigt die Zahl der CSS-Dateien dort auf 31 (Web Almanac 2025). Das Muster ist zudem alt: Schon in der CSS-Auswertung des Jahres 2022 lagen im 90. Perzentil 22 (Web Almanac 2022) Stylesheets je Seite. Neu ist also nicht das Volumen, neu ist die Erwartung an die Ladezeit. Besonders deutlich summiert sich das in Shops mit vielen Vorlagen -- Startseite, Kategorie, Detailseite, Warenkorb, Konto --, wie der Beitrag zu Ladezeiten in Shopware-Projekten an den typischen Stellschrauben zeigt.
Renderblockierend heißt nicht 'langsam geladen'
Den ungenutzten Anteil belastbar messen
Zwei Bordmittel reichen für den Einstieg. Lighthouse führt unter den Einsparpotenzialen alle Stylesheets auf, deren ungenutzter Anteil mindestens 2 KiB (Chrome for Developers) beträgt, und beziffert die mögliche Ersparnis in Kilobyte. Das ist eine Grobsortierung: Sie sagt, welche Datei sich anzusehen lohnt, nicht welche Regel weg kann. Wie sich die Befunde eines Berichts nach Wirkung ordnen lassen, statt sie von oben nach unten abzuarbeiten, beschreibt der Beitrag zum Lesen und Priorisieren eines Lighthouse-Berichts.
Genauer wird es mit der Abdeckungsansicht der Entwicklerwerkzeuge. Sie zeichnet während einer Aufnahme mit, welche Bytes einer Datei tatsächlich angewendet wurden, und stellt genutzten und ungenutzten Anteil je Datei gegenüber (Chrome for Developers). Die Aufnahme läuft über einen Ablauf, den man selbst bestimmt: Seite laden, scrollen, Menü öffnen, Formular abschicken. Genau darin liegt der Wert -- und die Falle. Ergänzend lohnt der Blick auf die Serverseite, denn ein spät ausgeliefertes Stylesheet kann auch an der Antwortzeit hängen; wie sich diese Zeit aufschlüsseln lässt, zeigt der Beitrag zu Server-Timing im Backend.
Wo die Abdeckungsmessung in die Irre führt
Eine Abdeckungsmessung ist die Momentaufnahme eines einzigen Ablaufs auf einer einzigen Seite. Regeln für Zustände, die während der Aufnahme nicht eingetreten sind -- geöffnetes Menü, Fehlermeldung im Formular, Tastaturfokus, Druckausgabe --, erscheinen als ungenutzt, obwohl sie gebraucht werden. Umgekehrt zählt eine Regel als genutzt, sobald sie auf ein einziges Element passt, selbst wenn dieses Element nur auf einer von zweihundert Seiten vorkommt. Belastbar wird das Bild erst, wenn man die Messung über mehrere Vorlagen und mehrere Zustände wiederholt und die Ergebnisse zusammenführt: Was in keiner einzigen Aufnahme angefasst wurde, ist ein Kandidat. Was in einer einzigen Aufnahme auftaucht, bleibt. Große Dokumente verschärfen die Lage zusätzlich, weil mehr Elemente gegen mehr Selektoren geprüft werden müssen -- dazu passt der Beitrag zur Reduzierung der DOM-Größe.
// Je Stylesheet zählen, welche Regeln auf DIESER Seite auf kein Element passen.
// Ergebnis über mehrere Vorlagen sammeln -- ein einzelner Lauf beweist nichts.
const bericht = [];
for (const blatt of document.styleSheets) {
let regeln;
try {
regeln = blatt.cssRules; // fremde Herkunft wirft hier
} catch {
bericht.push({ datei: blatt.href, hinweis: 'nicht lesbar' });
continue;
}
let gesamt = 0, ohneTreffer = 0;
for (const regel of regeln) {
if (!(regel instanceof CSSStyleRule)) continue; // @media separat behandeln
gesamt++;
try {
if (!document.querySelector(regel.selectorText)) ohneTreffer++;
} catch {
// Selektoren mit ::before lassen sich so nicht abfragen
}
}
bericht.push({ datei: blatt.href, gesamt, ohneTreffer });
}
console.table(bericht);Der Bericht ist ein Anhaltspunkt, kein Urteil. Er zählt Regeln, nicht Bytes, er sieht nur, was das Dokument im Moment der Ausführung enthält, und er kann Regeln für Zustände nicht beurteilen, die eine Interaktion erst herstellt. Sein Wert liegt in der Wiederholung: Lässt man ihn auf zehn Vorlagen laufen und legt die Ergebnisse übereinander, zeichnet sich schnell ab, welche Datei auf keiner einzigen Vorlage nennenswert zum Einsatz kommt. Wer solche Werte nicht einmalig im Browser, sondern laufend aus dem Feld sammeln möchte, braucht dafür einen Übertragungsweg, der die Seite nicht ausbremst -- wie das geht, zeigt der Beitrag zu fetchLater und verzögert gesendeten Messdaten.
Was Critical CSS löst -- und was es offenlässt
Der übliche erste Schritt heißt Critical CSS: Die Regeln für den sofort sichtbaren Bereich wandern als eingebetteter Block in das Dokument, der Rest wird so nachgeladen, dass er den Bildaufbau nicht mehr anhält. Als Zielgröße für diesen sichtbaren Bereich nennt die Chrome-Dokumentation 14 KB (web.dev) komprimiert, damit der erste Aufbau ohne weitere Netzumläufe auskommt. Die Wirkung ist messbar: Im Beispiel der Dokumentation sank der First Contentful Paint um 0,2 Sekunden (web.dev) und damit um 20 Prozent (web.dev). Wie der Zuschnitt praktisch aussieht und wo er im Bauprozess sitzt, beschreibt der Beitrag zu Critical CSS für den sichtbaren Bereich.
Der Rest bleibt im Bündel
Nachgeladenes CSS ist nicht gespartes CSS. Die Datei wird weiterhin übertragen, ausgewertet und in das Objektmodell eingehängt, und jede Regel nimmt danach an der Stilberechnung teil. Der erste Bildaufbau wird schneller, die Arbeit je Seitenwechsel bleibt gleich.
Der Zuschnitt veraltet
Critical CSS gilt für einen bestimmten Bildausschnitt und einen bestimmten Stand der Vorlage. Ändert sich das Layout, passt der eingebettete Block nicht mehr, und im ungünstigen Fall entsteht ein sichtbarer Sprung. Der Zuschnitt gehört deshalb in den Bauprozess und nicht in eine einmalige Handarbeit.
Schriften bleiben ein eigener Posten
Ein eingebetteter Kritikblock hilft wenig, wenn die Schriftdatei den Text zurückhält. Ladeverhalten, Vorabladen und Ersatzschrift entscheiden hier mit -- der Beitrag zur Optimierung von Web-Fonts ordnet das ein.
| Maßnahme | Erster Bildaufbau | Übertragene Menge | Stilberechnung je Seite |
|---|---|---|---|
| Critical CSS einbetten | deutlich früher | unverändert | unverändert |
| Nachladen ohne Blockade | früher | unverändert | unverändert |
| Zuschnitt je Vorlage | früher | kleiner | kürzer |
| Bedingtes Laden per Medienabfrage | früher | kleiner | kürzer |
| Regeln löschen | früher | kleiner | kürzer |
Vier Wege, den Bestand wirklich zu verkleinern
Der erste Weg ist der Zuschnitt je Vorlage. Statt eines Bündels für die ganze Website entsteht je Seitentyp ein eigenes, das den gemeinsamen Sockel und die Regeln dieser Vorlage enthält. Der gemeinsame Sockel bleibt zwischengespeichert, der vorlagenspezifische Teil ist klein. Der zweite Weg ist das bedingte Laden: Stylesheets für Druckausgabe, sehr breite Ansichten oder eine bestimmte Ausgabeart bekommen eine Medienbedingung. Die Spezifikation hält ausdrücklich fest, dass ein Browser eine bedingte Einbindung nicht laden muss, solange die Bedingung nicht zutrifft (W3C) -- aus einer blockierenden Anfrage wird so im besten Fall gar keine. Beide Wege sind dieselbe Denkbewegung wie beim Aufteilen von JavaScript, die der Beitrag zu Lazy Loading und Code-Splitting für Skripte beschreibt.
Der Kern in einem Satz
Löschen ohne Darstellungsschäden
Der dritte Weg macht das Löschen überhaupt erst zumutbar: eine Struktur, in der klar ist, welche Regel welche andere überschreibt. Kaskadenebenen ordnen Stilangaben in benannte Schichten -- Grundgerüst, Bausteine, Ausnahmen -- und legen die Rangfolge einmal fest, statt sie über Spezifität und Wichtigkeitsmarkierungen auszufechten. Verfügbar sind sie in den stabilen Fassungen seit Chrome 99 (MDN), Firefox 97 (MDN) und Safari 15.4 (MDN). Wer Ebenen sauber trennt, kann eine Schicht entfernen, ohne dass eine Regel aus einer anderen Schicht plötzlich gewinnt. Der vierte Weg ist der unspektakulärste: Minifizierung. 62 Prozent (Web Almanac 2025) der mobilen Startseiten bestehen die entsprechende Lighthouse-Prüfung -- der Rest liefert Stildateien mit Einrückungen und Kommentaren aus. Das ersetzt keinen Zuschnitt, kostet aber nur einen Schritt im Bauprozess und wirkt auf jede Vorlage. Wie Zuschnitt und Einbettung zusammenspielen, zeigt erneut der Beitrag zu Critical CSS für den sichtbaren Bereich.
Drei Befunde, die keine sind
Ein Vorgehen, das im Bestand funktioniert
Im laufenden Betrieb ist der große Wurf selten die richtige Wahl. Wer das Bündel in einem Schritt neu schneidet, hat bei einem Darstellungsfehler keine Möglichkeit, die Ursache einzugrenzen. Sinnvoller ist eine Reihenfolge, die mit dem größten Hebel beginnt und jeden Schritt einzeln absichert. Damit der Gewinn nicht nach zwei Quartalen wieder verschwunden ist, gehört am Ende eine Obergrenze dazu -- dieselbe Logik, die der Beitrag zu Performance-Budgets für JavaScript für Skripte beschreibt, lässt sich auf die CSS-Menge je Vorlage übertragen.
- Bestand aufnehmen: Welche Stylesheets werden auf welcher Vorlage eingebunden, wie groß sind sie, und welche kommen aus Erweiterungen, die noch aktiv sind?
- Abdeckung über mindestens fünf Vorlagen und die wichtigsten Zustände messen und die Ergebnisse zusammenführen -- Kandidat ist nur, was in keiner Aufnahme angefasst wurde
- Ganze Dateien vor einzelnen Regeln entfernen: Eine Erweiterung, die auf keiner Vorlage etwas beiträgt, abzumelden ist risikoärmer als das Kürzen einer Datei, die weiter gebraucht wird
- Den Rest je Vorlage zuschneiden, den gemeinsamen Sockel getrennt halten und Druck- sowie Sondervarianten an eine Medienbedingung binden
- Jeden Schritt mit einem Bildvergleich je Vorlage und Zustand absichern und die CSS-Menge als Obergrenze in die Auslieferung aufnehmen, wie es der Beitrag zu Performance-Budgets im Bauprozess beschreibt
Gemessen wird das Ergebnis nicht am Dateigewicht, sondern an der Zeit bis zum ersten sichtbaren Inhalt. Als guter Wert gelten 1,8 Sekunden (web.dev) für den First Contentful Paint, und zwar im 75. Perzentil (web.dev) der Seitenaufrufe, getrennt nach mobil und Desktop. Das ist der ehrlichere Maßstab: Ein Bündel, das im Labor gut aussieht, kann im Feld an einer langsamen Verbindung weiterhin drei Sekunden kosten. Wo genau die Zeit bleibt und welche Vorlage die schlechtesten Werte liefert, klärt eine technische Performance-Analyse mit Feld- und Labordaten nebeneinander.
Die Frage ist selten, ob eine Regel schön geschrieben ist. Die Frage ist, ob die Seite, die sie herunterlädt, sie überhaupt braucht -- und diese Antwort steht in keiner Datei, sondern in der Messung über alle Vorlagen.
Ungenutztes CSS ist damit weniger ein Aufräumthema als eine Frage der Auslieferung: Nicht die Regel ist das Problem, sondern die Seite, die sie ohne Anlass mitbringt. Wer den Bestand je Vorlage kennt, den gemeinsamen Sockel bewusst klein hält und jede Erweiterung daran misst, was sie auf welcher Vorlage beiträgt, gewinnt zweimal: beim ersten Bildaufbau und bei jeder Stilberechnung danach. Wie sich die Wirkung solcher Eingriffe in den Kennzahlen niederschlägt, die Suchmaschinen und Nutzer gleichermaßen bewerten, ordnet unsere Seite zu den Core Web Vitals ein.
Quellen und Studien