Ein öffentlicher Beitrag wird durch Seiten-Caching schnell, doch eine angemeldete Berichtsseite führt weiterhin dieselben teuren Datenbankabfragen aus. Eine zusätzliche Seiten-Cache-Regel würde private Inhalte gefährden – der Engpass liegt auf einer anderen Ebene.
Seiten- und Objekt-Cache lösen unterschiedliche Probleme. Wer sie verwechselt, leert häufig den falschen Speicher oder speichert Inhalte, die nicht geteilt werden dürfen.
Was darunter zu verstehen ist
Ein Seiten-Cache verwendet eine vollständig gerenderte HTTP-Antwort erneut und kann WordPress bei geeigneten öffentlichen Anfragen weitgehend umgehen. Ein Objekt-Cache speichert Daten, die WordPress während der Ausführung lädt oder berechnet, nach Gruppe und Schlüssel.
Persistentes Objekt-Caching benötigt ein unterstütztes Backend wie Redis oder Memcached und eine korrekte Invalidierung. Es ersetzt keine Optimierung langsamer, nicht cachebarer Abfragen.
Praxisbeispiel
Die Startseite eines Portals profitiert stark vom Seiten-Cache. Im angemeldeten Bereich werden dagegen dieselben Konfigurations- und Berichtsdaten bei jeder Anfrage neu geladen. Ein persistenter Objekt-Cache kann diese wiederverwendbaren Werte beschleunigen, während das persönliche HTML ungecacht bleibt.
Damit steigt die Leistung, ohne Sitzungen zwischen Nutzern zu teilen.
Warum die Unterscheidung wichtig ist
Der richtige Cache hängt davon ab, welche Arbeit wiederholt wird. Stabiles öffentliches HTML gehört zum Seiten-Cache; wiederholt geladene Anwendungswerte können in den Objekt-Cache. Externe APIs, schlecht indizierte Abfragen oder falsche Schlüssel werden durch keinen der beiden automatisch behoben.
Beide Ebenen können sinnvoll kombiniert werden, sollten aber einzeln messbar und löschbar bleiben.
Ein einfacher und sicherer Einstieg
- Messen Sie öffentliche Erzeugungszeit, angemeldete Laufzeit und Datenbankabfragen getrennt.
- Nutzen Sie Seiten-Caching für stabile öffentliche Antworten.
- Prüfen Sie Objekt-Caching für anfrageübergreifend gültige Anwendungsdaten.
- Aktivieren und testen Sie jede Ebene zunächst einzeln.
- Kontrollieren Sie nach Inhalts- und Einstellungsänderungen beide Ebenen auf Aktualität.
Technische Prüfung
Bestätigen Sie, dass Drop-in und Backend tatsächlich aktiv sind. Installation allein beweist keine Persistenz. Kapazität, Verdrängung, Schlüsselpräfixe, Multisite-Trennung, Serialisierung und Netzwerklatenz beeinflussen den Objekt-Cache.
Dokumentieren Sie Backend, Namensraum, TTL-Verantwortung und Löschumfang. Beim Seiten-Cache gehören Ausnahmen und der vollständige Antwortschlüssel dazu.
Risiken, häufige Fehler, Backup und Rollback
Eine vollständige Objekt-Cache-Löschung wegen einer alten Seite erhöht Last, ohne die richtige Ebene zu treffen. Umgekehrt darf personalisiertes HTML nicht gemeinsam gespeichert werden, nur weil Objekt-Caching wenig Effekt zeigt.
- Messen Sie kalte und warme Anfragen getrennt.
- Prüfen Sie Neustart und Verdrängung des Backends.
- Halten Sie für jede Ebene eine eigene Abschalt- und Löschmöglichkeit bereit.
So unterstützt AIOWS:
AIOWS Cache Manager
AIOWS Cache Manager unterstützt die WordPress-seitige Verwaltung des Seiten-Caches und macht dessen Einstellungen nachvollziehbar. Das erleichtert die Abgrenzung zu einem separaten persistenten Objekt-Cache.
Ein externer Redis- oder Memcached-Dienst besitzt eigene Kapazitäts-, Schlüssel- und Betriebsregeln. AIOWS kann nicht belegen, dass dieses Backend aktiv ist oder Anwendungsdaten korrekt invalidiert. Prüfen Sie deshalb jede Ebene mit den passenden Messwerten: öffentliche Antwortheader für den Seiten-Cache, Abfrage- und Backend-Daten für den Objekt-Cache.
Ändern Sie nicht beide Ebenen gleichzeitig. Wenn ein Test fehlschlägt, setzen Sie nur die zuletzt angepasste Konfiguration zurück. So bleibt klar, welcher Cache den Nutzen oder den veralteten Zustand verursacht.
Passende AIOWS-Artikel
- Wie WordPress-Caching funktioniert: Seite, Browser, Objekt und CDN
- WordPress-Seiten-Cache sicher aktivieren
- Cache-Control-Header in WordPress erklärt
Fazit und Empfehlung
Seiten-Cache beschleunigt vollständige öffentliche Antworten, Objekt-Cache wiederverwendbare Anwendungsdaten. Messen Sie den Engpass, wählen Sie die passende Ebene und definieren Sie deren Invalidierung getrennt. Erst danach ist eine Kombination sinnvoll.
