Inline Critical CSS – Wie eine Bad Practice zum Geschwindigkeitsboost führen kann

Ein Ergebnis von 89 % bei Google Pagespeed Insights. Dann kann es bis zur 100 nicht mehr weit sein. Nach stundenlanger Bild- und Cacheoptimierung, Zusammenfassung von CSS- und Javascript-Dateien kommt nun der Endgegner. Was er bedeutet und wie ihr ihn besiegen könnt, erfahrt ihr in diesem Beitrag.

Eine rätselhafte Meldung bei den Pagespeed Insights

Nachdem erfolgreich alle bisherigen Meldungen abgearbeitet und eliminiert wurden, leuchtet nur noch ein Hinweis auf:

Unter dieser Meldung werden CSS- und Javascript-Dateien aufgelistet, die das Rendern der Seite verzögern sollen. Aber warum tun sie das?
Eine kurze Erklärung:
Nach der Anfrage des Browsers an den Server sendet dieser die Struktur der Website in einem HTML-Dokument zurück. Der Browser liest dieses von oben nach unten aus und stellt dann die Seite dar. Dabei stößt er gelegentlich auf Dateien, die nachgeladen werden müssen. Er stellt erneut eine Anfrage an den Server und ruft die entsprechenden Dateien ab. Dieser Dateiabruf kostet aber Zeit, in der die Darstellung der Seite nicht fortgeführt wird. Das Rendering wird blockiert.
Während die Lösung bei Skripten vergleichsweise einfach ist – sie können an das Ende des HTML-Dokumentes verschoben oder asynchron geladen werden- ist die Lösung für CSS-Dateien etwas aufwendiger. Werden die CSS-Dateien auch ans Ende des Dokuments verschoben, sehen wir beim Laden erst einmal die unformatierten Inhalte. Das ist optisch nicht gewollt und kann den Seitenbesucher verwirren. Was kann getan werden?

Die Lösung – Inline Critical CSS

Google schlägt hier die passende Lösung in seiner Dokumentation bereits vor. CSS-Anweisungen, welche für die saubere Darstellung der Website benötigt werden – das „kritische CSS“ – sollen inline direkt im Kopfbereich eingefügt werden. Jetzt kommt Panik auf!
„Ich habe doch gelernt, dass man Struktur und Darstellung voneinander trennen soll“. Dieser Grundsatz ist auch weiterhin korrekt. An dieser Stelle muss überlegt werden, wie wichtig es ist, Google zufriedenzustellen und noch ein paar extra Millisekunden Ladezeit herauszuholen, dafür aber Grundsätze der Webentwicklung über den Haufen zu werfen.
Geht man nun den Weg und versucht, sein CSS inline im Kopfbereich unterzubringen, stellen sich verschiedene Fragen. Wie binde ich das Inline-CSS am besten ein? Was ist eigentlich kritisch für die Darstellung meiner Website?

Welcher Teil meines Stylesheets ist „kritisch“?

In den meisten Fällen ist es nicht leicht zu filtern, was in der CSS-Datei letztendlich als kritisch anzusehen ist. Das funktioniert vielleicht noch bei kleineren Webseiten, wird aber bei größeren Internetauftritten oder sogar in Content-Management-Systemen mit einer Vielzahl an Stylesheets fast unmöglich.
Glücklicherweise gibt es verschiedene Tools, die diese Arbeit für den Programmierer abnehmen. Um einzelne Dateien zu analysieren und den kritischen Teil zu extrahieren, kann zum Beispiel der Critical Path CSS Generator von Jonas Ohlsson zum Einsatz kommen. Hier müssen die URL der betreffenden Seite und das dazugehörige CSS eingegeben werden. Der Generator analysiert das Stylesheet und gibt dann den kritischen Teil aus. Dieser wird dann noch mit einem CSS Minifier, z.B. cssminifier.com, zusammengefasst und in den -Bereich des HTML-Dokuments eingefügt.

Für größere Systeme können Taskrunner wie Grunt oder Gulp, in Kombination mit entsprechenden Plug-Ins, genutzt werden. Führt dieser die passende Aufgabe aus, wird bei jedem Durchlauf das gewünschte kritische CSS generiert.

In Grunt kann dafür das Plug-In Penthouse eingesetzt werden. Mit dem Paketmanager npm wird dieses heruntergeladen und integriert:
npm install grunt-penthouse –save-dev

Im Gruntfile wird das Plug-In dann geladen:

grunt.loadNpmTasks('grunt-penthouse');

und konfiguriert:

grunt.initConfig({  penthouse: {    extract : {        outfile : '.tmp/out.css',        css : './dist/css/full.css',        url : 'http://localhost:9000',        width : 1300,        height : 900,        skipErrors : false // this is the default     },  },});

Das outfile kann im Anschluss mithilfe eines CSS-Minifiers (z. B. cssmin) zusammengefasst werden.

Einbindung in den Quelltext

Der Inhalt der erstellten CSS-Datei wandert nun in ein style-Tag im Kopfbereich. Dies ist ein wichtiger Punkt, denn diese Technik berechtigt den Entwickler nicht dazu die Styles an die entsprechenden Tags selbst zu schreiben:

In einfachen, selbst geschriebenen Webseiten, mit Zugriff auf die HTML-Dateien, lässt sich dies recht einfach umsetzen. In größeren Umgebungen, wie Content-Management-Systemen, ist der richtige Ort für das Einfügen des Codes nicht gleich ersichtlich. Für die verschiedenen Systeme gibt es unterschiedliche Herangehensweisen.
In WordPress kann das populäre Modul Autoptimize verwendet werden. Es fasst CSS und Javascript zusammen und komprimiert die entstandenen Dateien. In der Konfiguration des Moduls kann dann das entsprechende Critical CSS eingefügt werden und alle anderen CSS-Dateien landen am Ende des Dokumentes.

Für das CMS Drupal in der Version 8 gibt es auch eine einfache Lösung. Hier muss nicht einmal ein zusätzliches Modul installiert werden. Innerhalb des Twig-Templates, welches die HTML-Ausgabe rendert, wird eine Zeile im Kopfbereich einfach hinzugefügt:

Damit wird die Datei „inline.css“ ausgelesen und deren Inhalt in den Seitenkopf geschrieben. Danach muss folgende Zeile in den Fußbereich verschoben werden:

css-placeholder token="{{ placeholder_token|raw }}

Dies führt dazu, dass alle CSS-Dateien im Fuß der Seite geladen werden.

Alternativen zu Inline CSS

Wem Inline CSS zu unsauber ist, kann auch auf andere Möglichkeiten zugreifen.
Eine über Javascript gesteuerte Methode ermöglicht es, CSS asynchron zu laden, wie es bei Javascript-Dateien bereits bekannt ist. Dafür kann die Bibliothek loadCSS von der Filament Group genutzt werden.
Eine weitere Option ist es CSS-Dateien parallel zu laden, indem diese von einem Content Delivery Network zur Verfügung gestellt werden. Dadurch wird eine parallele Verbindung zu einem anderen Server aufgebaut, während die eigentliche Verbindung zu Server der Website für das Rendering genutzt werden kann.

Die Zukunft von Inline CSS

Die Problematik beim Laden von Dateien beim Seitenaufbau ist, dass bei HTTP1.1 nur eine begrenzte Anzahl von Dateien in einem Roundtrip (Anfrage an Server, Antwort von Server) übertragen werden können. Dieser Roundtrip erfordert Zeit, die das Rendern der Seite bremst. Diese Problematik wird deshalb im neuen Standard HTTP2 aufgegriffen und gelöst. Alle Anfragen an den Server werden gebündelt und die Dateien in einem Paket zurückgeschickt. Dies beschleunigt die Datenübertragung entscheidend und macht die Einbindung von Inline CSS in Zukunft unnötig.