Caching verstehen: Vier Ebenen, ein typischer Fehler pro Ebene

Caching ist der wirksamste Einzelhebel für die Ladezeit und die häufigste Ursache für „warum sehe ich meine Änderung nicht“. Beides hat denselben Grund: Es arbeiten mehrere Ebenen gleichzeitig, und niemand weiß genau, welche.

Die vier Ebenen

Dazu kommt auf PHP-Ebene der OPcache, der kompilierten Code vorhält. Er ist beim Hoster eingerichtet oder nicht und braucht im Alltag keine Aufmerksamkeit – außer nach einem Deployment, wenn plötzlich alte Codefassungen laufen.

Die richtigen Header

Für den Browser-Cache gibt es eine klare Empfehlung, und sie unterscheidet zwei Fälle.

Dateien mit Versionskennung im Namen

Wenn der Dateiname einen Hash oder eine Versionsnummer trägt – style.a3f91c.css – ändert sich bei einer Änderung der Name. Dann kann die Datei sehr lange zwischengespeichert werden: Empfohlen wird Cache-Control: max-age=31536000, also ein Jahr. Der Browser verwendet den Wert aus dem Cache unmittelbar, ohne überhaupt eine Netzwerkanfrage zu stellen; optional lässt sich immutable ergänzen.

HTML und Adressen ohne Versionskennung

Hier gilt das Gegenteil: Empfohlen wird Cache-Control: no-cache. Das weist den Browser an, vor jeder Verwendung der zwischengespeicherten Fassung beim Server nachzufragen.

Der Name ist irreführend: no-cache bedeutet nicht „nicht speichern“, sondern „vor der Verwendung rückfragen“. Und diese Rückfrage ist billig, wenn ETag oder Last-Modified gesetzt sind – der Server antwortet dann mit 304 statt den vollen Inhalt erneut zu senden.

Das Muster dahinter: Lange Gültigkeit für alles, was sich bei einer Änderung umbenennt. Rückfrage für alles, was unter derselben Adresse neuen Inhalt haben kann.

Was nie gecacht werden darf

• Der Administrationsbereich
• Seiten für angemeldete Benutzer
• Warenkorb, Kasse, Kundenkonto
• Formularseiten mit Einmal-Token
• Alles, was pro Person unterschiedlich aussieht

Der vierte Punkt ist der, der stillschweigend Anfragen kostet: Wenn eine Formularseite aus dem Cache kommt, ist das Sicherheits-Token darin abgelaufen, und das Absenden scheitert. Für den Besucher sieht das aus wie ein defektes Formular – siehe Formulare, die ankommen.

Der dritte ist der, der Schaden anrichtet: Ein aus dem Cache ausgelieferter Warenkorb gehört jemand anderem.

Die Reihenfolge beim Leeren

1. Eigenen Browser – oder einfacher: ein privates Fenster zur Kontrolle öffnen.
2. Seiten-Cache auf dem Server.
3. Objekt-Cache, wenn vorhanden.
4. CDN, falls eines vorgeschaltet ist.

Der häufigste Fall von „die Änderung ist nicht da“: Schritt zwei erledigt, Schritt vier vergessen. Ein vorgeschaltetes Netzwerk liefert dann so lange die alte Fassung, bis dessen eigene Gültigkeitsdauer abläuft.

Ob tatsächlich aus dem Cache ausgeliefert wird, zeigt der Blick in die Antwort-Header – und welche Zugriffe überhaupt bis zum Server durchkommen, die Logfile-Analyse. Wenn dort nach der Einrichtung eines CDN plötzlich fast nichts mehr ankommt, funktioniert es.

Was Caching nicht löst

Es verkürzt die Zeit bis zur ersten Antwort. Es verkürzt nicht die Zeit bis zur Nutzbarkeit, wenn danach vier Megabyte JavaScript und sechs Schriftschnitte geladen werden.

Das ist der Grund, warum Caching allein die Core Web Vitals oft nicht in den grünen Bereich bringt. Die Reihenfolge, die wirkt: zuerst weglassen, was nicht gebraucht wird, dann optimieren, was bleibt, dann cachen. Wer in umgekehrter Reihenfolge arbeitet, cacht eine überladene Seite schneller aus.

Die vorgeschalteten Einwilligungsdialoge sind dabei ein eigener Fall: Sie müssen vor allem anderen laden und lassen sich nicht wegcachen – dazu Cookie-Banner. Die vollständige Reihenfolge für WordPress steht in WordPress-Performance, die Frage, was der Anbieter davon ohnehin mitbringt, in Hosting für kleine Unternehmen.