Critical CSS: Den sichtbaren Bereich blitzschnell rendern

Eine externe Stildatei blockiert den Aufbau der Seite, bis sie vollständig geladen und ausgewertet ist. Critical CSS dreht das um: Die Regeln für den sichtbaren Bereich stehen direkt im Dokument, der Rest wird nachgeladen. In einem Projekt sank der Zeitpunkt des ersten Inhaltsaufbaus dadurch von 2,4 auf 1,1 Sekunden – bei einer Stildatei von 180 Kilobyte, von denen nur 14 Kilobyte den ersten Bildschirm betrafen.

##Warum blockiert CSS den Seitenaufbau?

Weil der Browser ohne Stilregeln nicht weiß, wie er das Dokument darstellen soll, und deshalb wartet. Anders als ein Skript lässt sich eine Stildatei nicht ohne Risiko verzögern: Würde der Browser den Inhalt ungestaltet zeigen und später umbrechen, sähe der Besucher einen sichtbaren Sprung. Das Warten ist also kein Fehler des Browsers, sondern eine bewusste Entscheidung.

##Wie kommt man an das kritische CSS?

Durch Extraktion beim Build. Ein Werkzeug rendert die Seite in einem Browser, sammelt alle Regeln, die auf Elemente im sichtbaren Bereich zutreffen, und schreibt sie in eine kleine Datei. Der Rest bleibt in der ursprünglichen Stildatei, die mit einem nachrangigen Ladeverweis nachgezogen wird. Die Extraktion läuft einmal pro Build, nicht bei jedem Aufruf.

##Welche Fehler passieren bei der Extraktion?

Drei, und alle drei sind sichtbar. Regeln für Zustände wie beim Überfahren mit der Maus fehlen, weil sie beim Sammeln nicht ausgelöst werden. Regeln für Elemente knapp unterhalb der Bildschirmgrenze fehlen, weil der sichtbare Bereich zu knapp gemessen wurde. Und Regeln für Ansichten, die im Rendering nicht vorkamen, fehlen ganz. Jede dieser Lücken erzeugt ein kurzes Aufblitzen ungestalteter Elemente.

##Wie groß darf das kritische CSS sein?

Klein genug, dass es die Einsparung nicht auffrisst. Es steht im Dokument selbst und wird damit bei jedem Aufruf erneut übertragen – es lässt sich nicht wie eine externe Datei zwischenspeichern. Als Orientierung gilt ein Bereich von 10 bis 20 Kilobyte; darüber ist der Gewinn durch die Blockadevermeidung oft kleiner als die zusätzlich übertragene Menge bei jedem Aufruf.

##Wann lohnt sich der Aufwand nicht?

Wenn Ihre Stildatei klein ist. Bei 20 Kilobyte Gesamtgröße liegt der Gewinn im Millisekundenbereich, während die Extraktion eine zusätzliche Fehlerquelle in den Build bringt. Ebenso bei Seiten mit sehr unterschiedlichen Ansichten: Je mehr Vorlagen, desto mehr Varianten kritischen CSS, desto größer der Wartungsaufwand. Prüfen Sie zuerst, wie viel Ihrer Stildatei überhaupt den ersten Bildschirm betrifft.

##Wie prüft man das Ergebnis?

Indem man den ersten Aufbau mit und ohne Extraktion vergleicht – aus dem leeren Zwischenspeicher, nicht aus dem warmen. Zusätzlich lohnt ein Blick auf den Layout-Shift-Wert: Ein zu knapp extrahiertes kritisches CSS verschiebt den Aufbau nach hinten und verschlechtert genau den Wert, den es verbessern sollte. Messen Sie außerdem auf einem gedrosselten Mobilprofil, nicht im schnellen Büronetz.

##Wie oft muss die Extraktion erneuert werden?

Bei jeder Änderung an Gestaltung oder Vorlage. Ein einmalig extrahiertes kritisches CSS veraltet mit dem nächsten Redesign und erzeugt danach genau die ungestalteten Blitze, die es verhindern sollte. Die Extraktion gehört deshalb fest in den Build und nicht in eine einmalige Aktion – sonst hält der Effekt genau bis zur ersten Überarbeitung.

##Nachrangig laden statt blockieren

Critical CSS ist eine Umverteilung: Weniger Blockade am Anfang, dafür eine kleine Zusatzmenge bei jedem Aufruf. Der Effekt ist am größten bei umfangreichen Stildateien und langsamen Verbindungen. Beginnen Sie mit einer Vorlage, messen Sie den ersten Aufbau, und führen Sie die Extraktion nur dort ein, wo die Messung einen klaren Unterschied zeigt. Bei den übrigen Vorlagen lohnt sie nicht.