- Caching speichert fertig berechnete Seiten zwischen, damit der Server sie nicht bei jedem Aufruf neu zusammensetzen muss. Das reduziert die Ladezeit oft von mehreren Sekunden auf unter eine Sekunde.
- Es gibt vier unabhängige Cache-Ebenen: Browser-Cache, Page-Cache (Server), Objekt-Cache (Redis) und OPcache (PHP). Jede arbeitet an einer anderen Stelle der Anfragekette.
- Ein Caching-Plugin reicht als Einstieg, aber dynamische Inhalte wie Warenkorb, Login-Bereiche und personalisierte Seiten dürfen niemals gecacht werden.
- WP Rocket, W3 Total Cache und WP Super Cache sind die am weitesten verbreiteten Lösungen für WordPress; welche passt, hängt von der Hosting-Umgebung ab.
Eine WordPress-Website, die bei jedem Seitenaufruf neu aus der Datenbank zusammengesetzt wird, kann schnell an ihre Grenzen stoßen. Caching ist die technische Antwort darauf: fertig berechnete Ergebnisse werden zwischengespeichert und bei Folgeaufrufen direkt ausgeliefert. Dieser Artikel erklärt, wie die vier zentralen Cache-Ebenen funktionieren, welche Plugins es für WordPress gibt und wo Caching mehr Schaden anrichtet als Nutzen bringt.
Was Caching ist und warum WordPress es braucht
Stellen Sie sich eine Bäckerei vor, die jeden Morgen nach einem festen Rezept dieselben zwanzig Brötchensorten backt. Statt jedes Brötchen einzeln auf Bestellung zu formen und zu backen, legt die Bäckerei am frühen Morgen einen Vorrat an. Wer bestellt, bekommt sofort sein Brötchen, und der Ofen steht nicht den ganzen Tag unter Dauerlast.
Bei WordPress läuft ein ungesicherter Seitenaufruf so ab: Der Browser des Besuchers sendet eine Anfrage an den Webserver, PHP fragt mehrere Tabellen der MySQL-Datenbank ab, Theme-Dateien und Plugin-Code werden interpretiert, und erst dann entsteht das fertige HTML, das zum Browser zurückgeschickt wird. Bei einer typischen WordPress-Installation mit zehn bis zwanzig aktiven Plugins können dabei 30 bis 80 Datenbankabfragen pro Seitenaufruf entstehen. Dieser Vorgang kostet messbare Zeit, und er wiederholt sich für jeden Besucher.
WordPress selbst bringt kein vollständiges Page-Caching mit. Das ist kein Versehen, sondern folgt der Architektur: WordPress ist ein dynamisches System, das sich über Themes und Plugins stark verändern lässt, und diese Erweiterungen gehen sehr unterschiedlich mit Inhalten um. Ein universelles Caching-System würde in vielen Konfigurationen falsche Inhalte ausliefern. Caching wird deshalb nachträglich eingerichtet und auf die konkrete Installation abgestimmt.
Warum das lohnt, zeigt ein Blick auf die Messwerte: Websites, die in den Core Web Vitals ein „Gut“ bei Largest Contentful Paint (LCP) erreichen wollen, müssen unter 2,5 Sekunden bleiben. Ohne Caching schaffen das viele mittelständische WordPress-Installationen auf Shared Hosting nicht zuverlässig, erst recht nicht unter Last.
Browser-Cache: was der Besucher schon lokal hat
Gesteuert wird das über HTTP-Header, die der Server mit jeder Antwort mitschickt. Der entscheidende Header ist Cache-Control. Ein typischer Wert für statische Ressourcen ist max-age=31536000, immutable, was bedeutet: diese Datei darf der Browser bis zu ein Jahr lang ohne Rückfrage aus seinem eigenen Speicher ausliefern.
Laut MDN Web Docs gibt es zwei grundlegende Cache-Strategien: Fresh bedeutet, der Browser nutzt seine Kopie direkt ohne Rückfrage. Stale bedeutet, der Browser fragt beim Server nach, ob sich die Datei geändert hat, bevor er sie nutzt. Für diese Prüfung wird in der Regel ein ETag genutzt: ein Fingerabdruck der Datei, den der Server mitspeichert. Hat sich der ETag nicht verändert, antwortet der Server mit einem schlanken 304 Not Modified, und der Browser nutzt seinen Cache. Dieser Mechanismus ist erheblich schneller als das erneute Übertragen der gesamten Datei.
Für WordPress bedeutet das: Bilder, Fonts, CSS- und JavaScript-Dateien sollten lange Cache-Zeiten bekommen. Bei Änderungen an diesen Dateien, zum Beispiel nach einem Theme-Update, muss die URL der Datei sich ändern, damit der Browser nicht weiterhin die alte Kopie ausliefert. Modernes Asset-Management löst das über Cache-Busting: An die URL wird ein Versions-Parameter angehängt (etwa style.css?ver=2.3.1), der sich bei jeder Änderung aktualisiert.
Browser-Caching konfigurieren Sie auf Apache-Servern über mod_expires oder die .htaccess, auf Nginx über das Headers-Modul. Die meisten Caching-Plugins für WordPress setzen diese Header mit, ohne dass Sie selbst in die Serverkonfiguration eingreifen müssen.
Page-Cache: der größte Einzelhebel
Der Ablauf ohne Page-Cache: Anfrage kommt an, PHP startet, Datenbank wird abgefragt, HTML wird erzeugt, Antwort geht raus. Mit Page-Cache: Anfrage kommt an, der Cache-Handler prüft, ob eine gespeicherte Version existiert, und liefert sie aus. PHP und Datenbank bleiben komplett außen vor.
Wie groß der Gewinn ist, hängt von der Komplexität der Installation ab. Eine WordPress-Seite mit WooCommerce und zwanzig Plugins kann auf Shared Hosting ohne Cache drei bis fünf Sekunden Ladezeit haben. Mit sauber konfiguriertem Page-Cache sinkt dieser Wert bei typischen Informationsseiten regelmäßig auf unter 500 Millisekunden, weil der Server nur noch eine Datei von der Festplatte liest und zurückschickt.
Page-Caching wird in WordPress durch Plugins realisiert. Die Seite zu WordPress-Optimierung in der offiziellen Dokumentation nennt Caching als erste empfohlene Maßnahme und verweist direkt auf verfügbare Plugins.
Ein Sonderfall ist serverseitiges Caching auf Hosting-Ebene: Managed-WordPress-Hoster wie Kinsta, WP Engine oder auch manche Pakete bei all-inkl.com setzen ein eigenes Page-Caching ein, das noch vor PHP greift. In diesem Fall sollte das Caching-Plugin so konfiguriert werden, dass es dem Hosting-Cache nicht in die Quere kommt. Doppeltes Page-Caching ist in der Regel kontraproduktiv.
Objekt-Cache und Redis
Der WordPress Object Cache ist eine interne API, über die Plugins und das Core-System Datenbankabfragen zwischenspeichern können. Ohne ein persistentes Backend werden diese Daten bei jeder neuen PHP-Anfrage neu aus der Datenbank geladen, weil der Arbeitsspeicher zwischen Anfragen nicht geteilt wird.
Mit einem persistenten Objekt-Cache wie Redis Object Cache oder Memcached bleiben diese Daten im Arbeitsspeicher des Servers dauerhaft vorgehalten. Eine Abfrage der WordPress-Options-Tabelle, die ohne Cache bei jedem Aufruf gegen die Datenbank geht, wird stattdessen aus dem In-Memory-Store beantwortet, was um den Faktor 10 bis 100 schneller ist.
Redis ist besonders sinnvoll bei Installationen mit vielen gleichzeitigen Zugriffen, bei Shops mit komplexen Menüstrukturen und bei Membership-Sites, die viele individuelle Datenbank-Abfragen erzeugen. Auf Shared Hosting ist Redis oft nicht verfügbar, auf Managed-WordPress-Hostern häufig als Option buchbar.
Ein Objekt-Cache ersetzt den Page-Cache nicht. Beide arbeiten auf unterschiedlichen Ebenen: Der Page-Cache speichert das fertige HTML, der Objekt-Cache speichert die Rohdaten, aus denen das HTML gebaut wird. Bei einer Seite, die gecacht ist und direkt als HTML ausgeliefert wird, hilft Redis gar nicht, weil die Datenbankabfragen gar nicht stattfinden. Bei dynamischen Seiten, die nicht gecacht werden dürfen, zum Beispiel dem Warenkorb, macht der Objekt-Cache trotzdem einen messbaren Unterschied.
OPcache: PHP-Code nicht doppelt übersetzen
PHP ist eine interpretierte Sprache. Das bedeutet: Der PHP-Interpreter liest bei jeder Anfrage den Quellcode, übersetzt ihn in einen Zwischencode (Opcodes) und führt ihn dann aus. Bei WordPress mit zehn bis zwanzig Plugins bedeutet das, dass bei jedem Seitenaufruf mehrere hundert PHP-Dateien erneut übersetzt werden, inklusive des gesamten WordPress-Cores.
OPcache ist eine Erweiterung, die seit PHP 5.5 in den PHP-Core integriert ist und auf den meisten Hostern standardmäßig aktiv ist. Sie speichert den kompilierten Bytecode (die Opcodes) im Arbeitsspeicher des Servers. Beim nächsten Aufruf entfällt die Übersetzungsphase, und PHP führt direkt den gespeicherten Bytecode aus.
In der Praxis reduziert OPcache die reine PHP-Ausführungszeit einer WordPress-Seite je nach Installation um 50 bis 80 Prozent. Das klingt nach viel, der absolute Gewinn hängt aber davon ab, wie viel Zeit PHP überhaupt verbraucht. Auf einem bereits gut konfigurierten Server mit Page-Cache ist der Effekt von OPcache für gecachte Seiten kaum spürbar, weil PHP bei gecachten Seiten ohnehin nicht zum Einsatz kommt.
OPcache richtet der Hoster in der Regel ein. Als Website-Betreiber müssen Sie nichts konfigurieren, können aber im PHP-Info-Bereich des Hosting-Control-Panels prüfen, ob opcache.enable auf 1 steht.
CDN: Auslieferung nah am Besucher
CDN ist eine eigene Disziplin, die einen separaten Artikel verdient. Der wesentliche Unterschied zu den anderen Cache-Ebenen: Ein CDN ist räumlich verteilt. Wenn Ihr Server in einem deutschen Rechenzentrum steht und ein Besucher aus der Schweiz kommt, muss jede Datei dieselbe Strecke zurücklegen. Ein CDN mit einem Standort in Zürich halbiert diese Strecke.
Für eine Website mit überwiegend deutschen Besuchern und einem Server in Deutschland ist der CDN-Gewinn bei reinen HTML-Seiten gering, bei Bildern und Videos aber messbar. Der größere Nutzen ist oft die Server-Entlastung: Statische Dateien werden vom CDN ausgeliefert, der eigene Server muss nur noch die dynamischen Seiten beantworten.
Wie CDN konkret eingerichtet wird und wann es sich für kleine Unternehmen wirklich lohnt, beschreibt der Artikel CDN für kleine Unternehmen ausführlich.
Wie die Ebenen zusammenspielen
Die vier Cache-Ebenen arbeiten nicht gegeneinander, sondern hintereinander. Jede Ebene fängt Anfragen ab, die zur nächsten Ebene durchgefallen wären. Das Zusammenspiel sieht vereinfacht so aus:
- Der Besucher ruft eine Seite auf. Sein Browser prüft zuerst seinen eigenen Cache. Hat er die statischen Dateien (CSS, Bilder, JS) noch gespeichert und sind sie nicht abgelaufen, lädt er sie von dort.
- Alles, was der Browser nicht hat, geht als Anfrage an den Server. Der Server prüft, ob ein Page-Cache für diese URL existiert. Falls ja, schickt er die HTML-Datei direkt zurück.
- Gibt es keinen Page-Cache-Treffer, startet PHP. OPcache stellt sicher, dass der PHP-Code nicht neu übersetzt werden muss.
- PHP greift für Daten wie Menüs und Einstellungen auf den Objekt-Cache zurück, statt jede Abfrage gegen die Datenbank zu schicken.
In der Betreuungspraxis begegnen wir häufig Installationen, bei denen ein Caching-Plugin aktiv ist, aber Browser-Cache-Header fehlen und kein CDN eingebunden ist. Der einfachste Gewinn liegt oft im Zusammenspiel aller Ebenen, nicht im Austausch einer einzelnen Komponente.
Warum manche Websites trotz Caching langsam sind, erklärt der Artikel zu den häufigsten Ursachen langsamer Websites.
Überblick: alle Cache-Ebenen im Vergleich
| Cache-Ebene | Was sie speichert | Wo sie greift | Werkzeug/Einstellung |
|---|---|---|---|
| Browser-Cache | Statische Dateien (CSS, JS, Bilder, Fonts) | Gerät des Besuchers | Cache-Control-Header, .htaccess, Caching-Plugin |
| Page-Cache | Fertig gerendertes HTML der Seite | Webserver / Festplatte | WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache |
| Objekt-Cache | Datenbankabfrageergebnisse, Options, Transients | Arbeitsspeicher des Servers | Redis, Memcached + passendes WordPress-Plugin |
| OPcache | Kompilierter PHP-Bytecode | PHP-Interpreter, Arbeitsspeicher | PHP-Konfiguration (opcache.enable=1), kein Plugin nötig |
| CDN | Statische Dateien, teils auch HTML | Verteilte Server weltweit | Cloudflare, Bunny.net, KeyCDN u.a. |
Caching-Plugins für WordPress
Für Page-Caching und Browser-Cache-Header stehen drei weit verbreitete Plugins zur Wahl.
WP Super Cache
WP Super Cache von Automattic (dem WordPress-Mutterunternehmen) ist das einfachste der drei Plugins. Es erzeugt statische HTML-Dateien aus WordPress-Seiten und speichert sie im Dateisystem. Bei einem Seitenaufruf liefert der Webserver diese Datei direkt aus, ohne PHP zu starten. Die Einrichtung ist in Minuten erledigt, und die Standardeinstellungen funktionieren auf den meisten einfachen WordPress-Installationen. Der Funktionsumfang ist bewusst schlank gehalten, was die Konfiguration einfach macht, bei komplexeren Anforderungen aber Grenzen zeigt.
W3 Total Cache
W3 Total Cache ist das umfangreichste der drei kostenlosen Plugins. Es deckt Page-Cache, Objekt-Cache, Browser-Cache, Datenbank-Cache und CDN-Integration in einer einzigen Oberfläche ab. Das macht es leistungsfähig, aber auch komplex: Wer nicht weiß, was er konfiguriert, kann mit den falschen Einstellungen mehr Schaden als Nutzen anrichten. Auf Servern mit Memcached oder Redis ist W3 Total Cache eine solide Wahl, weil es diese Backends direkt anbindet.
WP Rocket
WP Rocket ist kostenpflichtig (ab etwa 59 Euro pro Jahr für eine Website) und gilt in der Praxis als die ausgereifteste Lösung mit dem besten Verhältnis aus Konfigurationsaufwand und Ergebnis. Sinnvolle Standardeinstellungen, eine klar strukturierte Oberfläche und eine aktive Exklusion typischer dynamischer Seiten (Warenkorb, Checkout, Login) direkt nach der Installation machen es zur empfehlenswerten Option für Produktivseiten, die kein technisches Tüfteln erlauben. Bei WooCommerce-Shops ist WP Rocket die sicherste Wahl, weil die kritischen Ausnahmen schon vorab gesetzt sind.
LiteSpeed Cache
LiteSpeed Cache ist nur sinnvoll, wenn der Hoster LiteSpeed als Webserver einsetzt. Das Plugin arbeitet dann direkt mit dem Server zusammen und erreicht eine Effizienz, die PHP-basierte Lösungen nicht bieten. Auf Apache oder Nginx läuft LiteSpeed Cache zwar auch, bietet dann aber keinen nennenswerten Vorteil gegenüber den anderen Plugins.
Cache-Fallen: was niemals gecacht werden darf
Das ist die gefährlichste Seite des Cachings: Ein Page-Cache, der falsch konfiguriert ist, liefert einer Person die gecachte Seite einer anderen. Bei Informationsseiten bedeutet das veraltete Inhalte. Bei Onlineshops kann das bedeuten, dass ein Besucher den Warenkorb eines anderen Kunden sieht.
Folgende Bereiche müssen grundsätzlich vom Page-Caching ausgenommen werden:
- Warenkorb und Checkout: Diese Seiten sind per Definition individuell. Jeder Kunde hat andere Produkte im Warenkorb, andere Preise, andere Mengen. Ein gecachter Warenkorb ist ein ernsthaftes Datenschutz- und Vertrauensproblem.
- Login-Seiten und eingeloggte Nutzer: Ein eingeloggter Benutzer sieht in der Regel andere Inhalte als ein anonymer Besucher. Der Admin darf nicht die gecachte Version des Kundenprofils sehen.
- Formulare mit CSRF-Token: Kontaktformulare und andere Formulare mit Sicherheits-Tokens erzeugen bei jedem Aufruf einen neuen Token. Wird das Formular gecacht, ist der Token bei Einreichung bereits abgelaufen, und das Formular schlägt fehl.
- Suchseiten: Suchergebnisse sind von der Suchanfrage abhängig und in den meisten Fällen zu individuell für einen sinnvollen Cache-Gewinn.
- Seiten mit personalisierten Widgets: Empfehlungen, zuletzt angesehene Produkte und ähnliche dynamische Blöcke dürfen nicht gecacht werden.
Die meisten Caching-Plugins kennen diese Ausnahmen und setzen sie bei WooCommerce automatisch. Prüfen lässt sich die Konfiguration mit einem einfachen Test: Legen Sie zwei verschiedene Artikel in den Warenkorb, öffnen Sie die Warenkorb-Seite im Inkognito-Modus und prüfen Sie, ob sie leer ist. Ist sie leer, funktioniert die Ausnahme.
Für WooCommerce-Shops gibt es weitere, tiefere Performance-Stellschrauben, die über Caching hinausgehen. Der Artikel WooCommerce beschleunigen deckt diese ab.
Praxisbeispiel: Caching auf einer mittelständischen Unternehmenswebsite
In einem Projekt betreuten wir die Website eines Handwerksbetriebs mit zehn Seiten, einem Kontaktformular und einer Bildergalerie. Die Website lief auf Shared Hosting, kein Caching war aktiv. Der gemessene LCP lag bei 4,2 Sekunden, der Google-Bericht zeigte ein rotes „Schlecht“.
Wir aktivierten WP Rocket mit den Standardeinstellungen, konfigurierten Cache-Control-Header für statische Ressourcen und kompremierten die Bilder einmalig. Das Kontaktformular wurde explizit aus dem Page-Cache ausgenommen, was WP Rocket in diesem Fall bereits automatisch erkannt hatte. Die Galerie-Bilder wurden in ein CDN ausgelagert.
Nach dem Eingriff: LCP 1,1 Sekunden, grünes „Gut“ im Google-Bericht. Die Hosting-Kosten blieben gleich. Der gesamte Konfigurationsaufwand lag unter zwei Stunden.
Das ist kein Einzelfall. Die Grundlagen-Optimierung, also Page-Cache aktivieren, Bilder komprimieren und Browser-Cache-Header setzen, ist fast immer die schnellste und kosteneffizienteste Maßnahme, bevor über Hosting-Wechsel oder teure Umbauten nachgedacht wird. Eine Gesamtbetrachtung, wo genau Ihre Website Zeit verliert, bietet das Hosting-Ratgeber als Ausgangspunkt.
- Ist ein Caching-Plugin aktiv und konfiguriert (WP Rocket, W3 Total Cache oder WP Super Cache)?
- Liefert der Server
Cache-Control-Header für statische Ressourcen (CSS, JS, Bilder)? - Sind Warenkorb, Checkout und Login-Bereiche ausdrücklich vom Page-Cache ausgenommen?
- Liefert der Server nach Updates nicht weiterhin veraltete CSS- oder JS-Dateien aus (Cache-Busting aktiv)?
- Ist der Warenkorb-Test bestanden (Inkognito-Aufruf zeigt leeren Warenkorb)?
- Ist OPcache auf dem Server aktiv (
opcache.enable=1)? - Laufen kein Hosting-Cache und kein Plugin-Cache gleichzeitig, ohne aufeinander abgestimmt zu sein?
- Sind große Bilder komprimiert, bevor der Cache sie ausliefert?
- Page-Caching ist der größte Einzelhebel für WordPress-Ladezeiten. Er spart die teuerste Phase des Seitenaufrufs vollständig ein.
- Browser-Cache, Page-Cache, Objekt-Cache und OPcache arbeiten auf verschiedenen Ebenen. Wer nur eine aktiviert, lässt Potenzial liegen.
- Dynamische Inhalte wie Warenkorb, Checkout, Login und Formulare dürfen niemals gecacht werden. Falsch konfiguriertes Caching richtet mehr Schaden an als kein Caching.
- WP Rocket ist die empfehlenswerteste kostenpflichtige Lösung, WP Super Cache die einfachste kostenlose. W3 Total Cache bietet den größten Funktionsumfang bei höherer Konfigurationskomplexität.
Häufige Fragen
Muss ich den Cache nach jedem WordPress-Update leeren?
Ja, zumindest den Page-Cache. Nach einem Plugin- oder Theme-Update kann der Cache noch alte Versionen von CSS- oder JavaScript-Dateien enthalten, was zu Darstellungsfehlern führt. WP Rocket und W3 Total Cache leeren den Cache nach Updates automatisch. Prüfen Sie diese Einstellung und führen Sie nach größeren Updates einmal manuell einen Cache-Clear durch.
Kann ich zwei Caching-Plugins gleichzeitig betreiben?
Davon ist abzuraten. Zwei Page-Caching-Mechanismen, die für dieselbe URL zuständig sind, können sich gegenseitig blockieren oder widersprüchliche Dateien erzeugen. Wenn Ihr Hoster bereits server-seitiges Caching einsetzt, sollte das Plugin wissen, dass es damit zusammenarbeiten soll, nicht dagegen. WP Rocket und Kinsta zum Beispiel sind aufeinander abgestimmt.
Warum sehe ich Änderungen auf meiner Website nicht, obwohl ich sie gerade gespeichert habe?
Der Cache liefert noch die alte Version aus. Leeren Sie den Cache im Plugin (die meisten haben einen Button im WordPress-Adminbereich) und laden Sie die Seite anschließend mit einem Hard Refresh im Browser neu (Windows: Strg+Shift+R, Mac: Cmd+Shift+R). Passiert das regelmäßig, verkürzen Sie die Cache-Lebensdauer oder konfigurieren Sie, dass der Cache nach jedem Speichern automatisch geleert wird.
Bringt Caching auch etwas, wenn meine Website schon schnell genug ist?
Caching hilft besonders unter Last. Eine Seite, die bei einem einzelnen Besucher in 1,5 Sekunden lädt, kann bei 50 gleichzeitigen Besuchern deutlich langsamer werden, weil jede Anfrage den Server beansprucht. Mit Page-Caching bleibt die Ladezeit auch unter Besucherspitzen stabil, weil der Server nur Dateien ausliefert statt PHP zu starten.
Ist Caching auf Shared Hosting sinnvoll?
Ja, gerade dort ist es am sinnvollsten. Shared Hosting teilt Serverressourcen unter vielen Kunden, was bedeutet, dass PHP und Datenbank unter Last langsamer werden. Page-Caching entlastet diese Engpässe direkt, weil gecachte Seiten ohne PHP und Datenbank ausgeliefert werden. Auf Shared Hosting ist Caching deshalb keine Optimierung, sondern eine Grundvoraussetzung für verlässliche Ladezeiten.
Was ist der Unterschied zwischen Cache leeren und Cache-Preloading?
Cache leeren entfernt alle gespeicherten Seiten aus dem Cache. Die nächsten Besucher nach dem Leeren treffen auf einen leeren Cache und warten auf die erste, ungecachte Generierung. Cache-Preloading füllt den Cache proaktiv wieder auf, bevor Besucher auf die leere Version treffen. WP Rocket und W3 Total Cache bieten Preloading an und starten es automatisch nach dem Leeren.