Redis-Cache für WooCommerce: wann er wirklich hilft, wie du ihn einrichtest

Redis macht deinen Shop an den Stellen schneller, die ein normaler Seiten-Cache gar nicht erreicht: Warenkorb, Kasse, Mein Konto und die Bestellverwaltung im Backend. Vorausgesetzt, dein Shop läuft auf einem Server, den du konfigurieren kannst - also WooCommerce, Shopware oder ein anderes selbst gehostetes System. Für Shopify gibt es das nicht, und das ist kein Nachteil.

Was Redis in einem Shop überhaupt macht

Redis ist eine Datenbank, die alles im Arbeitsspeicher hält. Im WordPress-Umfeld wird sie als Objekt-Cache eingesetzt: WordPress merkt sich darin die Ergebnisse von Datenbankabfragen, damit sie nicht bei jedem Seitenaufruf neu aus MySQL geholt werden müssen.

Der entscheidende Punkt: WordPress hat auch ohne Redis einen Objekt-Cache - aber der lebt nur für die Dauer eines einzigen Seitenaufrufs. Danach ist er weg, und der nächste Besucher löst dieselben Abfragen wieder aus. Redis macht aus diesem Kurzzeitgedächtnis ein dauerhaftes. Deshalb heißt es in WordPress auch „dauerhafter Objekt-Cache“ (persistent object cache).

Damit klar ist, worüber wir reden - es gibt im Shop vier verschiedene Caches, die oft durcheinandergeworfen werden:

Ein Seiten-Cache ist der stärkste Hebel - aber er greift bei einem Shop seltener, als man denkt. Sobald etwas im Warenkorb liegt, jemand eingeloggt ist oder die Kasse aufgerufen wird, muss die Seite individuell berechnet werden. Genau dort arbeitet Redis.

Wann sich Redis lohnt - und wann nicht

Ehrlich gesagt: Nicht jeder Shop braucht das. Wir sehen regelmäßig Installationen, in denen Redis aktiv ist und trotzdem alles langsam bleibt, weil das eigentliche Problem woanders liegt.

Es lohnt sich, wenn

• dein Shop mehr als ein paar hundert Produkte hat und Filter oder Varianten einsetzt,
• regelmäßig mehrere Besucher gleichzeitig im Warenkorb oder in der Kasse sind,
• das Backend beim Bearbeiten von Bestellungen zäh wird,
• du viele Plugins im Einsatz hast, die Daten zwischenspeichern (Preise, Versandregeln, Lagerstände),
• deine Datenbank bei jedem Aufruf dieselben Abfragen beantwortet - das siehst du in Tools wie Query Monitor.

Es lohnt sich nicht, wenn

• dein Shop wenige Besucher hat und die Seite ohnehin in unter einer Sekunde antwortet,
• dein Hoster Redis zwar anbietet, aber nur mit wenigen Megabyte Speicher,
• die Ladezeit vor allem an großen Bildern, blockierenden Skripten oder einem überladenen Theme hängt - das ist der häufigste Fall,
• du eine reine Visitenkarten-Website ohne Shop betreibst.

Ein Beispiel aus unserem eigenen Haus: shomugo.com nutzt kein Redis. Die Seite fragt gar keine Datenbank, sie besteht aus PHP-Dateien, die HTML ausgeben. Die Antwortzeit liegt bei rund 0,15 Sekunden. Ein Objekt-Cache hätte dort nichts zu tun.

Gibt es das auch für Shopify?

Nein - und du brauchst es dort auch nicht. Shopify betreibt die Server selbst. Du hast keinen Zugriff auf die Infrastruktur, kannst also weder Redis installieren noch konfigurieren. Caching, Datenbank und Auslieferung über das weltweite Netz macht Shopify im Hintergrund.

Was in Shopify an Geschwindigkeit in deiner Hand liegt, ist etwas anderes:

• Apps: Jede App bringt eigenes JavaScript mit, das im Shop geladen wird. Der größte Tempoverlust in Shopify-Shops kommt fast immer von hier.
• Theme-Code: Angepasste Abschnitte, die viele Produkte oder Metafelder durchlaufen, bremsen die Auslieferung.
• Bilder: zu groß hochgeladen, ohne passende Größenangabe eingebunden.
• Drittanbieter-Skripte: Tracking, Chat, Bewertungen, Pop-ups.

Wie du diese Bremsen findest und Schritt für Schritt löst, zeigt unsere Anleitung Shopify schneller machen.

Mit anderen Worten: Bei WooCommerce kümmerst du dich um Server und Cache, bei Shopify um das, was du in den Shop hineingebaut hast. Mehr dazu in unserem Vergleich der laufenden Arbeit in beiden Systemen auf der Seite zur Shop-Betreuung.

Voraussetzungen prüfen

Bevor du ein Plugin installierst, klär drei Dinge:

1. Läuft auf dem Server überhaupt ein Redis?

Redis ist ein eigener Dienst, der auf dem Server laufen muss. Auf einfachem Shared Hosting gibt es ihn meist nicht. Bei Hetzner ist Redis in den Webhosting-Paketen ab L und auf Managed Servern verfügbar und muss in konsoleH erst aktiviert werden.

2. Kann PHP mit Redis sprechen?

Dafür braucht es entweder die PHP-Erweiterung phpredis (schneller, üblich) oder die Bibliothek Predis, die das Plugin mitbringt. Ob die Erweiterung vorhanden ist, zeigt dir eine Datei mit phpinfo() oder im WordPress-Backend „Werkzeuge → Website-Zustand → Bericht“.

3. Wie viel Speicher darf Redis belegen?

Ein Objekt-Cache braucht nicht viel - für die meisten Shops reichen 64 bis 256 MB. Wichtig ist, dass bei vollem Speicher die ältesten Einträge verworfen werden und nicht einfach Schreibfehler auftreten. Bei verwalteten Angeboten wie Hetzner stellst du die Größe im Kundenmenü ein, auf einem eigenen Server ist es die Einstellung maxmemory-policy allkeys-lru.

Einrichtung Schritt für Schritt

Die folgende Anleitung beschreibt den Weg auf einem Hetzner Managed Server. Bei anderen Hostern unterscheiden sich nur die ersten beiden Schritte - der WordPress-Teil ist überall gleich.

Schritt 1: Redis beim Hoster aktivieren

In konsoleH anmelden, unter „Produkte“ den Server wählen, zum Hosting-Account gehen und unter „Dienste“ den Punkt Redis aktivieren. Dort legst du auch fest, wie viele interne Datenbanken es gibt und wie viel Arbeitsspeicher die Instanz bekommen darf.

Der Zugriff läuft bei Hetzner nicht über eine Netzwerkadresse, sondern über einen sogenannten Socket - eine Datei auf dem Server. Sie liegt unter:

/run/redis_<dein-account>/redis.sock

Das hat einen angenehmen Nebeneffekt: Die Instanz ist von außen nicht erreichbar, ein Passwort ist deshalb nicht vorgesehen.

Schritt 2: Verbindung testen

Per SSH auf dem Server prüfst du, ob Redis antwortet:

redis-cli -s /run/redis_<dein-account>/redis.sock ping
# Antwort: PONG

Schritt 3: Zugangsdaten in die wp-config.php eintragen

Die folgenden Zeilen gehören in die wp-config.php, oberhalb der Zeile mit /* That's all, stop editing! */:

/* Verbindung ueber den Unix-Socket des Hosters */
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis_dein-account/redis.sock' );

/* Eigene Datenbank-Nummer und eigener Praefix je Shop (0-15) */
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop1' );

/* Wenn Redis nicht antwortet, soll die Seite trotzdem ausliefern */
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

Läuft Redis bei deinem Hoster über eine Netzwerkadresse statt über einen Socket, nimmst du stattdessen diese Variante:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PASSWORD', 'dein-passwort' );

Schritt 4: Plugin installieren und den Cache einschalten

Das Standard-Plugin heißt Redis Object Cache und stammt von Till Krüss. Es ist kostenlos, wird gepflegt und ist das, was praktisch jeder Hoster empfiehlt.

Nach der Installation findest du den Punkt unter „Einstellungen → Redis“. Dort gibt es genau einen Knopf: Objekt-Cache aktivieren. Damit schreibt das Plugin eine Datei object-cache.php in den Ordner wp-content. Diese Datei ist der eigentliche Cache - das Plugin selbst ist nur die Bedienoberfläche dazu.

Mit WP-CLI geht dasselbe schneller:

wp plugin install redis-cache --activate
wp redis enable
wp redis status

Schritt 5: Kontrollieren, ob es wirklich arbeitet

Drei Stellen, an denen du es siehst:

• Plugin-Seite: Status „Verbunden“, dazu Trefferquote, Anzahl der Schlüssel und belegter Speicher. Eine Trefferquote über 90 Prozent ist ein gutes Zeichen.
• Website-Zustand: Unter „Werkzeuge → Website-Zustand“ verschwindet die Empfehlung „Du solltest einen dauerhaften Objekt-Cache verwenden“.
• Antwortzeit: Miss vorher und nachher dieselbe Seite, am besten eine, die nicht im Seiten-Cache liegt - etwa die Kasse mit einem Artikel im Warenkorb.

Für die Messung reicht die Kommandozeile:

curl -o /dev/null -s -w "%{time_starttransfer}\n" https://dein-shop.at/kasse/

Mehrere Shops auf einem Server

Das ist der Fehler, den wir am häufigsten finden: Zwei oder drei WordPress-Installationen auf demselben Server greifen auf dieselbe Redis-Datenbank zu, ohne sich zu unterscheiden. Dann holt sich Shop A Einträge, die Shop B geschrieben hat - mit Ergebnissen, die von vertauschten Menütiteln bis zu falschen Preisen reichen.

Die Lösung sind zwei Zeilen pro Installation: eine eigene Datenbank-Nummer und ein eigener Präfix.

/* Shop 1 */
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop1' );

/* Shop 2 */
define( 'WP_REDIS_DATABASE', 1 );
define( 'WP_REDIS_PREFIX', 'shop2' );

Wie viele Datenbanken zur Verfügung stehen, legst du bei Hetzner in denselben Einstellungen fest, in denen du Redis aktiviert hast. Üblich sind 16 (die Nummern 0 bis 15).

Häufige Fehler

• Redis als Ersatz für Hausaufgaben. Wenn die Startseite 6 MB Bilder lädt, bringt ein Objekt-Cache fast nichts. Erst messen, wo die Zeit hingeht, dann entscheiden.
• Cache nach Änderungen nicht geleert. Nach einem Umzug, einem Datenbank-Import oder größeren Plugin-Updates leerst du ihn mit wp redis flush oder über den Knopf im Plugin.
• Plugin gelöscht, Drop-in geblieben. Wer das Plugin einfach löscht, lässt die object-cache.php zurück - WordPress versucht dann weiter, Redis zu erreichen. Richtig ist: erst „Objekt-Cache deaktivieren“, dann das Plugin entfernen.
• Zu knapper Speicher ohne Verdrängungsregel. Ist Redis voll und nicht auf allkeys-lru gestellt, schlagen Schreibzugriffe fehl. Im besten Fall merkt man nichts, im schlechtesten hängt die Seite.
• Zwei Objekt-Caches gleichzeitig. Manche Performance-Plugins bringen einen eigenen mit. Es kann nur eine object-cache.php geben - entscheide dich für eine Lösung.
• Kein Zeitlimit gesetzt. Ohne WP_REDIS_TIMEOUT wartet WordPress im Störungsfall unnötig lange. Mit einer Sekunde fällt es schnell auf die Datenbank zurück.

Wieder sauber entfernen

Falls du feststellst, dass es nichts bringt - der Rückbau dauert zwei Minuten:

wp redis disable
wp plugin deactivate redis-cache
wp plugin delete redis-cache

# Kontrolle: Die Datei darf nicht mehr existieren
ls wp-content/object-cache.php

Danach die Konstanten aus der wp-config.php nehmen und beim Hoster den Dienst abschalten, wenn er Geld kostet.

Was du realistisch erwarten darfst

Bei einem Shop mit vielen Produkten und echtem Besucheraufkommen sind kürzere Antwortzeiten im Backend und auf Warenkorb- und Kassenseiten die Regel. Spürbar wird es vor allem dann, wenn mehrere Leute gleichzeitig unterwegs sind - die Datenbank wird entlastet, die Seite bricht später ein.

Was Redis nicht tut: Es macht keine Bilder kleiner, entfernt keine blockierenden Skripte und repariert kein langsames Theme. In unseren Shop-Analysen ist die Reihenfolge fast immer dieselbe - zuerst Bilder und Skripte, dann der Seiten-Cache, dann der Objekt-Cache. Womit du anfängst und wie du deine Werte einordnest, steht beim Hebel Ladezeit & Core Web Vitals – dort gibt es auch einen Rechner für das Seitengewicht. Wer es umgekehrt macht, zahlt für Technik, die das eigentliche Problem nicht berührt.