Kritisches CSS.

Kritisches CSS ist die minimale Stilmenge, die zum Malen des ersten sichtbaren Bereichs der Seite nötig ist, und lässt sich sofort anwenden, ohne auf eine eigene Datei zu warten.

Der Browser malt nichts, bevor die Stildateien geladen und geparst sind. Diese Regel macht Stildateien renderblockierend: Jede ist eine Anfrage und ein Warten. Liegen auf der Seite drei getrennte Stildateien, wartet das erste Malen auf alle drei.

Der Ansatz des kritischen CSS will dieses Warten verkürzen: Die Regeln für den ersten sichtbaren Bereich werden herausgelöst und direkt in die Seite eingebettet, der Rest lädt später auf nicht blockierende Weise. Das erste Malen wartet dann auf keine Netzanfrage.

Wann es sich lohnt, wann nicht

Die Technik ist stark, aber nicht gratis, und nicht jede Website hat einen Gegenwert. Der Gewinn hängt von der Größe der Stildatei und der Geschwindigkeit des Servers ab; sind beide gut, kann der Gewinn zu klein bleiben, um messbar zu sein.

Auf dieser Website wurde der Ansatz geprüft und NICHT gewählt. Die Begründung wurde gemessen: Zwei getrennte Stildateien wurden zu einer verschmolzen und die Kommentare entfernt; das Ergebnis war 12,4 Kilobyte nach gzip. Eine einzelne Datei dieser Größe kommt von einem guten Server in einem Umlauf, und der Gewinn des kritischen CSS rechtfertigt die Komplexität des Systems nicht.

Die Entscheidung fiel mit Zahlen. Vor der Verschmelzung blockierten im mobilen Lighthouse-Lauf zwei Dateien das Rendern: eine 821 Millisekunden, die andere 221. Die Verschmelzung schloss beide. Kritisches CSS wäre der Versuch gewesen, die danach verbliebene Zeit zu teilen — und es blieb keine Zeit zu teilen.

Eine Technik kann gut sein und auf Ihrer Website unnötig; beides widerspricht sich nicht.

Wenn angewandt, dann wie

Es gibt Fälle, in denen kritisches CSS wirklich nötig ist: große Designsysteme, vielseitige Anwendungen und Websites mit Stildateien von Hunderten Kilobyte. Dort wird der Ansatz so aufgebaut.

1. Den sichtbaren Bereich festlegen — für welche Bildschirmgröße? Meist wird der schmalste und häufigste Umbruch gewählt.
2. Die Regeln herauslösen — ein Werkzeug sammelt die in diesem Bereich verwendeten Selektoren; von Hand geschieht das nicht.
3. In den Rumpf einbetten — die herausgelösten Regeln kommen in die Seite, angewandt vor dem ersten Malen.
4. Den Rest ohne Blockieren laden — die übrigen Stile kommen später auf einem Weg, der das Malen nicht blockiert.
5. Je Seitentyp erzeugen — die kritische Menge der Startseite ist nicht die der Beitragsseite.
6. Automatisieren — eine von Hand gepflegte kritische Menge veraltet bei der ersten Designänderung.

Der letzte Punkt ist der eigentliche Preis dieser Technik. Kritisches CSS muss neu erzeugt werden, während sich das Design ändert; einmal herausgelöst und vergessen, geschieht das erste Malen mit falschen Stilen, und die Seite „springt“ sichtbar. Ein schlechteres Ergebnis, als gar kein kritisches CSS zu verwenden.

Die Spannung zur Content-Security-Policy

Kritisches CSS in den Rumpf einzubetten heißt, Inline-Stile zu verwenden — und eine strenge Content-Security-Policy blockiert Inline-Stile. Die zwei Ziele kollidieren direkt, und es muss gewählt werden.

Die Policy zu lockern ist eine Option, hat aber einen Sicherheitspreis; jedem Inline-Block eine eigene Signatur zu geben ist möglich, verkompliziert aber die Produktionskette. Auf dieser Website wurde die Policy streng gehalten und Inline-Stil nie erlaubt — der zweite Grund, warum kritisches CSS nicht gewählt wurde.

Die allgemeine Lehre: Performance-Techniken lassen sich nicht im Vakuum bewerten. Eine Technik wird zusammen mit Ihrer Sicherheitspolitik, Ihrer Wartungskapazität und Ihren vorhandenen Messungen gewogen. Es gibt keine für alle richtige Liste; es gibt eine gemessene und entschiedene.

Die Alternative: die Datei verkleinern

Das Problem, das kritisches CSS lösen will — das Warten auf die Stildatei —, lässt sich auch anders verringern: die Datei wirklich verkleinern. Und auf den meisten Websites ist dieser Weg billiger, dauerhafter und weniger riskant.

1. Unbenutzte Regeln entfernen — auf den meisten Websites wird der Großteil der Stildatei auf keiner Seite verwendet.
2. Die Framework-Standards wiegen — ein fertiges CSS-Framework lässt womöglich zehn Prozent seiner mitgebrachten Regeln nutzen.
3. Die Kommentare entfernen — in der Quelle bleiben sie, in die Produktion gehen sie nicht.
4. Die Kompression verifizieren — sendet der Server wirklich komprimiert? Nicht annehmen, prüfen.
5. In einer Datei sammeln — auch auf modernen Protokollen sollte der fürs erste Malen nötige Stil in einer Anfrage kommen.

Auf dieser Website wurden vier der fünf Punkte angewandt, und das gemessene Ergebnis ist 12,4 Kilobyte gzip. Eine Datei dieser Größe kommt von einem guten Server in einem Umlauf; der Gewinn des Herauslösens bleibt zu klein zum Messen und rechtfertigt die Komplexität nicht.

Die allgemeine Lehre: Ob eine Technik nötig ist, zeigt die Messung vor ihrer Anwendung. Kritisches CSS ist eine echte Lösung für große Stildateien — aber zuerst muss man prüfen, ob die Datei wirklich groß ist.

Zum Abschluss ein Messvorschlag: Die Zeit des ersten Malens sollte vor und nach dem kritischen CSS gemessen und der Unterschied notiert werden. Die Technik wirkt intuitiv richtig, und genau deshalb wird sie ohne Messung angewandt — doch bei kleinen Stildateien kann der Gewinn im Messrauschen bleiben. Eine ungemessene Optimierung ist eine Annahme; und eine Annahme mit Wartungskosten wird mit der Zeit zum Verlust.

Auf dieser Website fiel die Entscheidung genau so: Die Technik wurde bewertet, die vorhandene Messung betrachtet, der Gewinn geschätzt und mit der Komplexität verglichen. Das Ergebnis war, sie nicht anzuwenden — und die Begründung wurde dokumentiert, damit die Antwort bereitliegt, wenn künftig jemand dieselbe Frage stellt.

Dazu kommt die Frage der Teamgröße: Die Produktion kritischen CSS fügt einen Schritt hinzu, der bei jeder Designänderung neu laufen muss, und wird dieser Schritt vergessen, ist das Ergebnis schlechter als ganz ohne kritisches CSS. In kleinen Teams kann die Wartungslast den Gewinn übersteigen. Eine Technik ist nicht nur nach ihrem Performance-Ertrag zu wählen, sondern nach der Kapazität, diesen Ertrag zu erhalten.

Eine praktische Checkliste

Übersetzt man diese Seite in einen Prüfschritt, ist für die Renderkosten der Stildateien Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.

1. Wie viele Stildateien kommen herunter — mehr als eine ist ein Verschmelzungskandidat.
2. Wie groß nach gzip — eine Datei um zehn Kilobyte kommt in einem Umlauf.
3. Wie hoch der Anteil unbenutzter Regeln — Framework-Standards sind die größte Quelle der Aufblähung.
4. Gehen Kommentare in die Produktion — in der Quelle bleiben, in der Ausgabe nicht.
5. Komprimiert der Server — nicht annehmen, messen.
6. Ist kritisches CSS wirklich nötig — NACH dem Verkleinern der Datei zu fragen.

Der sechste Punkt ist die These dieser Seite: Die Technikwahl folgt der Messung. Auf dieser Website lief die Reihenfolge genau so — zuerst Verschmelzen und Entfernen, das Ergebnis war 12,4 Kilobyte gzip, und an diesem Punkt rechtfertigte der Gewinn des kritischen CSS die Komplexität nicht.