Cache-Plugins in WordPress: Aktiv heißt noch lange nicht wirksam

Es gibt Probleme, die laut sind: Die Website ist weg, ein weißer Bildschirm, eine Fehlermeldung. Und es gibt die leisen. Die Website läuft, alles sieht normal aus – sie ist nur langsamer, als sie sein müsste. Bei der Wartung von WordPress-Kundenseiten begegne ich solchen Problemen immer wieder. Stichwort: Cache-Plugins!

Ein typischer Hinweis kommt aus der Website-Zustandsprüfung: „Seiten-Cache wurde nicht erkannt“. Dabei ist ein Cache-Plugin installiert und aktiviert. Manchmal meldet WordPress zusätzlich, dass automatisch geladene Optionen die Leistung beeinflussen können. Die Website funktioniert, doch unter der Oberfläche stimmt etwas nicht.

Dann beginnt die Detektivarbeit. Denn ein aktives Plugin beweist zunächst nur, dass es eingeschaltet ist. Ob es zur Serverumgebung passt und tatsächlich Seiten aus dem Cache ausliefert, muss man gesondert prüfen.

Was Cache-Plugins eigentlich leisten

WordPress setzt eine Seite normalerweise bei jedem Aufruf zusammen: Es lädt Einstellungen, fragt Inhalte aus der Datenbank ab und verarbeitet die Vorgaben von Theme und Plugins. Ein Seiten-Cache speichert das fertige Ergebnis. Weitere Besucher bekommen diese vorbereitete Fassung, statt dieselbe Berechnung erneut auszulösen.

Das kann den Server entlasten und die Antwortzeit verkürzen. Allerdings nur, wenn der Cache richtig eingerichtet ist. Genau daran scheitert es auf manchen Websites: Das Plugin ist vorhanden, seine wichtigste Funktion bleibt aber ungenutzt.

Das richtige Cache-Plugin auf dem falschen Server

Ein gutes Beispiel ist LiteSpeed Cache. Das Plugin bietet zahlreiche Funktionen zur Optimierung. Sein eigentlicher Seiten-Cache setzt jedoch eine passende LiteSpeed-Infrastruktur voraus. Alternativ lässt sich diese Funktion über den Dienst QUIC.cloud nutzen.

Läuft die Website auf einem Apache-Server ohne eine solche Anbindung, reicht die Installation des Plugins für den Seiten-Cache nicht aus. Andere Optimierungsfunktionen können trotzdem arbeiten. Dadurch entsteht leicht der Eindruck, auch das Caching sei erledigt.

Deshalb prüfe ich bei Kundenseiten zuerst die Hostingumgebung. Ein Blick in die Antwort-Header des Servers kann Hinweise geben; bei vorgeschalteten Diensten oder unklaren Angaben helfen die Informationen des Hosters weiter.

Cache-Plugins müssen zur technischen Umgebung passen. Entscheidend ist nicht, welches Plugin besonders häufig empfohlen wird, sondern welches auf dem jeweiligen Server die benötigte Aufgabe erfüllt.

Auf Apache können beispielsweise Cache Enabler oder WP Super Cache – beides einfache, aber hier sehr wirksame Cache-Plugins – infrage kommen. Gibt es bereits einen Seiten-Cache beim Hoster, muss auch dieser in die Entscheidung einbezogen werden.

Alte Cache-Plugins hinterlassen ihre Spuren

WordPress-Websites wachsen über Jahre. Jemand installiert ein Plugin, probiert ein anderes aus und löscht später den Vorgänger. Was dabei zurückbleibt, fällt oft erst bei einer technischen Prüfung auf.

Im Ordner wp-content können alte Cache-Verzeichnisse, Konfigurationsdateien oder eine verwaiste advanced-cache.php liegen. Diese Datei gehört bei vielen Cache-Plugins zur technischen Einbindung. Stammt sie vom falschen Plugin oder verweist sie auf nicht mehr vorhandene Dateien, kann sie den neuen Cache behindern.

Mehrere Cache-Plugins nacheinander auszuprobieren, löst das Problem deshalb nicht unbedingt. Unter Umständen wächst nur die Sammlung der Hinterlassenschaften.

Beim Wechsel prüfe ich, welche Dateien zum bisherigen Plugin gehören und welche das neue benötigt. Unbekannte Dateien einfach zu löschen, ist keine gute Aufräumstrategie. Erst wird ihre Funktion geklärt, dann werden überflüssige Reste gezielt entfernt.

Wenn die Datenbank bei jedem Aufruf unnötigen Ballast lädt

Neben dem Cache verdient die Datenbank Aufmerksamkeit. WordPress kennt Einstellungen, die automatisch geladen werden: die sogenannten Autoload-Optionen. Sie stehen WordPress beim Start zur Verfügung, ohne dass jede Einstellung einzeln angefordert werden muss.

Problematisch wird es, wenn sich dort große Datenmengen ansammeln. Das können umfangreiche Plugin-Einstellungen sein, Reste früherer Erweiterungen oder einzelne ungewöhnlich große Zwischenspeicher.

Ein Beispiel ist _transient_dirsize_cache. Darin kann WordPress ermittelte Verzeichnisgrößen zwischenspeichern. Bei umfangreichen Verzeichnisstrukturen kann dieser Eintrag erheblich wachsen. Wird er automatisch geladen, trägt er zum Datenvolumen bei, das WordPress beim Start verarbeiten muss.

Deshalb schaue ich bei einer entsprechenden Warnung nicht nur auf die Anzahl der Einträge. Ein einzelner großer Eintrag kann mehr Gewicht haben als Hunderte kleine. Eine nach Größe sortierte Auswertung zeigt oft schnell, wo sich die weitere Prüfung lohnt.

Entbehrliche Zwischenspeicher lassen sich gezielt entfernen und bei Bedarf neu aufbauen. Einstellungen aktiver Plugins brauchen dagegen eine genauere Prüfung. Vor jeder Änderung gehört ein vollständiger Datenbankexport dazu. In der Datenbank gibt es keinen Papierkorb.

Die entscheidende Einstellung muss auf dem Server ankommen

Viele dateibasierte Cache-Plugins benötigen in der wp-config.php diese Zeile:

define( 'WP_CACHE', true );

Sie erlaubt WordPress, die Datei advanced-cache.php frühzeitig einzubinden. Die Einstellung allein beweist allerdings noch nicht, dass der Cache korrekt arbeitet.

Bei der Fehlersuche zählt außerdem die Datei auf dem Server. Eine korrekt bearbeitete Kopie auf dem eigenen Rechner hilft wenig, wenn der anschließende Upload scheitert. Schreibschutz, fehlende Berechtigungen oder das falsche Zielverzeichnis können dafür sorgen, dass die Änderung nie wirksam wird.

Nach einer Anpassung prüfe ich deshalb den tatsächlichen Inhalt auf dem Server und das Übertragungsprotokoll. Unter Werkzeuge → Website-Zustand → Bericht → WordPress-Konstanten lässt sich zusätzlich nachsehen, welchen Wert WordPress für WP_CACHE erkennt.

Auch nach einem Plugin-Wechsel lohnt sich diese Kontrolle. Cache-Plugins können bei ihrer Aktivierung oder Deaktivierung Änderungen an der Konfiguration vornehmen.

Cache-Plugins richtig testen

Wer seine Website angemeldet besucht, sieht häufig bewusst keine zwischengespeicherten Seiten. Das ist sinnvoll: Persönliche Inhalte, Bearbeitungsleisten oder individuelle Kontodaten dürfen nicht versehentlich bei anderen Besuchern landen.

Für einen aussagekräftigen Test öffne ich die Website deshalb abgemeldet in einem privaten Browserfenster und rufe dieselbe Seite mehrfach auf. Anschließend prüfe ich anhand der zum jeweiligen Cache gehörenden Merkmale, ob tatsächlich eine gespeicherte Fassung ausgeliefert wird.

Die gefühlte Geschwindigkeit allein reicht dafür nicht aus. Browser-Cache, Verbindung und Serverauslastung beeinflussen den Eindruck. Entscheidend ist, ob sich die Funktion des Seiten-Caches nachweisen lässt.

Bei Shops und Mitgliederbereichen kommt eine weitere Prüfung hinzu: Warenkorb, Kasse und persönliche Seiten müssen korrekt behandelt werden. Eine schnelle Website hilft wenig, wenn sie die falschen Inhalte ausliefert. Hier ist bei allen Cache-Plugins besondere Vorsicht angezeigt.

Geplante Aufgaben dürfen nicht liegen bleiben

Ein funktionierender Seiten-Cache kann eine weitere Schwachstelle sichtbar machen. WordPress stößt seine geplanten Aufgaben normalerweise im Zusammenhang mit Seitenaufrufen an. Dazu gehören beispielsweise die Veröffentlichung vorbereiteter Beiträge und verschiedene Hintergrundarbeiten.

Liefert ein Cache die Seite aus, bevor WordPress startet, entfällt bei diesem Aufruf auch der übliche Anstoß für WP-Cron. Bei wenig Besuch oder weitgehend zwischengespeicherten Aufrufen können Aufgaben dadurch verspätet ausgeführt werden.

Ein serverseitiger Cronjob macht die Ausführung unabhängiger von Besuchern. Er kann wp-cron.php beispielsweise alle 15 Minuten aufrufen. Welcher Abstand sinnvoll ist, hängt davon ab, welche Aufgaben die Website erledigen muss. Die WordPress-Konfiguration wird darauf abgestimmt, damit die Zeitsteuerung sauber funktioniert.

Meine Prüfliste für Cache-Plugins auf Kundenseiten

• Hostingumgebung klären: Passt das Cache-Plugin zum Webserver, und gibt es bereits einen Cache beim Hoster?
• Zuständigkeiten ordnen: Überlappende Cache-Lösungen vermeiden und vorhandene Ebenen aufeinander abstimmen.
• Plugin-Reste prüfen: Alte Verzeichnisse und Dateien wie advanced-cache.php kontrollieren und eindeutig zuordnen.
• Konfiguration kontrollieren: Benötigte Einstellungen wie WP_CACHE in der tatsächlich verwendeten Serverdatei prüfen.
• Übertragungen überprüfen: Nach Änderungen Inhalt und Übertragungsprotokoll kontrollieren.
• Abgemeldet testen: Mehrere Aufrufe im privaten Fenster durchführen und die Cache-Auslieferung nachweisen.
• Datenbank untersuchen: Große Autoload-Optionen prüfen und Änderungen durch einen Export absichern.
• Zeitsteuerung kontrollieren: Sicherstellen, dass geplante Aufgaben zuverlässig ausgeführt werden.

Gute WordPress-Wartung schaut hinter die Oberfläche

Viele dieser Fehler sind einzeln schnell behoben. Zeit kostet ihre Kombination: Ein aktives Plugin vermittelt, dass der Cache läuft. Eine bearbeitete Datei vermittelt, dass die Einstellung geändert wurde. Eine erreichbare Website vermittelt, dass technisch alles in Ordnung ist.

Bei Kundenseiten prüfe ich deshalb, was der Server tatsächlich ausliefert und welche Daten WordPress verarbeitet. Erst daraus ergibt sich ein belastbares Bild.

Genau das gehört für mich zu guter WordPress-Wartung: Updates einspielen, Funktionen kontrollieren und versteckte Bremsen beseitigen. Cache-Plugins können dabei viel bewirken – wenn ihre Wirkung auch überprüft wird.

Überblick in der WordPress-Repository: https://wordpress.org/plugins/search/cache/