// <a href="https://hosting-fixers.de/category/pagespeed/" rel="category tag">Pagespeed</a>
Redis vs. Memcached für WordPress: Welcher Object-Cache ist besser?
Redis und Memcached sind In-Memory-Datenbanken, die als persistenter Object-Cache für WordPress eingesetzt werden. Beide speichern häufig abgerufene Datenbankabfragen im RAM und vermeiden so wiederholte Datenbankzugriffe. Der Unterschied liegt in der Tiefe: Redis ist eine vollwertige Datenstruktur-Engine mit Persistenz, Replikation und komplexen Datentypen. Memcached ist ein schlanker, schneller Key-Value-Store ohne Persistenz – einfach zu betreiben, aber in den Möglichkeiten begrenzt.
TL;DR – Die wichtigsten Punkte
- Beide reduzieren Datenbankabfragen um bis zu 90 % und senken den TTFB messbar
- Redis ist die bessere Wahl für WordPress: Datenpersistenz, WooCommerce-Sessions und Multisite-Isolation
- Memcached ist schneller im reinen Lese-Throughput, verliert aber alle Daten bei Neustart
- Auf Shared Hosting ist Memcached häufiger verfügbar; auf VPS/Root-Servern empfiehlt sich Redis
- Ohne site-scope-Isolierung bei Multisite kann ein FLUSH_ALL alle Sites gleichzeitig leeren
- Der WordPress Object-Cache wird als Drop-in (object-cache.php) in wp-content eingebunden
Was ist ein WordPress Object-Cache?
WordPress verfügt von Haus aus über einen internen Object-Cache (WP_Object_Cache), der Datenbankabfragen innerhalb eines einzelnen Seitenaufrufs zwischenspeichert. Dieser Cache ist nicht persistent: Nach dem Seitenaufruf werden alle gespeicherten Daten verworfen. Beim nächsten Request beginnt WordPress von vorne.
Ein persistenter Object-Cache löst dieses Problem: Redis oder Memcached speichern die Abfrageergebnisse über einzelne Requests hinaus im RAM. Folglich bekommt der zweite Besucher dieselben Datenbankwerte direkt aus dem Cache – ohne einen einzigen MySQL-Query. Das reduziert die Datenbanklast bei typischen WordPress-Installationen um 60–90 % und senkt den TTFB messbar. Zum Beispiel sinkt die Datenbankauslastung auf einem WooCommerce-Shop mit 1.000 Produkten nach der Redis-Aktivierung häufig auf ein Zehntel des ursprünglichen Wertes.
Redis vs. Memcached: Der direkte Vergleich
| Eigenschaft | Redis | Memcached |
|---|---|---|
| Datenstrukturen | Strings, Lists, Sets, Hashes, Sorted Sets | Nur Strings (Key-Value) |
| Persistenz | Ja – RDB-Snapshots + AOF-Log | Nein – Neustart = Datenverlust |
| Replikation | Ja – Master-Replica, Sentinel, Cluster | Nein – nicht nativ |
| Multisite-Isolation | Separate Datenbanken (0–15) | Key-Präfix nötig, FLUSH_ALL löscht alles |
| WooCommerce-Sessions | Ideal – persistente Hashes | Sessions gehen bei Neustart verloren |
| Lese-Throughput | ~100.000 ops/s (Single-Thread) | ~200.000 ops/s (Multi-Thread) |
| Shared Hosting | Selten verfügbar | Häufig verfügbar (cPanel) |
| VPS / Root-Server | Standard-Empfehlung | Verfügbar |
Redis – Vorteile und Nachteile
Vorteile: Datenpersistenz nach Neustart (RDB-Snapshot oder AOF-Log), komplexe Datenstrukturen (Hashes, Listen, Sets), sichere Multisite-Isolation über separate Datenbank-IDs, Pub/Sub für Background-Jobs, Lua-Scripting für atomare Cache-Invalidierung.
Nachteile: Höherer Basis-RAM-Verbrauch als Memcached, Single-Thread-Architektur (bei extremem Parallelzugriff Nachteil), Konfiguration von Persistenz und Eviction-Policy erforderlich.
Memcached – Vorteile und Nachteile
Vorteile: Multi-Thread-Architektur für hohen parallelen Lese-Throughput, geringer Speicheroverhead, weit verbreitet auf Shared Hosting ohne Root-Zugriff, einfache Konfiguration ohne Persistenz-Einstellungen.
Nachteile: Kein Persist – Server-Neustart leert den gesamten Cache (Cold-Start-Problem), FLUSH_ALL-Risiko bei Multisite ohne Key-Präfix-Strategie, nur String-Datentyp, keine native Replikation für Hochverfügbarkeit.
Redis für WordPress konfigurieren – Schritt für Schritt
- Redis installieren (Root erforderlich): apt install redis-server (Debian/Ubuntu) oder yum install redis (AlmaLinux). Danach: systemctl enable redis und systemctl start redis.
- PHP-Extension prüfen: php -m | grep redis – die phpredis-Extension muss geladen sein.
- wp-config.php erweitern vor dem That-is-all-Kommentar: define WP_REDIS_HOST 127.0.0.1, define WP_REDIS_PORT 6379, define WP_REDIS_DATABASE 0 (pro Site eigene Nummer), define WP_REDIS_PREFIX domain_ (Multisite-Isolierung).
- Drop-in installieren: Plugin Redis Object Cache aktivieren, im Dashboard auf Enable Object Cache klicken. Die object-cache.php wird automatisch in wp-content/ kopiert.
- Verifizieren: wp cache type via WP-CLI sollte Redis ausgeben. Im Admin unter Einstellungen → Redis: Status Connected.
Empfohlene Redis-Konfiguration für WordPress (/etc/redis/redis.conf)
maxmemory 256mb – Speicherlimit setzen. maxmemory-policy allkeys-lru – entfernt zuletzt am wenigsten genutzte Einträge wenn Speicher voll ist. bind 127.0.0.1 – kein Netzwerkzugriff von außen. tcp-keepalive 300 – Verbindungen aktiv halten. save 900 1 und save 300 10 – RDB-Snapshots für Persistenz.
Memcached für WordPress konfigurieren
- Memcached installieren: apt install memcached php-memcached. Start: systemctl enable memcached und systemctl start memcached.
- Verbindung in wp-config.php definieren: MEMCACHED_SERVERS als Array mit 127.0.0.1:11211.
- Drop-in einbinden: Batcache oder W3TC-Drop-in nach wp-content/object-cache.php kopieren.
- Key-Präfix setzen: Eindeutigen Präfix pro Domain konfigurieren – verhindert das FLUSH_ALL-Problem bei Multisite.
Wann Redis, wann Memcached?
| Szenario | Empfehlung | Begründung |
|---|---|---|
| WordPress auf VPS oder Root-Server | Redis | Volle Kontrolle, Persistenz, einfache Einrichtung |
| WooCommerce-Shop | Redis | Session-Persistenz, Cart-Daten überleben Neustart |
| WordPress Multisite | Redis | Datenbankisolierung verhindert site-übergreifende Flushes |
| Shared Hosting ohne Root | Memcached | Oft einzige verfügbare Option |
| Sehr hoher Lese-Throughput | Memcached | Multi-Threading-Vorteil bei extremer Parallelität |
Praxisbeispiel: Object-Cache auf cPanel-Shared-Server
Auf einem AlmaLinux-8-Server mit cPanel, 16 Domains und 8 GB RAM nutzten alle Installationen denselben Memcached-Slot ohne Key-Präfixe. Ein Cache-Flush durch Plugin-Update auf Domain A leerte alle 16 Domains gleichzeitig – messbare Lastspitze auf der Datenbank. Nach Wechsel auf Redis mit je einer eigenen Datenbank-ID pro Domain ist jeder Cache-Namespace isoliert – daher beeinflusst ein Flush auf Site A die restlichen 15 Sites nicht mehr. Zusätzlich sank der RAM-Verbrauch nach der Migration auf 340 MB statt zuvor 512 MB, weil Redis bei typischen WordPress-Workloads speichereffizienter arbeitet als erwartet.
Weitere Fragen und Antworten
Was ist ein WordPress Object-Cache und warum brauche ich ihn?
Ein WordPress Object-Cache ist ein Mechanismus, der häufig abgerufene Datenbankabfragen im RAM speichert, damit WordPress nicht bei jedem Seitenaufruf dieselbe Datenbankabfrage erneut ausführen muss. WordPress verfügt von Haus aus über einen internen Object-Cache, der jedoch nach jedem Seitenaufruf gelöscht wird – er ist daher nicht persistent. Ein persistenter Object-Cache wie Redis oder Memcached speichert die Ergebnisse dauerhaft im RAM, sodass auch der zweite und hundertste Besucher von zwischengespeicherten Datenbankabfragen profitiert. Das reduziert die Datenbanklast bei normalen WordPress-Installationen um 60 bis 90 Prozent. Folglich sinkt auch der TTFB messbar, weil WordPress weniger Zeit mit dem Warten auf Datenbankabfragen verbringt. Außerdem wird die Datenbankverbindung entlastet, was bei hochfrequentierten Seiten Serverabstürze unter Last verhindert.
Wie viel RAM sollte ich Redis für WordPress zuweisen?
Die Zuweisung des richtigen RAM-Limits für Redis hängt von der Größe der WordPress-Installation und dem Traffic ab. Als Faustregel gilt: 64 bis 128 MB für eine einfache WordPress-Installation mit wenig Traffic, 256 bis 512 MB für WooCommerce-Shops mit hohem Traffic und vielen gleichzeitigen Nutzern. Den tatsächlichen Verbrauch prüft man mit dem Befehl redis-cli info memory | grep used_memory_human. Weil Redis bei einem überschrittenen Speicherlimit Einträge nach der konfigurierten Eviction-Policy verwirft, muss maxmemory-policy korrekt gesetzt sein: allkeys-lru ist für WordPress die empfohlene Policy, da sie die am wenigsten genutzten Einträge entfernt und den Cache damit immer gefüllt hält. Zusätzlich sollte maxmemory so gewählt werden, dass genügend RAM für PHP-FPM und MariaDB verbleibt.
Was passiert bei WordPress wenn Redis ausfällt oder nicht erreichbar ist?
Wenn Redis nicht erreichbar ist, fällt WordPress automatisch auf den internen nicht-persistenten Object-Cache zurück. Das bedeutet: Die Website bleibt vollständig verfügbar und für Besucher funktional, jedoch ohne den Geschwindigkeitsvorteil des persistenten Caches. Weil jeder Seitenaufruf wieder vollständig auf die Datenbank zugreift, steigt die Datenbanklast und damit der TTFB. Auf stark frequentierten Seiten kann das zu merklichen Ladezeit-Erhöhungen führen. Das Plugin Redis Object Cache zeigt im WordPress-Admin einen deutlichen Verbindungsfehler an. Daher empfiehlt sich ein Monitoring des Redis-Dienstes via systemctl status redis oder via Uptime-Monitoring, um Ausfälle frühzeitig zu erkennen. Zusätzlich schreibt Redis bei aktivierter Persistenz den Cache-Inhalt auf die Festplatte, sodass nach einem Neustart der Cache-Stand sofort wieder verfügbar ist.
Kann ich Redis und Memcached gleichzeitig für WordPress nutzen?
Redis und Memcached können technisch auf demselben Server gleichzeitig betrieben werden, jedoch sollte nur einer der beiden Dienste als WordPress Object-Cache verwendet werden. Weil WordPress genau einen Object-Cache Drop-in (object-cache.php in wp-content/) laden kann, ist immer nur ein System aktiv. Der gleichzeitige Betrieb beider Dienste macht für WordPress-Zwecke daher keinen Sinn und würde nur RAM verschwenden. Sinnvoll wäre dagegen: Redis als WordPress Object-Cache und Memcached für einen separaten Anwendungsfall wie PHP-Session-Storage eines anderen Systems auf demselben Server. Zum Beispiel könnte eine Laravel-Anwendung Memcached für Session-Daten nutzen, während WordPress auf Redis setzt. Jedoch ist das ein fortgeschrittenes Setup, das in den meisten WordPress-Umgebungen nicht benötigt wird.
Wirkt der Object-Cache auch ohne Page-Cache-Plugin wie WP Rocket?
Ein persistenter Object-Cache wirkt vollständig unabhängig von einem Page-Cache-Plugin wie WP Rocket, Cache Enabler oder W3 Total Cache. Weil der Object-Cache auf Ebene der Datenbankabfragen ansetzt und nicht auf Ebene der HTML-Ausgabe, reduziert er die Datenbanklast bei jedem WordPress-Request – egal ob dieser Request über einen Page-Cache läuft oder nicht. Folglich profitiert auch eine WordPress-Installation ohne Page-Cache direkt von Redis oder Memcached: Typische TTFB-Verbesserungen von 30 bis 60 Millisekunden sind bei normalen Installationen realistisch. Außerdem ergänzen sich Object-Cache und Page-Cache optimal: Der Object-Cache beschleunigt PHP-seitige Datenbankabfragen, der Page-Cache verhindert, dass PHP für anonyme Besucher überhaupt ausgeführt wird.
Weiterführende Ressourcen: Redis-Dokumentation (redis.io), PHP Memcached-Extension (php.net), WordPress Object Cache API
Autor: Manuel Kuhn, WordPress Performance Engineer, Hosting-Fixers.de – Juli 2026