Website-Cache & serverseitiger Cache: So funktioniert Caching in WordPress
Als ich Website-Cache und serverseitigen Cache auf dem Server geprüft habe, auf dem diese Website läuft, liefen WordPress-Seitenanfragen vom Browser über CDN, Seiten-Cache, OPcache und Redis nach unten und stoppten an der Schicht, die eine Kopie hatte. Seitenanfragen, die direkt beim Ursprungsserver ankamen, bekamen die von WP Rocket erzeugte HTML-Datei sofort von nginx und reichten nie bis zu PHP oder der Datenbank.
Ⅰ. Aufbau des WordPress-Caches
In der Informatik ist ein Cache eine Technik, Daten vorübergehend zu speichern, damit sie schnell abrufbar sind; im Web funktioniert er nach demselben Prinzip und trägt viel zur Leistung bei.
Caching speichert Daten, damit der Server beim Aufruf einer Website nicht jedes Mal alles neu erzeugen muss; gespeicherte Daten laden schnell, und die Ladezeit sinkt. Das senkt die Serverlast und verbessert das Nutzererlebnis.
Die Caches für WordPress-Anfragen teilen sich in zwei Zweige: Website-Cache und serverseitiger Cache. Der HTTP-Caching-Standard, wie ihn MDN beschreibt, unterscheidet einen Cache, der nur im Browser eines einzelnen Besuchers liegt (private cache), von CDN- und Proxy-Caches, die viele Besucher gemeinsam nutzen (shared cache); dieser Beitrag fasst beide als Website-Cache zusammen.
Seiten-Cache, OPcache und Objekt-Cache hängen am Ablauf, mit dem WordPress im Server läuft. Der HTTP-Standard kennt dafür keine eigene Kategorie; die Einteilung stammt aus der offiziellen WordPress-Dokumentation: Caching-Plugins (Seiten-Cache), Objekt-Cache und Server-Cache (Opcode-Caches wie OPcache).
Alle Bereiche, in denen Caching eingesetzt wird, sind im Beitrag Was ist Cache? Definition und alle Bereiche, in denen Caching genutzt wird beschrieben, die vier Zweige der Performance-Optimierung samt Caching im Beitrag Web-Performance-Optimierung: Aufbau und Definition zusammengefasst.
Wähle im Simulator unten links im Baum einen Cache und tippe auf einen Chip; dann siehst du, an welcher Schicht die Anfrage stoppt. Die erste Schicht, die WordPress-Betreiber mit einem Caching-Plugin einschalten, ist der Seiten-Cache.
| Schicht | Speicherort | Was gespeichert wird | Beispiel Nginx + Apache |
|---|---|---|---|
| Browser-Cache | Gerät des Besuchers | HTML · CSS · JS · Bilder · Schriften | CSS · Bilder 7 Tage |
| CDN · Proxy-Cache | Vor dem Server (Edge · Reverse Proxy) | Kopien von Seiten · statischen Dateien | Bunny CDN |
| Seiten-Cache | Festplatte · Speicher des Servers | Von PHP erzeugtes HTML | WP Rocket + nginx |
| OPcache | Speicher des Servers | PHP-Bytecode | PHP 8.3, JIT aus |
| Objekt-Cache | Speicher des Servers | Abfrageergebnisse · Objekte | Redis |
Ⅱ. Website-Cache
Website-Cache ist der Cache, bei dem der Server über Antwort-Header sagt, wie gespeichert werden soll, und Browser sowie CDNs oder Proxys danach eine Kopie ablegen. Typische Header sind [Cache-Control], [ETag] und [Expires]; nach Ablauf der Speicherdauer prüft eine bedingte Anfrage ([304 Not Modified]), ob sich etwas geändert hat.
1️⃣ Browser-Cache
Der Browser-Cache ist der HTTP-Cache im Webbrowser des Besuchers. Er speichert HTML, CSS, JavaScript, Bilder und Schriften; wird dieselbe Ressource erneut angefragt, geht er entweder gar nicht zum Server oder prüft nur, ob sie sich geändert hat.
Die Speicherdauer legt der Server fest, nicht der Besucher. Der Nginx + Apache-Server unten gibt CSS und Bildern 7 Tage vor und liefert HTML-Seiten ohne Dauer aus, sodass sie bei jedem Besuch erneut geprüft werden.
If-None-Match: "6ab12775-2ee8"cache-control: max-age=604800 expires: Sat, 17 Oct 2026 03:21:00 GMT etag: "6ab12775-2ee8"
etag: "6ac9298c-95575" last-modified: Fri, 09 Oct 2026 17:51:08 GMT
2️⃣ CDN · Proxy-Cache
CDN- und Proxy-Caches liegen zwischen Besuchern und Ursprungsserver und werden von vielen Besuchern gemeinsam genutzt. Ein Forward Proxy sitzt auf der Seite des Besuchers, etwa in einem Firmennetz, während Reverse Proxys und CDNs vor dem Server sitzen und anstelle des Ursprungsservers mit einer gespeicherten Kopie antworten.
Ein typischer Reverse Proxy ist Varnish Cache, und CDNs wie Bunny CDN und Akamai folgen demselben Aufbau. Mit regionalem DNS lassen sich Besucher aus der Region des Ursprungsservers direkt mit ihm verbinden, während Besucher aus anderen Regionen die Antwort von einem nahen CDN-Edge (z. B. Bunny CDN) bekommen, der sogar das HTML speichert.
Aufbau und Vorteile eines CDN sind im Beitrag Was ist ein CDN? Gründe für ein CDN und 5 Vorteile zusammengefasst.
Ⅲ. Serverseitiger Cache
Serverseitiger Cache ist der Cache, der am Ablauf hängt, mit dem WordPress eine Seite erzeugt, nachdem die Anfrage beim Ursprungsserver angekommen ist. Ein Server mit Nginx + Apache bearbeitet Anfragen in der Reihenfolge unten; findet ein früherer Schritt eine Kopie, entfallen die späteren.
Ein Nginx + Apache-Setup kannst du bei Cloudways und ScalaHosting als Option wählen. Bei Cloudways wählst du pro Anwendung entweder den Hybrid-Stack (Nginx + Apache) oder den Lightning-Stack (nur Nginx), und bei ScalaHosting kannst du in SPanel eine Einstellung einschalten, die Nginx vor Apache setzt.
| Cache | Was gespeichert wird | Wann gespeichert wird |
|---|---|---|
| 1️⃣ Seiten-Cache | Fertige HTML-Seite | 🅑 ⑤ Beim Antworten speichert WP Rocket sie als Datei |
| 2️⃣ OPcache | Kompilierter PHP-Code (Bytecode) | 🅑 ② Wenn eine PHP-Datei zum ersten Mal läuft |
| 3️⃣ Objekt-Cache | Datenstücke wie Abfrageergebnisse und Optionen | 🅑 ③ Wenn WordPress die Daten zum ersten Mal holt |
1️⃣ Seiten-Cache
Der Seiten-Cache heißt auch Full-Page-Cache, und weil er HTML speichert, manchmal HTML-Cache. Er legt die ganze von PHP erzeugte Webseite als statische HTML-Datei ab und schickt diese Datei bei derselben Seitenanfrage, ohne PHP auszuführen. Das ist Fall 🅐 im Ablauf oben.
Gespeichert wird im Arbeitsspeicher (RAM) oder auf der Festplatte (HDD/SSD) des Servers: Speicher ist schnell, aber teuer und begrenzt, die Festplatte hat viel Platz, ist aber vergleichsweise langsam.
| Art | Beispiel | Wie gespeichert und geantwortet wird |
|---|---|---|
| Caching-Plugin | WP Rocket · WP Super Cache · W3 Total Cache · Cache Enabler | WordPress speichert die Seite als HTML-Datei, und der Webserver schickt diese Datei. |
| Webserver-Cache | Nginx FastCGI Cache · LiteSpeed Cache | Der Webserver speichert die PHP-Antwort selbst und schickt sie bei der nächsten Anfrage. |
| Reverse-Proxy-Cache | Varnish | Ein Cache-Server vor dem Webserver speichert die Seite und antwortet. |
Bei Nginx + Apache liest nginx die von WP Rocket erzeugte HTML-Datei direkt und schickt sie, und der Antwort-Header bekommt [x-rocket-nginx-serving-file: HIT]. Wie du den Seiten-Cache mit WP Rocket einschaltest und einrichtest, ist im Beitrag WP Rocket Anleitung zusammengefasst.
2️⃣ OPcache
OPcache speichert vorab zu Bytecode kompilierten PHP-Code im Speicher, sodass beim erneuten Ausführen derselben Datei der PHP-Parser entfällt. Er ist seit PHP 5.5 eingebaut; die früher genutzten APC und XCache unterstützen PHP 7 nicht und werden heute nicht mehr verwendet. Das ist Schritt ② von 🅑 im Ablauf oben.
| Art | Status | Beschreibung |
|---|---|---|
| Zend OPcache | Seit PHP 5.5 eingebaut | Der heute übliche Standard-Opcode-Cache, eingeschaltet mit [opcache.enable=1]. |
| OPcache JIT | Seit PHP 8 in OPcache enthalten | Wandelt Bytecode noch einmal in Maschinencode um und führt ihn aus; ein- und ausgeschaltet mit [opcache.jit]. |
| APC | Eingestellt | Der Opcode-Cache vor OPcache; seine Daten-Cache-Funktion lebt in APCu weiter. |
| XCache | Eingestellt | Unterstützt PHP 7 nicht. |
| WinCache | Für Windows-Server (IIS) | Ein Opcode-Cache, den die offizielle WordPress-Dokumentation neben OPcache nennt. |
OPcache schaltest du mit der PHP-Einstellung [opcache.enable=1] ein, und das mit PHP 8 hinzugekommene JIT lässt sich mit [opcache.jit=disable] separat abschalten. Installation und Einrichtung sind im Beitrag Zend OPcache: Konzept, Installation und Einrichtung beschrieben.
3️⃣ Objekt-Cache
Der Objekt-Cache speichert Ergebnisse von Datenbankabfragen oder berechnete Objekte in einem Speicher wie Redis oder Memcached. Standardmäßig merkt sich WordPress Objekte nur innerhalb einer einzelnen Anfrage; erst mit einem Speicher wie Redis bleiben die Ergebnisse nach der Anfrage erhalten. Das ist Schritt ③ von 🅑 im Ablauf oben.
| Art | Art | Bleibt nach der Anfrage erhalten? | Beschreibung |
|---|---|---|---|
| WP_Object_Cache | WordPress-Standard | Nein | Ein eingebauter Cache, der sich nur innerhalb einer Anfrage etwas merkt. |
| Redis | Objekt-Cache | Ja | Ein eigener Speicher, angebunden über das Drop-in des Plugins Redis Object Cache. |
| Memcached | Objekt-Cache | Ja | Ein eigener Speicher. |
| APCu | Objekt-Cache | Ja (innerhalb desselben Servers) | Speichert im gemeinsamen Speicher, den PHP nutzt. |
| Datei | Objekt-Cache | Ja | Speichert als Dateien auf der Festplatte. |
| InnoDB-Pufferpool | Eigener Cache der Datenbank · kein Objekt-Cache | Ja | MySQL und MariaDB halten Tabellendaten und Indizes im Speicher. |
| Query-Cache | Eigener Cache der Datenbank · kein Objekt-Cache | — | In MySQL 8.0 entfernt; in MariaDB noch vorhanden, aber standardmäßig aus. |
WordPress verbindet sich über die Drop-in-Datei ([object-cache.php]), die das Plugin Redis Object Cache anlegt, mit Redis. Die Installation ist im Beitrag Redis Cache für WordPress installieren und einrichten beschrieben.
🔢 FAQ & empfohlene Inhalte
ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt(bei Aktionsrabatten sinkt er ↓), steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.