Caching: Was ist was?

Geschwindigkeit ist wichtig, und Geschwindigkeit erreicht man in CMS wie WordPress über Caching- so die landläufige Meinung. Aber was ist das eigentlich, dieses Caching? Mittlerweile werden mit dem Begriff eine ganze Reihe an Techniken bezeichnet, die sich zum Teil deutlich unterscheiden. Und nicht für alles braucht man ein Plugin.

Was bedeutet Caching?

Caching ist an sich erst einmal das Zwischenspeichern von Informationen, die mehrfach genutzt werden. Dadurch spart man Ressourcen: Dateien müssen nicht nochmal übertragen werden, Daten müssen nicht nochmal generiert werden, … etc – und das spart am Ende Serverressourcen und Zeit. Caching kann an verschiedenen Stellen stattfinden, an verschiedenen Punkten auf dem Server und natürlich im Client, also im Browser. Mittlerweile werden auch Mechanismen in Caching-Plugins angeboten, die eigentlich kein Caching sind, auf diese wird am Ende auch kurz eingegangen.

Seitenausgabe-Caching

Dies ist die schärfste Waffe, die man als Admin hat, um ein WordPress performant wirken zu lassen, und meistens ist es auch das, was unter „Caching“ erst einmal verstanden wird. Um Seitenausgabe-Caching zu verstehen, schauen wir uns mal an, wie ein Abruf einer Seite funktioniert:

Wenn nun der generierte Inhalt für alle Menschen gleich ist, dann wäre es ja überflüssige Arbeit, die komplette Seite jedes mal neu zu generieren. Man speichert also die fertig zusammengestellte Seite zwischen – in einem Seitenausgabe-Cache:

Es gibt drei verschiedene Varianten, den Cache auszuliefern: über PHP (so arbeiten die meisten Caching-Plugins), über die htaccess (so arbeitet WP SuperCache, wenn man es richtig einstellt) und über Serverdienste wie Nginx FCGI Caching oder Varnish. PHP ist am langsamsten, Serverdienste am schnellsten.

Natürlich muss der Cache erst einmal befüllt werden. Dies geschieht entweder durch einen Nutzer, der das erste Mal auf die Seite kommt, oder aber durch ein sogenanntes Prefilling. Überlässt man dies dem Nutzer, so haben einige wenige Nutzer eine eher lange Ladezeit, weil sie den Cache füllen, alle danach kommenden Nutzer bekommen dann die schnelle, gecachte Ausgabe.

Wenn man die Seite aktualisiert hat, muss ein Cache gepurged werden – schließlich möchte man ja, dann zB. der neu geschrieben Artikel dann auf der Startseite auch erscheint und nicht weiterhin die alte Startseite ausgeliefert wird. Die meisten Caching-Plugins haben so einen Cache-Purging-Mechanismus mit drin, lediglich bei den besonders schnellen Serverdienst-Cachings über Nginx FCGI Cachin oder Varnish muss man sich darüber intensivere Gedanken machen. Allerdings funktioniert das Cache-Purging der Plugins nur, wenn man etwas an einer Seite, einem Beitrag oder Ähnlichem ändert – wenn man dagegen etwas globales z.B. an den Theme-Einstellungen ändert, dann muss man manuell den Cache purgen. Die allermeisten Caching-Plugins bieten das in ihren Einstellungen an.

Seitenausgabe-Caching ist natürlich nur dann machbar, wenn viele Nutzer dieselbe Ausgabe bekommen. Kurzum: nach einem Login ist ein Ausgabe-Caching typischerweise nicht mehr aktiv, da dann die ausgelieferte Website ja um Informationen angereichert wird, die nur den eingeloggten Nutzer betreffen. Erkennbar sind solche nutzerspezifischen Seiten-Auslieferungen an Cookies. Mit anderen Worten: wird ein Cookie gesetzt, ist das Caching gebrochen. Ob Cookies gesetzt werden, kann man gut mit Pingdom nachvollziehen:

Die von WPML gespiegelten Cookies brechen das Seitenausgabe-Caching.

Das gezeigte Beispiel ist übrigens ein sehr Schönes, weil es zeigt, wie durch unsaubere Programmierung Caching gebrochen wird. WPML setzt die Sprache nicht nur über die URL, sondern auch über ein Cookie, woraufhin das Caching-System denkt, dass es sich hierbei um eine nutzerangepasste Seite handelt, und sich selbst abschaltet. Dabei tut das schlicht nicht not. Manch ein Caching-Plugin korrigiert diese Programmierfehler dann, indem es die WPML Cookies ignoriert – aber am Ende ist das ein dreckiger, nachträglicher Bugfix für eine unsaubere Programmierung der WPML-Autoren.

WooCommerce dagegen ist übrigens ein schönes Beispiel, wie man dynamische Inhalte wie den nur für einen Nutzer geltenden Warenkorb mit Seitenausgabe-Caching kombinieren kann. Die Produkt-Seiten zum Beispiel sehen für alle Menschen in weiten Teilen identisch aus, und so werden all diese Teile gecached. Um die dynamischen Inhalte wie den Warenkorb in die Seite zu bekommen, werden diese dynamisch nachgeladen. Erst, wenn es zum Checkout kommt, deaktiviert WooCommerce das Seitenausgabe-Caching.

WordPress Plugin-Empfehlung: WP SuperCache und Caching via htaccess, Nginx FCGI-Caching mit Nginx Helper beim Root-Server.

Object-Caching

Object-Caching ist ein Caching-Mechanismus innerhalb von PHP. Er basiert darauf, dass einige Informationsfragmente identisch bleiben und nicht bei jeder Anfrage neu generiert werden müssen. Typische Beispiele sind die Theme-Optionen oder die Nutzer-Informationen: diese bleiben üblicherweise über einen längeren Zeitraum identisch und können so zwischengespeichert werden.

Als Zwischenspeicher kann man auf verschiedene Systeme zurückgreifen. Für gut betreute Managed Server ist Redis oder Memcached sicherlich eine Option, aber auch der interne Object Cache von PHP (der dann wiederum Dateien oder auch den Arbeitsspeicher als Speicherort nutzt) ist eine gute Option.

Object Caching ist dann eine gute Wahl, wenn man Features hat, die vom Seitenausgabe-Caching nicht weggecached werden können. Dies ist z.B. bei Shops der Fall, ebenso wie bei jeder Website mit Login. Aber Achtung: schlecht programmierte Plugins, die z.B. bei jedem Aufruf den Cache leeren, können einen Object Cache die Seite auch verlangsamen lassen. Wieder einmal ist die Code-Qualität wichtig.

WordPress Plugin-Empfehlungen: Redis Cache beim Managed- / Root-Server.

Datenbank-Query-Caching

Datenbank-Query-Caching setzt ein wenig vor einem Object-Caching an und speichert komplizierte Anfragen an die Datenbank zwischen. Am Ende ist dies aber aus zwei Gründen wenig sinnvoll:

Ein Datenbankquery sagt erst einmal nichts über die Struktur der Daten aus. Um Daten effizient zu speichern, müssen also die PHP-Objekte mit ihrer konkreten Datenstruktur gecached werden, nicht die Datenbank-Queries. Datenbank-Query-Caching in einem Caching-Plugin ist letztlich also eher poor-mans-Object-Caching.
Die richtige Stelle für ein Datenbank-Query-Caching wäre die Datenbank selbst. Dort kann ein Systemadministrator einstellen, wie viel Arbeitsspeicher dem Caching zur Verfügung steht. Dies geschieht erheblich intelligenter und schneller, als es ein Caching-Plugin je machen könnte. Dies kann von Webspace-Nutzern aber nicht geändert werden, da falsche Einstellungen dort schnell zu erheblichem RAM-Verbrauch und so zu Serverabstürzen führen.

Insgesamt kann man von Datenbank-Query-Caching in einem Plugin also nur abraten.

Browser-Caching

Wenn man mehr als eine Unterseite auf einer Website aufruft, werden oft dieselben Dateien wieder und wieder verwendet. Ein Logo im Seitenkopf ist dafür ein gutes Beispiel, ebenso aber auch CSS- und JS-Dateien. Es macht also Sinn, diese Dateien im Browser zwischenzuspeichern und nicht jedes mal neu zu laden. Dies geschieht durch das Browser-Caching.

Technisch funktioniert das so, dass mit dem immer mitgesendeten HTTP Header mitgeteilt wird, wie lange die Datei gültig bleibt. Diese Gültigkeit setzt man für statische Dateien sehr, sehr lange. Dies geschieht über die Header-Felder Expires oder Cache-Control max-age. Die Steuerung darüber ist verhältnismäßig simpel: der Browser fragt erst dann die Datei wieder an, wenn der angegebene Zeitpunkt vorbei ist.

Alternativ arbeitet man mit einem E-Tag bzw. Last-Modified, welches sich ändert, sobald sich die dazugehörige Datei ändert. Wenn der Browser dann eine Datei bei sich lokal im Cache hat, sendet er einfach das dazu passende E-Tag mit. Der Webserver schaut dann, ob das E-Tag der auf dem Server befindlichen Datei identisch ist. Wenn das der Fall ist, sendet er statt der gesamte Datei nur den Code 304 zurück, der sagt, dass sich die Datei nicht geändert hat. Ein Status-Code ist logischerweise deutlich kleiner als eine ganze CSS- oder Bild-Datei, so dass eine Menge Abfragen eingespart wird. E-Tags haben den Vorteil, dass sie Änderungen auf Serverseite mitbekommen, dies tut eine pauschale sehr lange Caching-Zeit nicht.

Browser-Caching in allen Varianten (und damit doppelten Informationen).

Manchmal möchte man aber den Browser-Cache brechen, z.B., wenn man eine Plugin-Update macht und so neue CSS- und JS-Dateien hineinkommen. Daher hat WordPress die Versionierung über ?ver=1.2.3 eingeführt (auch genannt: Query Strings, schön sichtbar an der style.css oben). Ändert man die Versionsnummer, lädt der Browser die Datei neu und bekommt so von den Änderungen etwas mit.

Es ist im Übrigen gefährlich, der Empfehlung von manchen Analyse-Tools zu folgen, und die Query-Strings zu entfernen. Dann bekommt der Browser nämlich nie mit, dass es eine Änderung in der JavaScript-Datei gab. JavaScript und HTML passen dann ab und an nicht mehr zusammen, und die Website funktioniert nur noch fehlerhaft. Das sollte man vermeiden und so dringend die Query-Strings beibehalten.

Das Browser-Caching wird komplett in der htaccess oder der vHost-Konfiguration eingestellt, da die HTTP-Header vom Webserver (Apache, Nginx, …) erstellt werden. Die meisten Caching-Plugins bieten an, die htaccess entsprechend zu aktualisieren. Wirklich notwendig ist das allerdings nicht, man kann die entsprechenden Zeilen auch einfach per Hand in die htaccess hineinkopieren (dann versteht man auch besser, was da passiert).

Plugin-Empfehlungen: keine, Realisierung via htaccess.