Caching in WordPress richtig einrichten

Caching ist der wirksamste einzelne Hebel für eine schnelle WordPress-Seite und gleichzeitig der am meisten missverstandene. „Installier ein Cache-Plugin” greift zu kurz, weil Caching auf mehreren Ebenen passiert. Wer die Ebenen kennt, trifft die richtige Entscheidung, statt drei sich überschneidende Plugins zu stapeln, die sich gegenseitig ins Gehege kommen. Dieser Artikel ist als Anleitung gebaut: erst die Ebenen, dann die Einrichtung in Reihenfolge, dann das Prüfen, ob es wirklich wirkt.

Was Caching überhaupt tut

WordPress baut jede Seite bei jedem Aufruf neu zusammen: PHP läuft, die Datenbank wird abgefragt, HTML entsteht, das Ergebnis geht an den Browser. Dieser Aufbau kostet Zeit, sichtbar als hohe Time to First Byte (TTFB), dem Moment, bis der Server das erste Byte schickt. Caching speichert das Ergebnis zwischen, sodass beim nächsten Aufruf die fertige Version ausgeliefert wird, ohne den ganzen Aufwand. Das senkt vor allem die TTFB und damit den LCP spürbar und entlastet den Server bei Lastspitzen.

Die Cache-Ebenen, von außen nach innen

Jede Ebene löst ein anderes Problem. Welche du brauchst, hängt davon ab, was bei dir langsam ist.

1. Browser-Cache (statische Dateien beim Besucher)

Bilder, CSS und JavaScript werden im Browser des Besuchers zwischengespeichert. Gesteuert wird das über Antwort-Header, vor allem Cache-Control (und das ältere Expires). Mit max-age legst du fest, wie viele Sekunden eine Datei als frisch gilt. Das Muster, das sich dafür eingebürgert hat: Dateien, deren URL sich bei jeder Änderung mitändert, bekommen eine sehr lange Laufzeit, das HTML selbst bleibt kurz oder muss vor jeder Wiederverwendung validiert werden (no-cache). WordPress hängt an eingebundene Skripte und Stylesheets standardmäßig einen Versionsparameter wie ?ver=…, deshalb eignen sie sich für lange Laufzeiten.

Sinnvoll ist das praktisch immer. Es kostet nichts, wirkt aber nur bei wiederkehrenden Besuchern und beim Wechsel zwischen Seiten, nicht beim ersten Aufruf. Die Regeln für Apache oder Nginx erzeugt dir der Generator:

Auch als eigenständige Seite mit allen Anleitungen: Caching-Generator.

2. Page-Cache (das fertige HTML)

Die größte Wirkung für normale Besucher. Die komplette Seite wird als statisches HTML zwischengespeichert. Es gibt zwei Wege:

• Server-Caching (z. B. über den Webserver oder einen Reverse-Proxy wie Varnish oder den Nginx-FastCGI-Cache). Die schnellste Variante, weil PHP gar nicht erst startet, der Server liefert die gespeicherte Datei direkt aus. Sofern dein Hosting das bietet: die erste Wahl.
• Plugin-Caching (ein WordPress-Plugin erzeugt statische Dateien). Solide Alternative, wenn kein Server-Cache verfügbar ist. Nicht beides parallel, das führt zu Konflikten und Anzeigefehlern.

Technisch läuft ein Plugin-Page-Cache über einen Mechanismus, den WordPress selbst vorsieht: die Datei wp-content/advanced-cache.php. Mehr dazu weiter unten bei WP_CACHE.

3. Object-Cache (Datenbankergebnisse)

Speichert wiederkehrende Datenbankabfragen im Arbeitsspeicher, üblicherweise mit Redis oder Memcached. WordPress hat einen eingebauten Object-Cache, der aber nur für die Dauer einer einzelnen Anfrage lebt. Erst ein persistenter Object-Cache überlebt den Seitenaufruf. Er wird über die Datei wp-content/object-cache.php eingehängt, ein sogenanntes Drop-in: Liegt sie dort, lädt WordPress sie beim Start als externen Object-Cache.

Ein Nebeneffekt, der selten erwähnt wird: Transients landen ohne persistenten Object-Cache in der Tabelle wp_options. Mit einem Memcached- oder Redis-Plugin legt WordPress sie stattdessen im schnellen Speicher ab (so beschreibt es die WordPress-Entwicklerdoku zu Transients). Das entlastet die Datenbank zusätzlich.

Wann lohnt er sich? Dort, wo der Page-Cache absichtlich aussetzt: eingeloggte Bereiche, WooCommerce, Mitgliederportale, Seiten mit vielen dynamischen Abfragen. Auf einem kleinen Blog mit statischen Inhalten bringt er wenig. Mehr zu den Hebeln im Shop findest du in WooCommerce schneller machen.

4. OPcache (kompilierter PHP-Code)

OPcache gehört zu PHP, nicht zu WordPress. Er hält den kompilierten PHP-Code im Speicher, damit PHP die Dateien nicht bei jeder Anfrage neu einliest und übersetzt. Laut PHP-Handbuch ist opcache.enable standardmäßig an, opcache.memory_consumption steht auf 128 MB und opcache.validate_timestamps ist aktiv (Prüfintervall opcache.revalidate_freq standardmäßig 2 Sekunden). Auf den meisten aktuellen Hostings läuft er bereits. Prüf das in der phpinfo()-Ausgabe oder frag deinen Hoster. Sehr viele Plugins und ein großer Dateibestand können opcache.max_accelerated_files (Standard 10000) ausreizen, dann fliegen Dateien wieder aus dem Cache. Eine passende PHP-Version bringt oft mehr als jede Feineinstellung.

5. CDN und Edge-Cache

Ein CDN legt Kopien deiner Dateien auf Servern nahe am Besucher ab. Für Bilder, CSS und JavaScript ist das die Regel und meist unkritisch. Beim HTML wird es heikel: Cloudflare etwa cacht laut eigener Dokumentation HTML und JSON standardmäßig nicht. Wer das ändert, muss selbst dafür sorgen, dass eingeloggte Nutzer und der Shop-Warenkorb ausgenommen sind. Ein CDN lohnt sich vor allem bei internationalem Publikum oder großen Mediendateien. Für eine regionale Firmenseite mit gutem Server-Cache ist es selten der erste Schritt.

Schritt für Schritt einrichten

Die Reihenfolge ist wichtig, weil jede Stufe auf der vorherigen aufbaut und du so immer weißt, was welchen Effekt hatte.

1. Ausgangswert messen. Notiere die TTFB vor jeder Änderung (siehe Abschnitt „Messen”). Ohne Vorher-Wert keine Aussage über den Nachher-Wert.
2. Hoster-Cache klären. Schau im Kundenbereich oder in der Doku, ob es einen serverseitigen Cache gibt, und ob er schon aktiv ist. Viele Hoster bieten so etwas an, jeder anders. Wenn ja, schalte ihn dort ein und installiere kein zweites Page-Cache-Plugin dazu.
3. Sonst: genau ein Page-Cache-Plugin. Installieren, Grundeinstellungen aktivieren, Page-Cache an. Mehr nicht. Minify, Lazy Load und Co. sind eigene Themen und lassen sich einzeln zuschalten und messen.
4. Ausschlüsse prüfen. Login, Warenkorb, Kasse, Konto (siehe unten).
5. Browser-Cache-Header setzen. Entweder über das Cache-Plugin, über die Serverkonfiguration oder die .htaccess.
6. Object-Cache nachrüsten, wenn du WooCommerce oder viele eingeloggte Nutzer hast und Redis oder Memcached zur Verfügung steht.
7. Wirkung prüfen und messen. Header kontrollieren, TTFB erneut messen, dann die Core Web Vitals.

Object-Cache mit Redis einrichten

Voraussetzung ist ein Redis-Server, den dein Hosting bereitstellt oder den du selbst betreibst. Auf geteiltem Hosting gibt es das oft nur in bestimmten Tarifen oder gar nicht. Das gängige Plugin „Redis Object Cache” (hier nur als Beispiel genannt) unterstützt laut seiner Plugin-Seite Predis, PhpRedis, Relay und mehr. Die Verbindung steuerst du über Konstanten in der wp-config.php, bei Bedarf auch mit Zugangsdaten und einem Präfix:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PREFIX', 'meine-seite_' );

Das Präfix ist wichtig, sobald mehrere WordPress-Installationen denselben Redis-Server nutzen: Ohne es teilen sie sich Schlüssel. Danach aktivierst du das Drop-in entweder in den Plugin-Einstellungen oder per WP-CLI:

wp redis enable

Dabei wird die Datei object-cache.php in wp-content angelegt. Prüfe nach dem Einschalten, ob die Seite normal lädt und der Site-Health-Test (siehe unten) den Object-Cache erkennt.

Prüfen, ob der Cache greift

„Aktiviert” heißt nicht „wirksam”. Es gibt drei Wege, das zu kontrollieren.

Antwort-Header mit curl ansehen

Ruf die Seite zweimal hintereinander ab und lass dir nur die Header geben:

curl -sI https://deine-domain.de/ | grep -iE 'cache|age|via|etag|last-modified|x-'

Beim ersten Abruf nach dem Leeren ist es meist ein Fehlschlag (MISS), beim zweiten ein Treffer (HIT). Welche Header dein Setup setzt, hängt vom Cache ab. Die WordPress-Quelltexte kennen für die Erkennung unter anderem diese Header: cache-control mit max-age, expires, age, x-cache, cf-cache-status, x-litespeed-cache, x-cache-status, x-proxy-cache und x-varnish. Bei Cloudflare gilt laut Dokumentation: HIT heißt, die Ressource kam aus dem Cloudflare-Cache, MISS war cachebar, aber nicht vorrätig, DYNAMIC ist nicht cachebar, BYPASS wurde zwar als cachebar eingestuft, die Antwort des Servers aber nicht. Setzt dein Hoster gar keinen sichtbaren Header, brauchst du den zweiten Weg.

Wichtig: Teste mit der echten Startseite und danach mit einer Seite, die nicht gecacht werden soll (Warenkorb, wp-login.php). Dort darf kein Treffer erscheinen.

Der Site-Health-Test in WordPress

Seit WordPress 6.1 prüft der Bereich Werkzeuge, Website-Zustand zwei Cache-Fragen, jeweils nur in einer Produktivumgebung. Der Page-Cache-Test fragt laut Core-Quelltext dreimal die Startseite ab, sucht nach Cache-Headern und bewertet die Antwortzeit (Standardschwelle 600 Millisekunden). Das Ergebnis ist „Page cache is detected and the server response time is good”, wenn beides passt, sonst eine Empfehlung. Beachte: Der Test erkennt Header, nicht deine Absicht. Ein Cache ohne passende Header wird übersehen.

Der Test zum persistenten Object-Cache hat drei mögliche Ergebnisse: „A persistent object cache is being used”, „A persistent object cache is not required” oder „You should use a persistent object cache” (in deutscher Oberfläche entsprechend übersetzt). Empfohlen wird er, wenn die Seite eine Schwelle überschreitet. Die Standardwerte im Core: 500 Autoload-Optionen bzw. 100.000 Byte dafür, oder je 1.000 Kommentare, Optionen, Beiträge, Begriffe oder Nutzer. Bei Multisite schlägt der Test ihn grundsätzlich vor. Hoster können diese Werte per Filter ändern, also muss deine Meldung nicht zu deinen Zahlen passen.

Direkt im Code

Auf der Kommandozeile prüfst du den Object-Cache so:

wp eval 'var_dump( wp_using_ext_object_cache() );'

true heißt, WordPress nutzt einen externen Object-Cache. Dazu passt: Liegt wp-content/object-cache.php nicht dort, ist es false.

WP_CACHE und advanced-cache.php

In der wp-config.php steht bei vielen Seiten diese Zeile:

define( 'WP_CACHE', true );

Laut WordPress-Doku schaltet sie kein Caching ein. Sie sorgt nur dafür, dass WordPress früh beim Start die Datei wp-content/advanced-cache.php lädt, falls sie existiert. Im Core steht dazu im Kommentar sinngemäß, dass es ein statisches Drop-in ist, weil man nur eines haben möchte. Das erklärt typische Fehlerbilder: Zwei Page-Cache-Plugins streiten um dieselbe Datei, und der Konstante allein ohne Datei fehlt jede Wirkung.

Cache richtig ausschließen

Der häufigste Caching-Fehler ist nicht ein fehlender, sondern ein falsch angewandter Cache. Diese Bereiche dürfen nie statisch ausgeliefert werden:

• Warenkorb, Kasse und Konto in WooCommerce, sonst sieht ein Kunde den Warenkorb eines anderen.
• Eingeloggte Bereiche: Mitgliederseiten, Kundenportale, das Admin-Backend.
• Formular- und Vorschau-Seiten mit personalisierten oder sitzungsabhängigen Inhalten.

WooCommerce setzt für diese Seiten laut seinem Quellcode (Klasse WC_Cache_Helper) die Konstante DONOTCACHEPAGE. Ein Cache-Plugin, das sie respektiert, lässt sie also aus. Unterstützt deins das nicht, musst du Warenkorb, Kasse und Mein Konto von Hand ausschließen. Zusätzlich nennt die WooCommerce-Doku Cookies, die auf einen aktiven Warenkorb oder eine Sitzung hindeuten: woocommerce_cart_hash, woocommerce_items_in_cart und wp_woocommerce_session_. Wer sie im Cache berücksichtigt, behandelt Kunden mit gefülltem Warenkorb richtig.

Teste nach der Einrichtung immer zwei Dinge: Login und Checkout, einmal als eingeloggter Nutzer und einmal im privaten Fenster. Lege einen Testartikel in den Warenkorb und prüfe in einem zweiten Browser, dass dort nichts auftaucht.

Wann wird der Cache geleert?

Ein Page-Cache muss wissen, wann eine gespeicherte Seite veraltet ist. Gute Lösungen leeren betroffene Seiten, wenn du einen Beitrag veröffentlichst oder aktualisierst, und räumen zusätzlich nach einer festgelegten Lebensdauer auf. Wie genau das passiert, unterscheidet sich je nach Plugin und Hoster, auch bei Menüs, Widgets, Kommentaren oder Theme-Änderungen. Du solltest deshalb einmal selbst prüfen: Beitrag ändern, speichern, die Seite im privaten Fenster neu laden. Zeigt sie noch den alten Stand, leere gezielt oder stelle die Lebensdauer kürzer. Pauschales Dauer-Leeren dagegen macht den Cache wirkungslos, weil jede Anfrage dann wieder ungecacht läuft.

Konflikte vermeiden

• Zwei Page-Cache-Plugins konkurrieren um dieselbe Datei advanced-cache.php. Ergebnis: Anzeigefehler, die mal da sind und mal nicht.
• Hoster-Cache plus Plugin-Cache doppelt die Arbeit. Im besten Fall bringt es nichts, im schlechten sehen Besucher alte Stände, weil du nur eine der beiden Ebenen geleert hast. Entscheide dich für eine Ebene als Page-Cache. Nutze das Plugin dann höchstens für die Dinge, die der Hoster nicht liefert, und schalte dessen Page-Cache ab. Bei vielen Hostings gibt es dafür eine eigene Anzeige oder ein mitgeliefertes Plugin, schau in die Doku deines Hosters.
• Object-Cache und Page-Cache sind dagegen kein Konflikt, sie ergänzen sich. Das Drop-in object-cache.php ist eine andere Datei als advanced-cache.php.
• CDN plus Plugin-Cache: Leere nach größeren Änderungen beide Ebenen, sonst liefert das CDN eine alte Version.

Messen: TTFB vorher und nachher

Der ehrlichste Wert für Caching ist die TTFB. Misse sie mit curl an der Startseite:

curl -o /dev/null -s -w 'connect: %{time_connect}s  ttfb: %{time_starttransfer}s\n' https://deine-domain.de/

Führe den Befehl mehrmals aus und nimm einen mittleren Wert statt eines Einzelschusses. Ein einzelner Messwert ist anfällig für Netzschwankungen. Wichtig ist der Vergleich: der erste Abruf nach dem Leeren (ungecacht) gegen die folgenden (gecacht). Zeigt sich zwischen beiden kein Unterschied, greift der Cache nicht. Für das Gesamtbild aus Sicht der Nutzer helfen Core Web Vitals.

Die typischen Fehler

• Mehrere Cache-Plugins gleichzeitig, sie überschreiben sich und verursachen schwer auffindbare Anzeigefehler.
• Cache nicht ausschließen, wo nötig, personalisierte Seiten gehören nie in den Page-Cache.
• Nach jeder Änderung Panik: Moderne Caches leeren sich bei Inhaltsänderungen selbst, nur bei sichtbaren Altständen gezielt leeren.
• Caching als Ersatz für Aufräumen: Ein Cache versteckt eine überladene Seite, er heilt sie nicht. Zu viele Plugins und eine aufgeblähte Datenbank bleiben ein Problem.

Wann Caching allein nicht reicht

Caching beschleunigt die Auslieferung, aber es ersetzt keine saubere Basis. Wenn eine Seite 40 Plugins lädt, riesige unoptimierte Bilder ausliefert oder auf einer überfüllten Datenbank läuft, kaschiert der Cache das nur für den ersten Eindruck. Der erste, ungecachte Aufruf, und den kann auch Googles Crawler erwischen, bleibt langsam. Caching gehört deshalb zusammen mit optimierten Bildern, schlanker Plugin-Auswahl und einer aufgeräumten Datenbank gedacht. Auch das Hosting setzt eine Grenze, worauf du in WordPress-Hosting: worauf achten nachlesen kannst.

Unsicher, welche Cache-Ebene bei deinem Setup wirklich etwas bringt? Schreib uns kurz, wir richten Caching sauber ein, ohne dass Warenkorb oder Login durcheinandergeraten. Dauerhaft im Blick bleibt das Ganze im Rahmen unserer WordPress-Wartung, zusammen mit Updates, Backups und Datenbankpflege.