Kritisches CSS einrichten

Was das Modul tut — und was es nicht tut

Kakapo ruft je Seitenvorlage eine echte Beispielseite deiner Site über HTTP ab (nur im Adminbereich oder per Cron, nie im Seitenaufbau eines Besuchers), liest die dort verlinkten lokalen Stylesheets direkt von der Festplatte und prüft jede einzelne Regel mit DOMXPath gegen das Dokument. Daraus entstehen zwei Ergebnisse: das kritische CSS, das inline in den Kopf gestellt wird, und die Liste der Regeln, die auf dieser Vorlage kein einziges Element getroffen haben.

Gerendert wird dabei nichts. Es gibt keinen Browser, keinen Viewport und keine Scrollposition. „Oben sichtbar" ist eine Näherung nach einer offengelegten Regel: alle Elemente unterhalb von body werden durchnummeriert, die ersten 30 Prozent (Voreinstellung, zwischen 5 und 90 einstellbar) gelten als oben, dazu alles innerhalb der eingetragenen Landmarken. Immer aufgenommen werden html, body, :root und @font-face sowie @keyframes, die eine kritische Regel per animation benennt. Regeln, die nur über Zustände greifen (:hover, :focus, :active), bleiben draußen, @media print ebenfalls. Wo das Verfahren an seine Grenze kommt, rundet es nach oben: die Regel gilt als getroffen. Ein paar Kilobyte zu viel kosten weniger als eine fehlende Regel und Flackern.

Voraussetzungen prüfen, bevor du analysierst

Zwei Dinge müssen stimmen. Erstens die PHP-Erweiterung dom/libxml — das Modul prüft sie nicht über class_exists(), sondern baut ein Miniatur-Dokument und fragt es wirklich ab. Der Grund: manche Hoster setzen disable_classes=DOMDocument, dann meldet class_exists() weiterhin „ja", das new schlägt aber fehl. Fehlt die Erweiterung, sind „Analysieren" und „Täglich auffrischen" gesperrt und der Grund steht daneben.

Zweitens der Loopback: die Site muss sich selbst über HTTP erreichen. Dafür gibt es den Knopf „Loopback prüfen" im Bereich Voraussetzungen; er merkt sich HTTP-Code, Antwortgröße und Dauer. Schlägt er fehl, scheitert jeder Analyse-Lauf — typische Ursachen sind eine Firewall vor der Site, ein Basic-Auth-Schutz auf der Staging-Umgebung oder ein Hostname, der intern nicht auflöst.

Was die Analyse nicht lesen kann, wird auch nicht verzögert: Stylesheets von fremden Hosts, von einem CDN oder aus Google Fonts bleiben unverändert render-blockierend. Das ist der langsame, aber sichere Weg.

Vorlage für Vorlage vorgehen

Es gibt sieben Vorlagen: Startseite, Blog-Seite, Einzelner Beitrag, Statische Seite, Archiv, Suchergebnisse und Fehlerseite 404. Jede wird einzeln analysiert und einzeln freigegeben. Zeigt deine Startseite die Beitragsliste, ist „Blog-Seite" nicht anwendbar — der Schalter bleibt gesperrt, weil er ohne Wirkung wäre. Gibt es keinen veröffentlichten Beitrag oder keine Seite, fehlt die Beispielseite und die Vorlage bleibt ebenfalls gesperrt.

Der empfohlene Weg: erst „Alle analysieren" oder einzeln analysieren. Danach öffnest du zu einer Vorlage „Vorschau" und „ohne" in zwei Tabs — das ist dieselbe echte Seite einmal mit und einmal ohne Behandlung, sichtbar nur für angemeldete Verwalter und nur mit gültigem Einmal-Schlüssel in der Adresse. Der Hauptschalter muss dafür nicht an sein. Flackern beim Aufbau siehst du am zuverlässigsten im eigenen Tab mit gedrosselter Verbindung, nicht im eingebetteten Rahmen.

Erst wenn der Vergleich sauber aussieht, gibst du die Vorlage frei und schaltest den Hauptschalter an. Er beginnt im Testbetrieb: dort bekommen nur angemeldete Verwalter die Behandlung zu sehen, für alle anderen bleibt die Seite unverändert. Auf „scharf" stellst du erst, wenn du mehrere Vorlagen durchgesehen hast.

Die vier Bremsen und die Ausnahmelisten

„Analysierte Stylesheets verzögert laden" ist die eigentliche Zeitersparnis. Aus bedeutet: das kritische CSS kommt zusätzlich inline dazu, sonst bleibt alles wie es war — risikolos, aber ohne Gewinn. An bedeutet: die ausgewerteten Stylesheets laden per media="print" plus onload-Rücksetzer, mit einem noscript-Duplikat für Besucher ohne JavaScript. Verzögert wird ausschließlich, was auch wirklich gelesen wurde, und nur, wenn Handle und Dateiadresse noch zu dem passen, was analysiert wurde.

„Bei veränderten Quelldateien aussetzen" merkt sich zu jeder ausgewerteten Datei Änderungszeit und Größe sowie das aktive Theme. Ändert sich etwas, wird gar nicht behandelt statt mit möglicherweise falschem kritischem CSS — im Quelltext steht dann eine Notiz mit dem Grund.

Drei Textfelder sind der Notausgang. Ausschluss-URLs: eine Zeile je Pfad, „*" als Platzhalter, diese Seiten werden nie behandelt (typisch /checkout*, /mein-konto*). Stylesheets nie verzögern: ein WordPress-Handle je Zeile, voreingestellt admin-bar und dashicons. Landmarken: ein Selektor je Zeile, alles darin gilt als oben — voreingestellt sind header, [role="banner"], .site-header, #masthead, nav, .main-navigation, .site-branding, .hero und h1. Nicht auswertbare Zeilen werden abgelehnt statt stillschweigend gespeichert.

Eine Änderung am Anteil „oben" oder an den Landmarken wirkt erst nach einem neuen Analyse-Lauf. Alles andere verwirft den Seiten-Cache sofort, weil dort fertiges HTML mit dem alten Zustand liegt.

Wenn etwas schiefgeht

„Zeitbudget aufgebraucht": der Lauf hat 25 Sekunden oder das PHP-Zeitlimit erreicht. Der Bericht ist gespeichert, das kritische CSS bewusst nicht — unvollständiges kritisches CSS würde flackern. Die Meldung nennt die Datei, in der Schluss war. Analysiere erneut oder nimm ein sehr großes Stylesheet über die Ausnahmeliste heraus.

„Antwortete mit HTTP …": die Beispielseite lieferte nicht den erwarteten Code (200, bei der Fehlerseite 404). Gespeichert wird nichts. Prüfe, ob die Seite im Browser erreichbar ist und ob ein Schutz davorliegt.

Eine Vorlage steht auf „veraltet": eine ausgewertete CSS-Datei hat sich geändert oder das Theme wurde gewechselt. Neu analysieren. Steht dort „anderer Anteil", wurde die Vorlage mit einem anderen Prozentwert erstellt als jetzt eingestellt ist — ebenfalls neu analysieren.

Damit das nicht Handarbeit bleibt, gibt es „Täglich prüfen und auffrischen". Der Cron-Lauf analysiert nur Vorlagen, die bereits freigegeben und veraltet sind; er schaltet nie etwas ein und legt keine Analyse für eine nicht freigegebene Vorlage an. Sein letztes Ergebnis steht als Notiz im Bereich Sicherheitsgurt.

Bleibt eine Seite trotzdem unruhig, hilft der Blick in den Quelltext: dort steht ein Kommentar mit der behandelten Vorlage und dem Zustand (Vorschau, Testbetrieb, scharf) oder der Grund, warum bewusst nicht behandelt wurde.