Was ist ein Object Cache? Redis und Memcached für WordPress erklärt

Ein Object Cache speichert die Ergebnisse von Datenbankabfragen im Arbeitsspeicher, damit WordPress sie beim nächsten Mal nicht wieder aus der Datenbank holen muss. Das klingt unspektakulär. Bei Shops, Mitgliederseiten und allem mit vielen eingeloggten Nutzern macht es aber oft den größten Unterschied bei der Ladezeit. WordPress bringt zwar einen eigenen Object Cache mit, der vergisst jedoch nach jedem Seitenaufruf alles wieder. Erst mit Redis oder Memcached im Hintergrund wird daraus ein persistenter Object Cache, der Daten über viele Anfragen hinweg behält. In diesem Artikel erfährst du, wie das genau funktioniert, worin sich Redis und Memcached unterscheiden, wann sich der Aufwand lohnt und welche Fehler du beim Einrichten vermeiden solltest.

Was ist ein Object Cache in WordPress?

Jedes Mal, wenn jemand eine Seite deiner Website aufruft, setzt WordPress sie aus vielen Einzelteilen zusammen. Es lädt die Einstellungen der Website, die Menüs, die Widgets, den Beitrag selbst, die Daten des Autors, Kategorien, Schlagwörter und alles, was deine Plugins zusätzlich brauchen. Fast all das liegt in der Datenbank (MySQL oder MariaDB). Auf einer normalen Seite kommen so schnell 50 bis 150 Datenbankabfragen zusammen, mit WooCommerce und ein paar größeren Plugins auch deutlich mehr. Viele davon fragen bei jedem Aufruf genau dasselbe: Wie heißt die Website? Welche Plugins sind aktiv? Wie sieht das Hauptmenü aus?

Ein Object Cache merkt sich die Antworten auf solche Fragen. WordPress schaut zuerst im Cache nach, und nur wenn dort nichts liegt, geht die Anfrage an die Datenbank. Das Ergebnis landet anschließend im Cache und steht beim nächsten Mal sofort bereit. Der Name kommt daher, dass WordPress dort keine fertigen Seiten ablegt, sondern einzelne Datenobjekte: einen Beitrag, eine Liste von Optionen, die Metadaten eines Benutzers.

Stell dir einen Notizzettel neben der Tastatur vor. Statt jedes Mal im Aktenschrank zu suchen, schaust du zuerst auf den Zettel. Bei einer einzelnen Frage spart das kaum Zeit. Wenn dieselbe Frage aber tausendmal am Tag gestellt wird, sehr viel.

Wie funktioniert der Object Cache von WordPress?

WordPress hat seit vielen Jahren eine eigene Klasse für den Object Cache, WP_Object_Cache. Der Kern von WordPress und viele Plugins sprechen sie über Funktionen wie wp_cache_get() und wp_cache_set() an. Der Haken: Ohne zusätzliche Software lebt dieser Cache nur so lange wie ein einzelner Seitenaufruf. Sobald die Seite ausgeliefert ist, ist der Speicher wieder leer, und beim nächsten Besucher geht alles von vorn los.

Nutzlos ist dieser nicht persistente Cache trotzdem nicht, denn er verhindert doppelte Abfragen innerhalb eines Aufrufs. Richtig interessant wird es aber erst mit einem persistenten Object Cache. Dafür liegt eine Datei namens object-cache.php im Ordner wp-content. WordPress erkennt sie beim Start automatisch und nutzt dann statt des eigenen Zwischenspeichers einen externen Dienst wie Redis oder Memcached. Die Daten bleiben dort über viele Seitenaufrufe hinweg erhalten, bis sie ablaufen, sich ändern oder der Speicher voll ist. Diese Datei musst du nicht selbst schreiben. Plugins wie Redis Object Cache bringen sie mit und legen sie beim Aktivieren an die richtige Stelle.

Ein Nebeneffekt, den viele nicht kennen, betrifft die sogenannten Transients. Das sind zwischengespeicherte Werte mit Ablaufdatum, die Plugins gern nutzen, zum Beispiel für Antworten externer APIs. Ohne persistenten Object Cache landen Transients in der Tabelle wp_options und blähen sie mit der Zeit auf. Mit Redis oder Memcached wandern sie in den Arbeitsspeicher, und die Datenbank bleibt schlanker.

Object Cache, Page Cache und OPcache: Was ist der Unterschied?

Sobald es um WordPress und Caching geht, fallen schnell drei Begriffe, die gern durcheinandergeraten. Sie arbeiten auf verschiedenen Ebenen und ergänzen sich, statt sich gegenseitig zu ersetzen.

• Page Cache: speichert die komplett fertige Seite als HTML und liefert sie aus, ohne WordPress überhaupt zu starten. So arbeiten zum Beispiel WP Rocket, LiteSpeed Cache oder WP Super Cache. Schneller geht es nicht, allerdings nur, solange alle Besucher dieselbe Seite sehen.
• Object Cache: speichert einzelne Ergebnisse aus der Datenbank. WordPress läuft weiterhin bei jedem Aufruf, muss die Datenbank aber deutlich seltener fragen.
• OPcache: hat mit deinen Daten gar nichts zu tun. Er sorgt dafür, dass PHP die Dateien von WordPress nicht bei jedem Aufruf neu einlesen und übersetzen muss. Auf fast jedem Hosting ist er heute schon aktiv.

Der wichtigste Punkt dabei: Ein Page Cache hilft nur bei Seiten, die für alle gleich aussehen. Sobald jemand eingeloggt ist, etwas in den Warenkorb legt oder im Backend arbeitet, wird er umgangen. Genau dort springt der Object Cache ein. Für einen Blog mit fast nur anonymen Lesern bringt ein guter Page Cache deshalb mehr. Bei einem Shop, einer Lernplattform oder einem Forum ist der Object Cache oft der größere Hebel.

Redis vs. Memcached: Welcher Object Cache passt zu WordPress?

Beide Systeme halten Daten im Arbeitsspeicher und legen sie als einfache Paare aus Schlüssel und Wert ab. Als Object Cache sind beide schnell genug. Die Unterschiede stecken in den Details.

Redis ist heute die übliche Wahl für WordPress. Es kann mehr als nur Schlüssel und Werte speichern, zum Beispiel Listen, Hashes und Sets, und es schreibt seinen Inhalt auf Wunsch auf die Festplatte, sodass der Cache einen Neustart übersteht. Dazu kommen Replikation, ein feineres Rechtesystem und ein großes Ökosystem. Für WordPress gibt es mit Redis Object Cache außerdem ein sehr verbreitetes und gut gepflegtes Plugin. Nach einem Lizenzwechsel bei Redis im Jahr 2024 ist zusätzlich Valkey entstanden, ein freier Fork unter dem Dach der Linux Foundation, den inzwischen viele Hoster einsetzen. Für WordPress verhält er sich genauso wie Redis, du merkst davon in der Regel nichts.

Memcached ist älter und bewusst schlicht. Es kennt nur Schlüssel und Werte, speichert nichts dauerhaft und verliert bei jedem Neustart seinen gesamten Inhalt. Dafür nutzt es mehrere Prozessorkerne gleichzeitig und lässt sich sehr einfach auf mehrere Server verteilen. Eine Grenze, die bei WordPress gelegentlich auffällt: Ein einzelner Eintrag darf standardmäßig höchstens 1 MB groß sein. Bei sehr großen Optionen, etwa aufgeblähten Einstellungen mancher Page Builder, kann das zu Problemen führen.

Unsere Empfehlung: Wenn dein Hoster beides anbietet, nimm Redis. Wenn nur Memcached zur Verfügung steht, ist das kein Grund zur Sorge, als Object Cache reicht es völlig. Viel wichtiger als die Wahl zwischen den beiden ist, dass überhaupt ein persistenter Object Cache läuft und vernünftig konfiguriert ist. Ein dritter Kandidat ist übrigens APCu, ein Zwischenspeicher direkt in PHP. Er kommt ohne eigenen Dienst aus, funktioniert aber nur auf einem einzelnen Server und spielt in der Praxis eine kleinere Rolle.

Wann lohnt sich ein persistenter Object Cache?

Ein Object Cache ist kein Wundermittel. Wie viel er bringt, hängt davon ab, wie viele Anfragen am Page Cache vorbei direkt bei WordPress landen und wie viel Arbeit die Datenbank dabei hat. Besonders spürbar ist der Effekt bei:

• Shops mit WooCommerce, denn Warenkorb, Kasse und Kundenkonto kommen nie aus dem Page Cache.
• Mitgliederseiten, Lernplattformen und Foren mit vielen eingeloggten Nutzern.
• Redaktionen, in denen mehrere Leute gleichzeitig im Backend arbeiten.
• Websites mit vielen Plugins, die ihre Daten in Optionen und Transients ablegen.
• Großen Websites mit tausenden Beiträgen, Begriffen oder Benutzern.

WordPress selbst gibt dir dabei einen Hinweis. Seit Version 6.1 empfiehlt der Zustandsbericht unter Werkzeuge einen persistenten Object Cache, sobald deine Website bestimmte Größen überschreitet, zum Beispiel mehr als 1.000 Beiträge, Kommentare oder Benutzer.

Wenig bringt ein Object Cache dagegen bei einer kleinen Unternehmensseite mit zehn Unterseiten, die fast nur anonyme Besucher hat und schon einen guten Page Cache nutzt. Dort beantwortet der Page Cache ohnehin fast jede Anfrage, bevor WordPress überhaupt startet.

Wie richte ich einen Object Cache mit Redis in WordPress ein?

Der genaue Weg hängt von deinem Hosting ab. Bei vielen Managed Hostern ist Redis schon vorhanden und lässt sich mit einem Schalter im Kundenmenü aktivieren, manche richten sogar alles selbst ein. Frag im Zweifel kurz beim Support nach, bevor du selbst etwas installierst. Auf einem eigenen Server läuft es meist so ab:

1. Redis installieren und starten, unter Debian oder Ubuntu zum Beispiel mit dem Paket redis-server.
2. Die Erweiterung phpredis für PHP installieren (Paket php-redis), damit PHP mit Redis sprechen kann. Das Plugin bringt mit Predis zwar eine Variante ganz ohne Erweiterung mit, die ist aber spürbar langsamer.
3. Die Verbindungsdaten in der wp-config.php eintragen, und zwar oberhalb der Zeile, die das Ende der Bearbeitung markiert.
4. Das Plugin Redis Object Cache installieren und in seinen Einstellungen den Object Cache aktivieren. Dabei legt es die Datei object-cache.php an.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'meineseite_' );
define( 'WP_REDIS_MAXTTL', 86400 );

Den Präfix solltest du immer setzen, sobald mehrere Websites dieselbe Instanz von Redis nutzen. Ohne ihn können sich zwei Installationen gegenseitig Daten überschreiben, und das führt zu sehr merkwürdigen Fehlern. Wer lieber auf der Kommandozeile arbeitet, erledigt den letzten Schritt mit wp plugin install redis-cache --activate und anschließend wp redis enable. Für große Shops gibt es außerdem die kostenpflichtige Lösung Object Cache Pro.

Welche Fehler passieren beim Object Cache am häufigsten?

Ein Object Cache ist schnell eingerichtet, aber ein paar Stolperfallen tauchen immer wieder auf.

• Kein Speicherlimit: Ohne maxmemory wächst Redis, bis der Server keinen Speicher mehr hat. Mit Limit, aber der Standardrichtlinie noeviction, lehnt Redis neue Einträge ab, sobald der Speicher voll ist, und WordPress wirft plötzlich Fehler. Für einen Cache ist allkeys-lru die richtige Wahl: Redis wirft dann einfach die Einträge raus, die am längsten nicht gebraucht wurden.
• Redis offen im Internet: Redis sollte nur auf 127.0.0.1 oder im privaten Netz erreichbar sein und ein Passwort haben. Offene Instanzen auf Port 6379 werden im Netz gezielt gesucht und missbraucht.
• Veraltete Daten nach direkten Änderungen: Wer Daten direkt in der Datenbank ändert, etwa mit phpMyAdmin oder bei einem Import, geht am Cache vorbei. WordPress zeigt dann weiter die alten Werte. Leere den Cache danach, entweder in den Einstellungen des Plugins oder mit wp cache flush.
• Vergessene object-cache.php nach einem Umzug: Ziehst du auf einen Server ohne Redis um, bleibt die Datei manchmal im Ordner wp-content liegen. Im harmlosen Fall erscheint nur ein Hinweis im Adminbereich, im ungünstigen Fall bricht WordPress mit einem fatalen Fehler ab. Dann hilft es, die Datei per FTP zu löschen.
• Redis auf einem entfernten Server: Jeder Zugriff auf den Cache kostet dann einen Weg durchs Netzwerk. Bei Hunderten Zugriffen pro Seitenaufruf frisst die Latenz einen Teil des Vorteils wieder auf. Redis gehört deshalb möglichst auf denselben Server oder zumindest ins selbe Rechenzentrum.

maxmemory 256mb
maxmemory-policy allkeys-lru

Diese beiden Zeilen in der redis.conf reichen für die meisten Websites. Wie viel Speicher du brauchst, hängt von der Größe der Website ab. Für einen normalen Shop sind 256 MB ein guter Startwert.

Wie prüfe ich, ob der Object Cache funktioniert?

Ob der Cache wirklich arbeitet, siehst du auf mehreren Wegen:

• Im Plugin: Redis Object Cache zeigt in seinen Einstellungen, ob eine Verbindung besteht, und liefert eine kleine Statistik zu Treffern und Fehlgriffen.
• Auf der Kommandozeile: wp cache type verrät, welcher Object Cache aktiv ist. Steht dort Default, läuft kein persistenter Cache.
• Mit Query Monitor: Das kostenlose Plugin zeigt für jeden Seitenaufruf die Trefferquote des Object Cache und die Zahl der Datenbankabfragen. Vergleich die Werte einmal mit und ohne Cache, der Unterschied ist oft größer als gedacht.
• Direkt in Redis: redis-cli info stats liefert unter anderem keyspace_hits und keyspace_misses. Bleibt die Trefferquote nach ein paar Stunden Betrieb dauerhaft niedrig, stimmt meist etwas mit der Konfiguration nicht, zum Beispiel ein zu kleines Speicherlimit.

Wie InspectWP dir hilft, das Caching deiner Website einzuschätzen

Ein Object Cache arbeitet auf dem Server, von außen ist er nicht direkt zu sehen. Seine Wirkung schon. Der Bericht von InspectWP misst unter anderem die Time to First Byte, also wie lange der Server braucht, bis das erste Byte der Seite ankommt. Werte über 800 Millisekunden markiert InspectWP als Warnung, und genau dort hilft ein Object Cache, wenn die Seite nicht aus dem Page Cache kommt. Außerdem erkennt InspectWP, welche Plugins für das Caching im Einsatz sind, darunter auch Redis Object Cache anhand des kurzen Kommentars, den das Plugin standardmäßig im Quelltext hinterlässt. Zusammen mit den Angaben zu Hoster, Server und der Version von PHP bekommst du so schnell ein Gefühl dafür, ob beim Caching einer Website noch Luft nach oben ist.