Ein Redis Object Cache lohnt sich bei Anfragen, die ein Page Cache nicht beantworten kann, vor allem für angemeldete Benutzer, Warenkörbe und den Admin-Bereich. Er hält die Ergebnisse von WordPress-Datenbankabfragen im Arbeitsspeicher, sodass spätere Anfragen diese Abfragen überspringen. Eine kleine Website, deren Seiten alle aus einem Page Cache kommen, gewinnt wenig.
Was macht ein Object Cache in WordPress?
WordPress bringt einen Object Cache mit, der standardmäßig nur eine Anfrage lang hält. Optionen, Beiträge, Terme und die Ergebnisse vieler Plugin-Abfragen werden in den PHP-Speicher geladen und verworfen, sobald die Seite fertig ist.
Ein Drop-in unter wp-content/object-cache.php ersetzt diesen Cache und legt dieselben Daten in einem Server wie Redis ab. Jede Anfrage kann dann wiederverwenden, was frühere Anfragen geladen haben, und die Datenbank beantwortet weniger Abfragen.
Ein Page Cache arbeitet eine Ebene höher. Er speichert fertiges HTML und antwortet fast oder ganz ohne PHP. Mit einem Object Cache baut WordPress die Seite weiterhin selbst auf, muss dabei aber seltener zur Datenbank. Eine Website kann beides nutzen.
Wann lohnt er sich?
| Anfrage oder Website | Wirkung | Grund |
|---|---|---|
| Anfrage oder Website: Warenkorb, Kasse und Kontoseiten | Wirkung: Lohnt sich | Grund: Sie können nicht aus einem Page Cache kommen und lesen bei jeder Anfrage Produkt-, Sitzungs- und Benutzerdaten |
| Anfrage oder Website: Angemeldete Benutzer und Admin-Bereich | Wirkung: Lohnt sich | Grund: Redakteure, Shop-Manager und Mitglieder bekommen keine Treffer aus dem Page Cache |
| Anfrage oder Website: Shops und mehrsprachige Websites | Wirkung: Lohnt sich | Grund: WooCommerce, WPML und WCML fragen Produkte, Terme, Übersetzungen und Währungen immer wieder ab |
| Anfrage oder Website: Seiten mit vielen Abfragen | Wirkung: Lohnt sich | Grund: Große Menüs, Filter, ähnliche Beiträge und Page Builder stellen Abfragen, die der Cache beantworten kann |
| Anfrage oder Website: Kleine Website mit anonymen Besuchern | Wirkung: Gering | Grund: Der Page Cache beantwortet fast jede Anfrage |
| Anfrage oder Website: Freitextsuche | Wirkung: Gering | Grund: Jeder Suchbegriff ist eine neue Abfrage, daher lässt sich wenig wiederverwenden |
WordPress gibt selbst einen Hinweis. Seit Version 6.1 empfiehlt der Website-Zustand (Site Health) einen persistenten Object Cache, wenn eine Website bestimmte Schwellen überschreitet. Das sind zum Beispiel 1.000 Beiträge, Terme, Benutzer, Kommentare oder Optionen oder 500 automatisch geladene Optionen.
Was brauche ich dafür?
- Einen Redis-Server auf demselben Host oder erreichbar über ein internes Netz oder TLS.
- Einen PHP-Client. phpredis ist eine kompilierte Erweiterung, Predis eine PHP-Bibliothek. Welche davon akzeptiert wird, hängt vom Plugin ab.
- Ein Plugin, das den Drop-in installiert.
- Ein Speicherlimit in Redis und eine Eviction Policy (siehe unten).
Drei Befehle zeigen, was ein Server schon mitbringt. wp cache type gibt Default aus, solange kein persistenter Cache aktiv ist.
php -m | grep -i redis
redis-cli ping
wp cache typeWelche Fallstricke gibt es?
Eine geteilte Redis-Datenbank
Manche Hoster geben mehreren Websites dieselbe Redis-Datenbank. Ohne Schlüsselpräfix überschreiben zwei WordPress-Websites gegenseitig ihre Optionen. Geben Sie jeder Website in der wp-config.php ein eigenes Präfix, der Name der Konstante hängt vom Plugin ab. Die Redis-Dokumentation rät davon ab, nummerierte Datenbanken für voneinander unabhängige Anwendungen zu nutzen.
Leeren des Caches
WordPress und viele Plugins leeren den Object Cache nach Updates und Importen. FLUSHDB leert die ganze Datenbank, auch die Daten aller anderen darauf. Auf einer geteilten Datenbank darf das Leeren nur die eigenen Schlüssel löschen, und das dauert länger. Eine eigene Datenbank vermeidet das Problem.
Speicherlimit und Eviction
Auf einem 64-Bit-System hat Redis standardmäßig kein Speicherlimit. Ist ein Limit gesetzt, entscheidet maxmemory-policy, was beim Erreichen passiert. Unter allkeys-lru entfernt Redis die am längsten nicht genutzten Schlüssel, und der Cache arbeitet weiter. Unter noeviction, dem Standard von Redis, funktioniert das Lesen weiter, neue Schreibzugriffe schlagen fehl.
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policyAusfälle
Hängt Redis, macht ein Drop-in, der bei jedem Cache-Aufruf das Timeout abwartet, eine Seite mit Hunderten von Aufrufen weit langsamer als eine Website ohne Cache. Prüfen Sie, ob Ihr Plugin Redis nach dem ersten fehlgeschlagenen Aufruf nicht mehr verwendet.
Nach einem Ausfall kann Redis außerdem Werte enthalten, die sich in der Datenbank inzwischen geändert haben. Der Cache muss dann einmal geleert werden.
Woran erkenne ich, dass es funktioniert?
Redis zählt Treffer (HIT) und Fehlschläge (MISS). Die Trefferquote ist keyspace_hits geteilt durch die Summe aus keyspace_hits und keyspace_misses. Steigt der Wert evicted_keys, ist das Speicherlimit für die Website zu niedrig.
redis-cli INFO stats | grep -E "keyspace_|evicted_keys"Eine hohe Trefferquote allein beweist wenig. Messen Sie die Datenbankabfragen und die Time to First Byte (TTFB) einer nicht gecachten Seite, jeweils mit und ohne Cache. Query Monitor zeigt die Abfragen je Anfrage.
Wie geht CachePilot damit um?
CachePilot ist das Plugin, um das es auf dieser Website geht. So behandelt es die genannten Fallstricke:
- Geteilte Datenbanken. Schlüssel tragen ein Präfix. Findet die Einrichtung Schlüssel einer anderen Anwendung, bleibt das Leeren auf dieses Präfix beschränkt.
- Ausfälle. Nach einem Verbindungsfehler überspringt der Drop-in Redis für 30 Sekunden und leert den Cache einmal, wenn Redis zurückkommt.
- Round Trips. SMEMBERS liest die Liste der Schlüssel, die eine Seite verwendet, MGET lädt ihre Werte. In einem Live-Shop senkte das im November 2026 die Redis-Befehle einer nicht gecachten Shop-Seite von 691 auf 61. Die Serverzeit im Frontend lag 10 bis 15 % unter der mit Redis Object Cache 3.0.0 (Methode).
Die Seite zum Object Cache beschreibt den Drop-in vollständig.
Quellen
- WordPress-Entwicklerreferenz, WP_Object_Cache: standardmäßig nicht persistent, Ersatz durch einen Drop-in.
- WordPress-Entwicklerreferenz, Prüfung des Website-Zustands für einen Object Cache: Schwellenwerte des Website-Zustands.
- WP-CLI, wp cache type.
- Redis-Dokumentation, Key Eviction: maxmemory, Policies, Trefferquote aus INFO stats.
- Redis-Dokumentation, SELECT: nummerierte Datenbanken.
- phpredis und Predis.
- object-cache.php und Setup.php (src/Autopilot) des Plugins: Ausfallverhalten, Prefetch und Erkennung geteilter Datenbanken.
