Was ist Caching? Website-Cache einfach verständlich erklärt

Caching bedeutet, ein bereits vorhandenes Ergebnis vorübergehend zu speichern, damit es beim nächsten Mal nicht erneut aufwendig erzeugt oder übertragen werden muss.

Das klingt unspektakulär. Für die Geschwindigkeit moderner Websites ist Caching jedoch eines der wirkungsvollsten Prinzipien überhaupt.

Eine WordPress-Seite kann bei jedem Aufruf PHP-Code ausführen, Plugins laden, eine Datenbank abfragen, Templates zusammensetzen und daraus HTML erzeugen. Wenn sich das Ergebnis zwischen zwei Besuchern nicht verändert, wäre es ineffizient, dieselbe Arbeit jedes Mal komplett zu wiederholen.

Ein Cache merkt sich deshalb das Ergebnis.

Beim nächsten Aufruf kann es unmittelbar wiederverwendet werden.

Aus einer komplizierten Berechnung wird im Idealfall ein einfacher Zugriff auf bereits vorbereitete Daten.

Caching bedeutet Wiederverwenden statt Neuberechnen

Das Grundprinzip lässt sich an einem einfachen Beispiel erklären.

Ohne Cache:

Besucher
↓
Webserver
↓
PHP
↓
WordPress
↓
Plugins
↓
Datenbank
↓
Theme
↓
HTML erzeugen
↓
Besucher

Mit einem funktionierenden Seiten-Cache kann der Ablauf deutlich kürzer werden:

Besucher
↓
Cache
↓
fertiges HTML
↓
Besucher

Die Website muss nicht jedes Mal komplett neu zusammengesetzt werden.

Gerade bei Artikeln, Informationsseiten und anderen weitgehend statischen Inhalten kann das enorme Mengen an Serverarbeit einsparen.

Ein Cache ist keine zweite Website

Ein Cache enthält normalerweise nur temporär gespeicherte Ergebnisse.

Die eigentlichen Inhalte bleiben weiterhin in ihrem ursprünglichen System.

Bei WordPress kann ein Artikel beispielsweise weiterhin in der Datenbank gespeichert sein.

Der Cache enthält lediglich eine bereits erzeugte Darstellung dieses Artikels.

Wird der Inhalt geändert, muss der Cache entsprechend aktualisiert oder verworfen werden.

Danach wird beim nächsten Aufruf eine neue Fassung erzeugt.

Diese Unterscheidung ist wichtig:

Originaldaten sind die Quelle.

Der Cache ist eine beschleunigende Zwischenablage.

Warum Websites ohne Cache unnötig viel Arbeit machen können

Nehmen wir einen Ratgeberartikel.

Er wurde gestern veröffentlicht und seitdem nicht verändert.

Heute lesen ihn 10.000 Menschen.

Ohne Seiten-Caching könnte WordPress theoretisch 10.000-mal ähnliche Abläufe durchführen:

Artikel aus der Datenbank laden,

Website-Einstellungen lesen,

Plugins ausführen,

Theme verarbeiten,

HTML erzeugen.

Das Ergebnis ist für fast alle Besucher identisch.

Ein Cache kann die Seite einmal erzeugen und danach häufig direkt ausliefern.

Dadurch sinken:

CPU-Belastung,

PHP-Ausführung,

Datenbanklast

und häufig auch die Antwortzeit.

Caching ist damit nicht nur eine Geschwindigkeitsoptimierung. Es kann auch die Anzahl von Besuchern erhöhen, die ein Server mit denselben Ressourcen bewältigen kann.

Es gibt nicht den einen Website-Cache

Wenn jemand sagt:

Lösch den Cache.

fehlt eigentlich eine wichtige Information.

Welchen Cache?

Bei einem einzigen Webseitenaufruf können mehrere Cache-Ebenen beteiligt sein.

Zum Beispiel:

Browser-Cache
↓
CDN-Cache
↓
Reverse-Proxy-/Server-Cache
↓
Page Cache
↓
Object Cache
↓
WordPress
↓
Datenbank

Nicht jede Website verwendet alle Ebenen.

Aber mehrere davon können gleichzeitig aktiv sein.

Deshalb kann das Löschen eines WordPress-Caches wirkungslos bleiben, wenn der Browser weiterhin eine alte CSS-Datei gespeichert hat.

Oder der Browser-Cache wird geleert, während ein CDN weiterhin eine alte HTML-Version ausliefert.

Caching wird wesentlich verständlicher, sobald diese Ebenen getrennt betrachtet werden.

Was ist der Browser-Cache?

Der Browser kann Dateien einer Website lokal auf dem Gerät des Besuchers speichern.

Dazu gehören häufig:

Bilder,

CSS-Dateien,

JavaScript,

Schriftarten

und andere statische Ressourcen.

Besucht der Nutzer später eine weitere Seite derselben Website, müssen diese Dateien nicht unbedingt erneut vollständig vom Server übertragen werden.

Das Logo ist beispielsweise auf allen Artikelseiten identisch.

Es wäre unnötig, dieselbe Datei bei jedem Klick erneut herunterzuladen.

Der Browser kann seine lokale Kopie verwenden.

Browser-Caching spart vor allem Netzwerkverkehr

Angenommen, eine Website verwendet:

ein 80-KB-Logo,

200 KB CSS,

300 KB JavaScript,

mehrere Schriftdateien.

Beim ersten Besuch müssen diese Daten möglicherweise übertragen werden.

Beim nächsten Seitenaufruf können viele davon bereits lokal vorhanden sein.

Dann müssen nur noch neue oder veränderte Ressourcen geladen werden.

Dadurch können insbesondere wiederkehrende Besucher deutlich profitieren.

Browser-Caching reduziert also nicht unbedingt die serverseitige Erzeugung des HTML-Dokuments.

Es reduziert vor allem die erneute Übertragung bereits bekannter Ressourcen.

Woher weiß der Browser, wie lange er etwas speichern darf?

Server können dem Browser über HTTP-Header mitteilen, wie Dateien behandelt werden sollen.

Ein wichtiger Mechanismus ist Cache-Control.

Damit kann beispielsweise sinngemäß festgelegt werden:

Diese Datei darf für einen bestimmten Zeitraum verwendet werden, ohne erneut angefordert werden zu müssen.

Für unveränderliche Bilder, Skripte oder Stylesheets können relativ lange Cache-Zeiten sinnvoll sein.

Bei häufig wechselnden Daten müssen kürzere Regeln verwendet werden.

Die passende Einstellung hängt deshalb von der Art des Inhalts ab.

Lange Cache-Zeiten erzeugen ein neues Problem

Angenommen, der Browser darf eine CSS-Datei ein Jahr lang speichern.

Heute wird das Design geändert.

Die Datei heißt weiterhin:

style.css

Der Browser eines Stammlesers besitzt aber noch die alte Version.

Dann könnte er weiterhin das alte Design verwenden.

Genau dafür gibt es eine verbreitete Lösung:

Versionierte Dateinamen beziehungsweise URLs.

Statt:

style.css

wird beispielsweise verwendet:

style.css?ver=2.4

oder ein neuer Dateiname.

Für den Browser handelt es sich dadurch um eine neue Ressource.

Die alte Version kann lange gecacht werden, ohne spätere Aktualisierungen zu blockieren.

Was bedeutet Cache Busting?

Dieses Prinzip wird häufig als Cache Busting bezeichnet.

Die URL einer Ressource verändert sich, sobald sich deren Inhalt verändert.

Dadurch kann eine sehr lange Cache-Zeit genutzt werden.

Der Browser erkennt trotzdem sofort:

Diese Datei habe ich noch nicht.

Gerade bei CSS und JavaScript ist diese Methode sehr nützlich.

WordPress und viele moderne Build-Systeme verwenden entsprechende Versionierungsmechanismen.

Was ist ein Page Cache?

Ein Page Cache speichert das fertig erzeugte Ergebnis einer Webseite.

Bei WordPress ist das häufig fertiges HTML.

Ohne Page Cache muss WordPress die Seite dynamisch erzeugen.

Mit Page Cache kann das bereits vorbereitete HTML unmittelbar ausgeliefert werden.

Das ist bei vielen WordPress-Websites eine der wirkungsvollsten Optimierungen überhaupt.

Warum Page Caching bei WordPress so stark wirkt

WordPress ist ein dynamisches Content-Management-System.

Ein Seitenaufruf kann zahlreiche Komponenten aktivieren.

Vereinfacht:

Anfrage
↓
PHP
↓
WordPress Core
↓
Plugins
↓
Datenbank
↓
Theme
↓
HTML

Ein Page Cache setzt wesentlich früher an:

Anfrage
↓
fertige HTML-Kopie gefunden
↓
ausliefern

WordPress muss für diesen Aufruf möglicherweise gar nicht vollständig gestartet werden.

Das spart besonders viel Arbeit.

Nicht jede WordPress-Seite darf gleich gecacht werden

Ein normaler Wissensartikel ist für nahezu jeden Besucher identisch.

Er eignet sich hervorragend für Page Caching.

Andere Seiten sind individuell.

Beispielsweise:

Warenkorb,

Checkout,

Benutzerkonto,

Administrationsbereich,

personalisierte Inhalte.

Wenn ein Cache dort versehentlich die Seite von Benutzer A an Benutzer B ausliefert, entsteht ein erhebliches Problem.

Caching muss deshalb wissen, welche Inhalte gemeinsam verwendet werden dürfen und welche nicht.

Gute Cache-Lösungen schließen dynamische Bereiche entsprechend aus.

Eingeloggte Benutzer werden häufig anders behandelt

WordPress zeigt eingeloggten Benutzern teilweise andere Inhalte als anonymen Besuchern.

Eine Administrationsleiste ist ein einfaches Beispiel.

Auch Plugins können Inhalte abhängig vom Benutzer verändern.

Deshalb werden eingeloggte Nutzer bei vielen Page-Cache-Systemen nicht oder anders gecacht.

Für eine klassische Informationsseite ist das meist kein Problem.

Der Großteil der Besucher ist ohnehin nicht eingeloggt und kann vollständig vom Cache profitieren.

Was ist Cache Invalidation?

Eine der schwierigsten Fragen bei Caching lautet:

Wann ist ein gespeichertes Ergebnis nicht mehr gültig?

Angenommen, ein Artikel befindet sich im Cache.

Nun wird der Text geändert.

Die alte Cache-Version darf nicht dauerhaft weiter ausgeliefert werden.

Sie muss gelöscht beziehungsweise als ungültig markiert werden.

Dieser Vorgang wird als Cache Invalidation bezeichnet.

In der Praxis bedeutet das beispielsweise:

Artikel speichern

→ Cache dieses Artikels löschen

→ neue Fassung beim nächsten Aufruf erzeugen.

Eine Änderung kann mehrere Cache-Seiten betreffen

Bei WordPress wird es schnell komplexer.

Du änderst einen Beitrag.

Dadurch verändert sich nicht nur der Beitrag selbst.

Möglicherweise erscheint er auch auf:

der Startseite,

einer Kategorie,

einer Schlagwortseite,

einer Autorenseite,

einer „Neueste Beiträge“-Box.

Dann müssen möglicherweise mehrere Cache-Einträge aktualisiert werden.

Gute WordPress-Cache-Systeme berücksichtigen solche Beziehungen automatisch.

Das ist einer der Gründe, warum Cache-Invalidierung komplizierter ist als das reine Speichern fertiger Seiten.

Was bedeutet Cache Purge?

Purge bedeutet, gespeicherte Cache-Inhalte gezielt zu entfernen.

Das kann nur eine einzelne URL betreffen:

/wissen/caching/

oder sämtliche gecachten Seiten.

Ein kompletter Purge ist einfach, aber grob.

Danach müssen alle Seiten beim nächsten Aufruf wieder neu erzeugt werden.

Bei kleinen Websites ist das meist unproblematisch.

Bei sehr großen Systemen kann gezieltes Invalidieren effizienter sein.

Was bedeutet TTL beim Cache?

TTL steht für Time to Live.

Der Begriff begegnet uns auch bei DNS.

Bei Caches beschreibt er vereinfacht, wie lange ein gespeichertes Ergebnis als gültig betrachtet werden darf.

Beispielsweise:

Cache-Eintrag
↓
TTL 1 Stunde
↓
nach 1 Stunde neu prüfen oder erzeugen

Eine sehr kurze TTL sorgt für aktuelle Inhalte, reduziert aber den Nutzen des Caches.

Eine sehr lange TTL maximiert die Wiederverwendung, benötigt dafür eine zuverlässige Invalidierung bei Änderungen.

Je besser die Invalidierung, desto länger kann gecacht werden

Ein häufiges Missverständnis lautet:

Aktuelle Websites brauchen immer kurze Cache-Zeiten.

Nicht unbedingt.

Wenn das System zuverlässig erkennt, wann sich ein Inhalt verändert, kann eine Seite lange gecacht werden.

Der Cache wird dann nicht nach einer zufälligen Zeit ungültig, sondern genau dann, wenn tatsächlich eine Änderung erfolgt.

Das ist effizienter.

Die perfekte Cache-Strategie besteht deshalb nicht einfach aus möglichst langen oder möglichst kurzen Zeiten.

Sie besteht aus einer passenden Kombination von:

Speicherung,

TTL

und Invalidierung.

Was ist ein Server-Cache?

Der Begriff Server-Cache wird relativ unscharf verwendet.

Gemeint ist häufig eine Zwischenspeicherung auf der Serverseite, bevor WordPress beziehungsweise die eigentliche Anwendung vollständig arbeiten muss.

Ein Webserver oder ein vorgeschalteter Reverse Proxy kann fertige Antworten speichern und direkt ausliefern.

Dadurch kann der Cache noch früher im Request-Prozess greifen als ein klassisches WordPress-Plugin.

Das kann sehr leistungsfähig sein.

Ein Cache-Plugin und ein Server-Cache sind nicht dasselbe

Ein WordPress-Plugin arbeitet innerhalb beziehungsweise im Umfeld von WordPress.

Ein Server-Cache kann dagegen auf einer tieferen Infrastruktur-Ebene arbeiten.

Vereinfacht:

Besucher
↓
Server-Cache
↓
WordPress

Trifft der Cache, wird WordPress gar nicht benötigt.

Das kann Performance und Skalierbarkeit deutlich verbessern.

Viele Managed-WordPress-Hoster setzen deshalb eigene Caching-Systeme auf Serverebene ein.

Zwei Page-Caches gleichzeitig können unnötig sein

Angenommen, der Hoster besitzt bereits ein vollständiges serverseitiges Page Caching.

Nun wird zusätzlich ein WordPress-Plugin installiert, das ebenfalls die gesamte Seite cachen möchte.

Das kann funktionieren.

Es kann aber auch:

unnötige Doppelarbeit,

komplizierte Invalidierung,

schwer nachvollziehbare Fehler

oder widersprüchliche Einstellungen erzeugen.

Deshalb sollte vor der Installation eines Cache-Plugins geprüft werden, welche Funktionen das Hosting bereits bereitstellt.

Mehr Cache ist nicht automatisch mehr Geschwindigkeit.

Was ist ein Reverse Proxy?

Ein Reverse Proxy befindet sich vor dem eigentlichen Webserver beziehungsweise der Anwendung.

Anfragen gehen zunächst an diesen Proxy.

Er kann entscheiden:

Ist eine passende Antwort bereits gespeichert?

Wenn ja, liefert er sie direkt aus.

Wenn nein, leitet er die Anfrage an das dahinterliegende System weiter.

Vereinfacht:

Besucher
↓
Reverse Proxy
├── Cache vorhanden → direkt ausliefern
│
└── kein Cache → WordPress

Reverse Proxies können neben Caching auch weitere Aufgaben übernehmen, beispielsweise SSL-Terminierung, Lastverteilung oder Sicherheitsfunktionen.

Was ist ein Object Cache?

Ein Object Cache speichert nicht die komplette fertige Webseite.

Er speichert kleinere Daten beziehungsweise Berechnungsergebnisse, die eine Anwendung häufig benötigt.

WordPress lädt während eines Requests möglicherweise dieselben Informationen mehrfach.

Ein Object Cache kann solche Ergebnisse zwischenspeichern, damit nicht jedes Mal erneut auf die Datenbank zugegriffen werden muss.

Das spart vor allem bei dynamischen Websites Datenbankarbeit.

Page Cache und Object Cache lösen unterschiedliche Probleme

Page Cache:

ganze Seite fertig speichern

Object Cache:

häufig benötigte Daten zwischenspeichern

Bei einem normalen anonymen Besucher ist ein Page Cache häufig wesentlich wirkungsvoller, weil WordPress gar nicht erst vollständig ausgeführt werden muss.

Bei dynamischen Bereichen, die sich nicht komplett als fertige Seite cachen lassen, kann ein Object Cache dagegen besonders wertvoll sein.

Das gilt beispielsweise für komplexere Shops oder eingeloggte Anwendungen.

WordPress besitzt bereits einen Object-Cache-Mechanismus

WordPress kann während eines einzelnen Seitenaufrufs Daten im Arbeitsspeicher zwischenspeichern.

Dieser Cache verschwindet jedoch normalerweise wieder nach Ende des Requests.

Ein sogenannter persistenter Object Cache kann Ergebnisse dagegen über mehrere Requests hinweg erhalten.

Dafür werden häufig spezialisierte Systeme eingesetzt.

Ein bekanntes Beispiel ist Redis.

Was ist Redis?

Redis ist ein sehr schneller Datenspeicher, der häufig Arbeitsspeicher verwendet.

In einer WordPress-Umgebung kann Redis beispielsweise als persistenter Object Cache dienen.

Dann können bestimmte Datenbankergebnisse oder WordPress-Objekte über mehrere Seitenaufrufe hinweg zwischengespeichert werden.

Das kann besonders bei datenbankintensiven Installationen helfen.

Redis ist jedoch kein magischer Beschleuniger für jede Website.

Wenn eine Informationsseite bereits vollständig über einen Page Cache ausgeliefert wird, kann der zusätzliche Nutzen für normale Besucher gering sein.

Wann lohnt sich ein Object Cache besonders?

Ein persistenter Object Cache wird interessanter, wenn WordPress tatsächlich häufig dynamisch ausgeführt wird.

Zum Beispiel bei:

größeren Shops,

Mitgliederbereichen,

eingeloggten Benutzern,

komplexen Abfragen,

großen Datenbanken.

Bei einer kleinen Unternehmenswebsite mit zehn Seiten ist der technische Aufwand möglicherweise unnötig.

Wie bei fast jeder Performanceoptimierung sollte das Werkzeug zum Engpass passen.

Was ist PHP OPcache?

Auch PHP selbst kann cachen.

PHP-Dateien enthalten Programmcode, der für die Ausführung verarbeitet werden muss.

OPcache speichert bereits aufbereitete PHP-Bytecode-Ergebnisse im Arbeitsspeicher.

Dadurch muss derselbe PHP-Code nicht bei jedem Request erneut vollständig kompiliert werden.

Für PHP-Anwendungen wie WordPress ist OPcache heute eine wichtige grundlegende Performancekomponente.

Der Website-Betreiber bemerkt davon im Alltag meist wenig.

Die Optimierung arbeitet auf einer tieferen Ebene der Serverinfrastruktur.

OPcache ersetzt keinen Page Cache

Die beiden Verfahren sparen unterschiedliche Arbeit.

OPcache macht die Ausführung von PHP effizienter.

Page Cache kann dafür sorgen, dass PHP für viele Seitenaufrufe gar nicht erst benötigt wird.

Vereinfacht:

OPcache:
PHP schneller ausführen

Page Cache:
PHP möglichst gar nicht ausführen

Beide Mechanismen können deshalb hervorragend nebeneinander arbeiten.

Was ist ein Datenbank-Cache?

Auch Datenbanksysteme und Anwendungen verwenden verschiedene Zwischenspeichermechanismen.

Häufig benötigte Daten können beispielsweise bereits im Arbeitsspeicher verfügbar sein, statt erneut vom langsameren Datenträger gelesen zu werden.

Für normale WordPress-Betreiber muss diese Ebene nicht zwingend manuell verwaltet werden.

Sie zeigt allerdings erneut:

Caching findet an sehr vielen Stellen statt.

Deshalb lässt sich Website-Performance nicht auf ein einziges „Cache-Plugin“ reduzieren.

Was ist ein CDN-Cache?

Ein Content Delivery Network kann Dateien oder sogar komplette Webseiten an verschiedenen Standorten zwischenspeichern.

Angenommen, der Ursprungsserver steht in Europa.

Ein Besucher aus Kanada ruft eine Datei auf.

Ohne CDN muss sie möglicherweise über große geografische Entfernung übertragen werden.

Mit einem CDN kann eine bereits gespeicherte Kopie von einem näher gelegenen Standort geliefert werden.

Vereinfacht:

Ursprungsserver
│
├── CDN-Standort Europa
├── CDN-Standort Nordamerika
└── CDN-Standort Asien

Der Besucher erhält Inhalte möglichst von einem geeigneten Cache-Standort.

Ein CDN kann mehr als Bilder speichern

Historisch wurden CDNs stark mit statischen Dateien verbunden.

Zum Beispiel:

Bilder,

CSS,

JavaScript,

Videos.

Moderne CDN- und Edge-Plattformen können je nach Konfiguration auch HTML-Seiten cachen.

Dadurch kann ein Besucher eine komplette gecachte Website erhalten, ohne dass die Anfrage jedes Mal den Ursprungsserver erreicht.

Das kann besonders bei internationalem Publikum erhebliche Vorteile bringen.

CDN-Caching reduziert auch Last auf dem Ursprungsserver

Wenn 100.000 Besucher eine Datei anfordern und das CDN 99.000 dieser Anfragen aus seinem eigenen Cache beantwortet, muss der Ursprungsserver nur einen kleinen Teil davon bearbeiten.

Das spart:

Bandbreite,

Serverressourcen,

Anfragen.

Ein CDN kann deshalb sowohl Performance als auch Skalierbarkeit verbessern.

Es ist trotzdem kein notwendiger Bestandteil jeder kleinen Website.

Mehr dazu behandeln wir später in Was ist ein CDN?.

Was bedeutet Cache Hit?

Ein Cache Hit bedeutet:

Die benötigte Information befindet sich bereits im Cache.

Sie kann unmittelbar verwendet werden.

Beispiel:

Anfrage
↓
Cache prüfen
↓
vorhanden
↓
ausliefern

Je häufiger ein Cache Hit auftritt, desto stärker kann das System vom Caching profitieren.

Was bedeutet Cache Miss?

Ein Cache Miss bedeutet:

Die gesuchte Information ist nicht vorhanden oder nicht mehr gültig.

Dann muss sie vom ursprünglichen System erzeugt oder abgerufen werden.

Beispiel:

Anfrage
↓
Cache prüfen
↓
nicht vorhanden
↓
WordPress erzeugt Seite
↓
Ergebnis speichern
↓
ausliefern

Der erste Besucher nach einem Cache-Purge kann deshalb eine langsamere Antwort erhalten als die folgenden Besucher.

Das ist normal.

Was ist Cache Warming?

Nach dem vollständigen Löschen eines großen Page Caches ist zunächst keine Seite gespeichert.

Nun müsste jede URL erst bei ihrem ersten echten Besucher neu erzeugt werden.

Cache Warming versucht, wichtige Seiten bereits vorher automatisch aufzurufen.

Dadurch wird der Cache vorgefüllt.

Beispielsweise:

Cache leeren
↓
Startseite automatisch aufrufen
↓
wichtige Kategorien aufrufen
↓
Artikel aufrufen
↓
Cache wieder gefüllt

Bei kleinen Websites ist das häufig nicht notwendig.

Bei größeren Portalen kann es helfen, Lastspitzen nach einem vollständigen Purge zu vermeiden.

Warum sehe ich nach einer Änderung noch die alte Website?

Das ist eines der häufigsten Cache-Probleme.

Du änderst:

einen Text,

eine Farbe,

ein Bild,

eine CSS-Datei.

Im Browser erscheint weiterhin die alte Fassung.

Dann kann die alte Version an mehreren Stellen gespeichert sein.

Zum Beispiel:

Browser-Cache,

WordPress-Page-Cache,

Server-Cache,

CDN-Cache.

Genau deshalb ist „Cache leeren“ manchmal richtig – aber als Diagnose noch unvollständig.

Der erste Schritt ist herauszufinden, welche Ebene veraltet ist

Ein einfacher Test kann beispielsweise sein, die Seite in einem anderen Browser oder auf einem anderen Gerät aufzurufen.

Erscheint dort bereits die neue Fassung, spricht einiges für einen lokalen Browser-Cache.

Sehen alle Geräte die alte Version, kann eine serverseitige oder CDN-Ebene beteiligt sein.

Das ist noch keine vollständige technische Diagnose, zeigt aber das Prinzip:

Nicht blind alles löschen, sondern möglichst feststellen, wo die veraltete Kopie liegt.

Warum hilft ein privates Browserfenster manchmal?

Ein privates beziehungsweise Inkognito-Fenster startet mit einer weitgehend getrennten Browser-Sitzung.

Dadurch können bestimmte lokale Zustände anders sein als im normalen Fenster.

Das macht es für einfache Tests praktisch.

Es bedeutet jedoch nicht automatisch, dass sämtliche Cache-Ebenen ausgeschaltet sind.

Ein serverseitiger Cache oder CDN-Cache liefert selbstverständlich auch an ein privates Browserfenster dieselbe gespeicherte Seite.

Was ist ein Hard Reload?

Browser besitzen Möglichkeiten, eine Seite unter stärkeren Aktualisierungsbedingungen neu zu laden.

Das kann dabei helfen, lokale gecachte Ressourcen erneut anzufordern.

Auch das betrifft jedoch in erster Linie die Browserseite.

Wenn der Server selbst eine alte gecachte Version ausliefert, kann der Browser nicht wissen, dass dahinter eigentlich neuere Daten existieren.

Die Ebenen bleiben getrennt.

Cache löschen ist nicht dasselbe wie Cookies löschen

Cookies speichern andere Informationen.

Sie können beispielsweise enthalten:

Sitzungsinformationen,

Login-Zustände,

Einstellungen,

Tracking-Informationen.

Der Browser-Cache speichert dagegen typischerweise Ressourcen, die erneut verwendet werden können.

Beides liegt lokal im Browser, erfüllt aber unterschiedliche Aufgaben.

Wer Cookies löscht, kann beispielsweise ausgeloggt werden.

Das ist zum Aktualisieren einer CSS-Datei normalerweise nicht notwendig.

Caching und Cookies können miteinander interagieren

Cookies können allerdings beeinflussen, ob eine Seite gecacht werden darf.

Ein Shop erkennt möglicherweise über einen Cookie, dass ein Besucher einen gefüllten Warenkorb besitzt.

Die Seite darf dann nicht einfach mit derselben Cache-Version wie für einen anonymen Besucher ausgeliefert werden.

Cache-Systeme können deshalb bestimmte Cookies berücksichtigen.

Dadurch wird entschieden:

Diese Anfrage darf aus dem gemeinsamen Cache bedient werden.

Diese Anfrage muss dynamisch verarbeitet werden.

WooCommerce braucht spezielle Cache-Regeln

Bei einem Shop sind viele öffentliche Bereiche gut cachebar.

Eine normale Produktseite kann beispielsweise weitgehend identisch für alle Besucher sein.

Andere Bereiche sind hochdynamisch:

Warenkorb,

Kasse,

Kundenkonto.

Deshalb besitzen WordPress-Cache-Systeme häufig besondere Regeln für WooCommerce und ähnliche Anwendungen.

Ein schlecht konfigurierter Cache kann hier wesentlich problematischer sein als ein fehlender Cache.

Richtigkeit geht vor Geschwindigkeit.

Personalisierte Websites sind schwieriger zu cachen

Je stärker Inhalte vom einzelnen Benutzer abhängen, desto weniger eignet sich eine einzige gemeinsame HTML-Kopie.

Eine Website könnte beispielsweise unterschiedliche Inhalte zeigen nach:

Benutzerkonto,

Sprache,

Standort,

Mitgliedschaft,

gekauften Produkten.

Dann muss der Cache entweder unterschiedliche Varianten speichern oder bestimmte Bereiche dynamisch lassen.

Caching wird mit zunehmender Personalisierung deshalb anspruchsvoller.

Muss eine Nachrichtenseite ständig den Cache löschen?

Nicht zwangsläufig.

Auch häufig aktualisierte Seiten können hervorragend gecacht werden.

Wird ein neuer Artikel veröffentlicht, muss beispielsweise nur die betroffene Startseite beziehungsweise der entsprechende Bereich invalidiert werden.

Die übrigen tausenden Artikel bleiben unverändert.

Ein gutes Cache-System muss also nicht zwischen:

„alles cachen“

und

„nichts cachen“

entscheiden.

Es kann gezielt arbeiten.

Stale Content kann manchmal bewusst sinnvoll sein

Angenommen, der Ursprungsserver antwortet kurzfristig nicht.

Ein CDN oder Reverse Proxy besitzt aber noch eine etwas ältere Cache-Kopie.

In bestimmten Architekturen kann es besser sein, diese ältere Version vorübergehend auszuliefern, statt dem Besucher einen Fehler zu zeigen.

Dieses Prinzip wird häufig als „stale“ beziehungsweise veraltete, aber noch verwendbare Cache-Antwort bezeichnet.

Für Nachrichten oder Börsenkurse kann das ungeeignet sein.

Für einen drei Jahre alten Ratgeberartikel kann eine fünf Minuten ältere Cache-Kopie völlig problemlos sein.

Auch hier entscheidet der Inhalt.

Caching kann Verfügbarkeit verbessern

Caching wird meistens als Performancefunktion betrachtet.

Es kann aber auch die Robustheit eines Systems erhöhen.

Wenn ein vorgeschalteter Cache viele Anfragen selbst beantwortet, muss der Ursprungsserver weniger leisten.

Kurze Lastspitzen können besser abgefangen werden.

Manche bereits gecachten Inhalte können möglicherweise sogar noch ausgeliefert werden, wenn der Ursprung kurzzeitig Probleme hat.

Caching kann deshalb Teil der gesamten Betriebsarchitektur sein.

Cache kann Serverkosten reduzieren

Wenn eine dynamische Seite für jeden Aufruf viel CPU benötigt, müssen bei hohem Traffic entsprechend viele Ressourcen bereitgestellt werden.

Ein effektiver Cache reduziert diese Arbeit.

Dadurch kann derselbe Server wesentlich mehr Besucher bedienen.

Das bedeutet:

Performanceoptimierung kann gleichzeitig Kostenoptimierung sein.

Ein größerer Server ist nicht immer nötig, wenn ein großer Teil der Arbeit vermeidbar ist.

Caching hilft vor allem bei wiederholbarer Arbeit

Cache bringt besonders viel, wenn dieselbe Berechnung oder Datei häufig erneut benötigt wird.

Eine Seite, die nur einmal pro Jahr aufgerufen wird, profitiert kaum von aufwendigem Caching.

Eine Startseite mit tausenden täglichen Aufrufen dagegen sehr.

Dasselbe gilt für Datenbankobjekte.

Eine selten benötigte Abfrage zu speichern bringt wenig.

Ein Ergebnis, das bei jedem Seitenaufruf benötigt wird, ist wesentlich interessanter.

Nicht alles sollte gecacht werden

Ein Cache ist kein Selbstzweck.

Bestimmte Daten müssen bewusst aktuell bleiben.

Beispiele können sein:

individuelle Kontostände,

Checkout-Daten,

Sicherheitsinformationen,

zeitkritische Preise,

Benutzersitzungen.

Caching muss immer berücksichtigen, welche Veralterung akzeptabel ist.

Schnell und falsch ist keine gute Performance.

Die Cache-Dauer ist eine fachliche Entscheidung

Techniker können einstellen:

eine Minute,

eine Stunde,

einen Tag,

ein Jahr.

Aber welche Dauer richtig ist, hängt vom Inhalt ab.

Ein Logo verändert sich vielleicht nur einmal alle fünf Jahre.

Ein Wetterwert alle paar Minuten.

Ein Ratgeberartikel gelegentlich.

Ein Warenkorb bei jedem Klick.

Die passende Cache-Strategie entsteht deshalb aus dem Verhalten der Daten.

Caching kann Fehler schwerer nachvollziehbar machen

Ohne Cache sieht man normalerweise unmittelbar das Ergebnis der aktuellen Anwendung.

Mit mehreren Cache-Ebenen kann dagegen eine alte Version weiterleben.

Das erschwert Fehlersuche.

Ein Entwickler korrigiert einen Fehler, sieht ihn aber weiterhin.

Ein Administrator ändert DNS oder CDN-Einstellungen.

Ein Besucher erhält dennoch alte Inhalte.

Deshalb gehört zum Betrieb komplexerer Cache-Infrastrukturen eine klare Vorstellung davon, welche Ebene für welche Daten zuständig ist.

Zu viele Cache-Systeme machen die Fehlersuche unnötig schwer

Ein WordPress-Betreiber könnte gleichzeitig verwenden:

Cache-Plugin,

Hosting-Cache,

Redis,

CDN,

Browser-Cache,

Optimierungsplugin mit eigenem Cache.

Jede einzelne Komponente kann sinnvoll sein.

Die Kombination muss jedoch verstanden werden.

Wenn niemand mehr weiß, welches System welche Funktion übernimmt, wird Performanceoptimierung schnell zum Ratespiel.

Die beste Cache-Architektur ist nicht die mit den meisten Ebenen.

Sie ist diejenige mit klaren Zuständigkeiten.

Ein kleines WordPress-Projekt braucht meist keine komplizierte Architektur

Für eine normale Informationswebsite kann bereits reichen:

gutes Hosting,

Page Cache,

korrektes Browser-Caching.

Vielleicht kommt später ein CDN hinzu.

Redis, komplexe Reverse-Proxy-Konfigurationen und mehrere Cache-Schichten sind nicht automatisch notwendig.

Eine einfache Architektur ist leichter zu warten und zu verstehen.

Komplexität sollte durch einen tatsächlichen Bedarf gerechtfertigt sein.

Ein großer dynamischer Shop braucht möglicherweise mehr Ebenen

Anders sieht es bei stark frequentierten dynamischen Systemen aus.

Dort können sinnvoll zusammenspielen:

Browser-Cache für statische Ressourcen,

CDN für Bilder und Assets,

Page Cache für öffentliche Seiten,

Object Cache für dynamische WordPress-Daten,

OPcache für PHP,

spezialisierte Datenbankoptimierung.

Jede Ebene reduziert eine andere Art von Arbeit.

Das ist wesentlich wirkungsvoller als ein einzelner universeller „Turbo-Schalter“.

Woher weiß ich, ob mein Cache funktioniert?

Dafür kann man unterschiedliche Ebenen untersuchen.

Bei Browserressourcen lassen sich beispielsweise Netzwerkwerkzeuge des Browsers verwenden.

Bei Server- und CDN-Caches existieren häufig HTTP-Header oder Verwaltungsanzeigen, die Hinweise auf Cache Hits und Misses geben.

Auch die Antwortzeit kann einen deutlichen Unterschied zeigen.

Ein ungecachter erster Aufruf benötigt beispielsweise 700 Millisekunden serverseitige Verarbeitung.

Der nächste Cache Hit vielleicht nur einen Bruchteil davon.

Messung ist auch beim Caching besser als Vermutung.

Ein schneller zweiter Aufruf beweist nicht automatisch Page Caching

Vielleicht befindet sich inzwischen nur:

das Bild,

CSS,

JavaScript

im Browser-Cache.

Die eigentliche HTML-Seite wird weiterhin dynamisch erzeugt.

Deshalb sollte bei Performanceanalysen möglichst genau betrachtet werden, welcher Teil schneller geworden ist.

Das entspricht demselben Grundsatz wie in Warum Websites langsam werden:

Erst verstehen, wo Zeit verloren geht.

Dann die passende Ebene optimieren.

Cache sollte nach Updates berücksichtigt werden

Ein WordPress-Update oder Plugin-Update kann Dateien verändern.

Wenn alte gecachte Ressourcen weiterhin ausgeliefert werden, können vorübergehend unterschiedliche Versionen zusammenkommen.

Viele Systeme kümmern sich automatisch um entsprechende Invalidierung.

Bei größeren Änderungen kann dennoch ein gezielter Cache-Purge sinnvoll sein.

Insbesondere nach:

Themeänderungen,

CSS-Anpassungen,

größeren Pluginänderungen

sollte geprüft werden, ob tatsächlich die aktuelle Version ausgeliefert wird.

Cache-Purge gehört nicht als Ritual zu jeder Textänderung

Wenn ein ordentlich konfiguriertes Cache-System bei einer Artikeländerung automatisch die richtige Seite invalidiert, sollte der Administrator nicht nach jedem korrigierten Tippfehler sämtliche Caches weltweit leeren müssen.

Wenn das regelmäßig nötig ist, spricht das eher dafür, die Cache-Invalidierung zu verbessern.

Automatisierung sollte bekannte Zusammenhänge selbst handhaben.

Caching und SEO

Caching ist kein direkter SEO-Trick.

Es kann aber technische Voraussetzungen verbessern.

Schnellere und zuverlässigere Seiten sind für Besucher angenehmer.

Ein Cache kann außerdem helfen, Lastspitzen zu bewältigen und Serverantwortzeiten zu reduzieren.

Das allein garantiert keine besseren Suchmaschinenpositionen.

Ein gecachter schlechter Artikel bleibt ein schlechter Artikel.

Caching unterstützt die technische Qualität.

Es ersetzt keinen hilfreichen Inhalt.

Caching und Datenschutz

Ein falsch konfigurierter gemeinsamer Cache kann Datenschutz- und Sicherheitsprobleme verursachen.

Persönliche oder benutzerspezifische Inhalte dürfen nicht einfach für andere Besucher gespeichert und ausgeliefert werden.

Gerade bei:

Kundenkonten,

persönlichen Dashboards,

Formularergebnissen,

privaten Bereichen

muss genau definiert werden, was cachebar ist.

Performance darf niemals dazu führen, dass Benutzer fremde Daten sehen können.

Cache-Systeme brauchen ebenfalls Ressourcen

Caching spart Arbeit, benötigt dafür aber Speicherplatz beziehungsweise Arbeitsspeicher.

Ein Object Cache kann RAM verbrauchen.

Ein Page Cache benötigt Speicher.

Ein CDN speichert Kopien auf seiner Infrastruktur.

Caches können deshalb nicht unbegrenzt wachsen.

Ältere oder selten benötigte Einträge müssen irgendwann entfernt werden.

Das geschieht je nach System automatisch nach unterschiedlichen Strategien.

Cache ist bewusst temporär

Genau deshalb sollte ein Cache nie die einzige Kopie wichtiger Daten enthalten.

Er muss im Prinzip jederzeit vollständig gelöscht werden können.

Danach sollte die Anwendung weiterhin funktionieren – nur zunächst langsamer, bis neue Cache-Inhalte aufgebaut wurden.

Wenn das Löschen eines Caches dauerhaft Daten zerstört, handelt es sich nicht mehr nur um einen Cache.

Das ist ein nützlicher Grundsatz zur technischen Einordnung.

Was passiert nach einem kompletten Cache-Purge?

Zunächst fehlen gespeicherte Ergebnisse.

Die nächsten Besucher lösen deshalb wieder echte Berechnungen aus.

Eine WordPress-Seite muss erneut erzeugt werden.

Daten werden aus der Datenbank gelesen.

HTML wird gespeichert.

Nach und nach füllt sich der Cache wieder.

Bei einer kleinen Website merkt man davon kaum etwas.

Bei sehr großen Portalen kann ein gleichzeitiger kompletter Purge vieler Seiten kurzfristig deutlich mehr Serverlast erzeugen.

Deshalb wird dort gezielter invalidiert oder Cache Warming eingesetzt.

Caching ersetzt keine Optimierung

Ein Cache kann eine langsame WordPress-Seite für anonyme Besucher extrem schnell machen.

Im Hintergrund kann die Anwendung trotzdem ineffizient bleiben.

Das merkt man beispielsweise:

im Backend,

beim Cache Miss,

bei eingeloggten Benutzern,

beim Checkout.

Deshalb sollte ein Cache nicht als Ausrede dienen, grundlegende Performanceprobleme vollständig zu ignorieren.

Er ist eine Optimierungsebene, keine Reparatur für jede schlechte Architektur.

Caching und Bildoptimierung ergänzen sich

Ein Cache verhindert, dass ein Browser dieselbe Bilddatei ständig erneut herunterladen muss.

Beim ersten Aufruf muss die Datei aber trotzdem übertragen werden.

Ist sie 8 Megabyte groß, bleiben diese 8 Megabyte beim ersten Laden ein Problem.

Deshalb ergänzen sich Browser-Caching und Bildoptimierung hervorragend.

Caching reduziert Wiederholungen.

Optimierung reduziert die eigentliche Datenmenge.

Genau deshalb folgt im Performance-Cluster anschließend Bilder für Websites optimieren.

Caching und CDN ergänzen sich ebenfalls

Ein Browser-Cache hilft einem einzelnen Besucher.

Ein CDN-Cache kann dieselbe gespeicherte Kopie für viele Besucher einer Region nutzen.

Ein serverseitiger Page Cache verhindert die wiederholte WordPress-Berechnung.

Die Ebenen können deshalb zusammenarbeiten:

WordPress
↓
Page Cache
↓
CDN
↓
Browser

Jede Ebene vermeidet eine andere Form wiederholter Arbeit.

Die beste Cache-Strategie beginnt beim Inhalt

Bevor ein neues Caching-System eingerichtet wird, lohnt sich deshalb die Frage:

Welche Seiten sind für alle Besucher identisch?

Welche Daten verändern sich häufig?

Welche Inhalte sind personalisiert?

Welche Dateien verändern sich selten?

Welche Anfragen erzeugen besonders viel Rechenarbeit?

Aus diesen Antworten entsteht eine Cache-Strategie.

Nicht aus der möglichst langen Liste aktivierter Optimierungsoptionen.

Was du dir über Caching merken solltest

Caching bedeutet, bereits erzeugte oder übertragene Ergebnisse vorübergehend zu speichern und später wiederzuverwenden.

Dabei existieren unterschiedliche Ebenen.

Browser-Caching verhindert unnötige erneute Downloads auf dem Gerät des Besuchers.

Page Caching speichert fertige Webseiten und kann WordPress bei vielen Aufrufen vollständig umgehen.

Server- und Reverse-Proxy-Caches können Antworten bereits vor der Anwendung ausliefern.

Object Caching speichert häufig benötigte Daten und reduziert unter anderem wiederholte Datenbankarbeit.

OPcache beschleunigt PHP auf Serverebene.

CDN-Caching verteilt gespeicherte Inhalte näher an Besucher und reduziert Anfragen an den Ursprungsserver.

Keine dieser Ebenen ist automatisch besser als die andere.

Sie lösen unterschiedliche Probleme.

Und genau deshalb ist die wichtigste Regel bei Cache-Problemen:

Nicht einfach „den Cache“ löschen – zuerst herausfinden, welcher Cache überhaupt beteiligt ist.