Antworten aus dem Arbeitsspeicher
Statt dieselbe Abfrage bei jedem Aufruf erneut an die Datenbank zu schicken, holt WordPress das Ergebnis aus dem RAM. Der Weg über die Platte entfällt.
WordPress stellt bei jedem Aufruf dieselben Fragen an die Datenbank. Redis merkt sich die Antworten im Arbeitsspeicher, sodass sie beim nächsten Mal sofort bereitliegen. Das zahlt sich vor allem dort aus, wo kein fertiges HTML aus dem Cache kommen kann.
WordPress bringt einen Object-Cache von Haus aus mit. Er hat allerdings einen Haken: Er gilt laut Entwicklerdokumentation nur für die Dauer eines einzelnen Aufrufs. Ist die Seite ausgeliefert, ist der Speicher wieder leer. Beim nächsten Besucher beginnt dasselbe Spiel von vorn, mit denselben Abfragen an dieselbe Datenbank.
Ein persistenter Object-Cache ändert genau das. WordPress sieht beim Start nach, ob im Ordner wp-content eine Datei namens object-cache.php liegt. Findet es eine, übernimmt diese die Speicherung. Statt in den Arbeitsspeicher eines einzelnen Aufrufs gehen die Daten dann an Redis und überdauern dort den Seitenaufruf.
Redis ist ein Datenspeicher, der seine Inhalte im Arbeitsspeicher hält und dort mit Strukturen wie Zeichenketten, Hashes, Listen und Mengen arbeitet. Jeder Eintrag kann eine Laufzeit bekommen und verfällt danach von allein. Für WordPress zählt vor allem eins: Eine Antwort aus dem RAM ist um Größenordnungen schneller zu haben als eine, die erst über eine Datenbankabfrage zusammengesucht werden muss.
Der LiteSpeed-Cache speichert fertige Seiten. Ein anonymer Besucher bekommt reines HTML, ohne dass PHP oder die Datenbank überhaupt anspringen. Das ist die schnellste Variante, funktioniert aber nur bei Inhalten, die für alle gleich aussehen. Sobald jemand eingeloggt ist, etwas im Warenkorb liegt oder du im Backend arbeitest, muss die Seite individuell gebaut werden. Ab da entscheidet, wie schnell die Bausteine zusammenkommen. Und genau die liefert Redis.
Nicht jede Seite braucht einen Object-Cache. Für dynamische Projekte ist er aber der Hebel, an dem nach dem Seiten-Cache noch etwas zu holen ist.
Statt dieselbe Abfrage bei jedem Aufruf erneut an die Datenbank zu schicken, holt WordPress das Ergebnis aus dem RAM. Der Weg über die Platte entfällt.
Eingeloggte Besucher, Warenkorb, Kasse und das WordPress-Backend bekommen kein fertiges HTML aus dem Cache. Genau dort arbeitet Redis.
Die Verbindung läuft nicht über das Netzwerk, sondern direkt über einen Socket deines Kontos. Das spart Umweg und Handshake bei jeder Anfrage.
Ohne Object-Cache legt WordPress Transients als Zeilen in wp_options ab, wo abgelaufene Einträge liegen bleiben können. Mit Redis wandern sie in den Speicher und verfallen von selbst.
WooCommerce, Mitgliederbereiche und Seiten mit vielen Plugins erzeugen die meisten Datenbankabfragen. Dort ist der Unterschied am größten.
Die Anbindung läuft über das Redis Object Cache Plugin oder die Object-Cache-Funktion von LiteSpeed Cache. Beides ist verbreitet und jederzeit wieder abschaltbar.
Ein Object-Cache speichert keine Seiten, sondern einzelne Datenpakete. Diese hier fallen bei fast jedem Aufruf an.
| Datenart | Ohne Object-Cache | Mit Redis |
|---|---|---|
| Optionen wp_options, autoload | WordPress lädt bei jedem einzelnen Aufruf alle autoload-Optionen aus der Datenbank. Je mehr Plugins, desto größer dieser Block. | Wird einmal geladen und liegt danach im Speicher bereit. |
| Beiträge und Metadaten Posts, Postmeta | Jede Schleife im Theme fragt Inhalte und die zugehörigen Zusatzfelder erneut ab. | Wiederkehrende Abfragen werden aus dem Cache beantwortet. |
| Kategorien und Menüs Taxonomien, Navigation | Menüstruktur und Kategoriebäume werden bei jedem Seitenaufruf neu zusammengesetzt. | Bleiben zwischengespeichert, bis du etwas änderst. |
| Transients Zwischenergebnisse von Plugins | Landen als Zeilen in wp_options. Abgelaufene Einträge bleiben teils liegen und blähen die Tabelle auf. | Liegen im Arbeitsspeicher und verfallen automatisch mit ihrer Laufzeit. |
| Benutzer und Sitzungen Users, Usermeta | Für jeden eingeloggten Aufruf werden Benutzerdaten und Rechte frisch geholt. | Werden gecacht, was Backend und Mitgliederbereiche entlastet. |
| Produktdaten WooCommerce | Varianten, Preise und Lagerstände erzeugen viele einzelne Abfragen pro Produktseite. | Der Großteil kommt aus dem Cache, die Datenbank bleibt für Bestellungen frei. |
Caching bei WordPress passiert auf mehreren Ebenen. Wer sie kennt, kann einschätzen, was ein Object-Cache im eigenen Fall überhaupt bringt.
LiteSpeed liefert fertiges HTML an anonyme Besucher aus. Hier holst du den größten Sprung. Diese Ebene ist in jedem Tarif dabei.
Redis fängt ab, was die erste Ebene nicht abdecken kann: eingeloggte Nutzer, Warenkorb, Kasse und das Backend.
Was keine der beiden Ebenen beantwortet, landet bei MariaDB auf NVMe-Speicher. Je weniger dort ankommt, desto schneller bleibt es dort auch unter Last.
Für eine kleine Firmenseite mit wenig Bewegung reicht Ebene 1 meist aus. Deshalb steckt Redis bei uns in Business und Business PRO, nicht im Startup-Tarif. Eine Kurzfassung des Themas steht im Glossar unter Redis (Object-Cache).
Beitragslisten, Medienübersicht und Plugin-Seiten sind vom Seiten-Cache ausgenommen. Beim Arbeiten in WordPress merkst du den Unterschied deshalb oft zuerst.
Warenkorb und Kasse lassen sich nicht als fertige Seite ablegen. Ein Object-Cache hält die Datenbank frei für das, was wirklich geschrieben werden muss: Bestellungen.
Weniger wiederholte Abfragen bedeuten weniger Last. Das hilft besonders bei Zugriffsspitzen, wenn viele Besucher gleichzeitig dynamische Seiten aufrufen.
Transients von Plugins wandern in den Speicher statt in wp_options. Die Tabelle, die WordPress bei jedem Aufruf anfasst, bleibt dadurch kleiner und die Ladezeit stabiler.
Die Ebene davor beschreibt die Seite zum LiteSpeed Webserver, die Trennung der Konten übernimmt CloudLinux.
In Business und Business PRO. Im Startup-Tarif ist Redis nicht dabei, dort greifen LiteSpeed-Cache und NVMe-Speicher. Wenn deine Seite wächst oder du einen Shop startest, kannst du jederzeit wechseln.
Der Dienst läuft bereits und ist deinem Konto zugeordnet. In WordPress braucht es einen Handgriff: entweder das Plugin Redis Object Cache oder die Object-Cache-Funktion im LiteSpeed-Cache-Plugin. Bei einem Umzug durch uns erledigen wir das mit, auf Wunsch übernehmen wir es auch später.
Der LiteSpeed-Cache legt fertige HTML-Seiten ab und liefert sie an anonyme Besucher aus, ganz ohne PHP und Datenbank. Redis speichert die Bausteine darunter. Das zählt immer dann, wenn keine fertige Seite ausgeliefert werden kann, also bei eingeloggten Nutzern, im Warenkorb und im Backend. Die beiden konkurrieren nicht, sie greifen an unterschiedlichen Stellen.
Ehrlich gesagt oft wenig. Eine schlanke Seite mit wenigen Plugins, die überwiegend anonyme Besucher hat, wird schon vom Seiten-Cache bedient. Spürbar wird Redis bei vielen Plugins, bei Shops, bei Mitgliederbereichen und beim Arbeiten im Backend. Ob es sich lohnt, siehst du am ehesten an der Zahl der Datenbankabfragen, etwa mit dem Plugin Query Monitor.
WordPress verwirft betroffene Einträge selbst, sobald du etwas speicherst. Zusätzlich haben Einträge eine Laufzeit und verfallen danach. Falls doch einmal etwas hängt, lässt sich der Cache komplett leeren, ohne dass Inhalte verloren gehen.
Nichts Dramatisches. Im Cache liegen nur Kopien, die Originaldaten stehen weiter in der Datenbank. Fällt der Dienst aus, holt WordPress die Daten wieder von dort. Die Seite wird dann langsamer, bleibt aber vollständig.
Sag uns, was auf deiner Webseite läuft. Wir schauen ehrlich nach, ob ein Object-Cache bei dir etwas bringt oder ob der Seiten-Cache reicht.