Cachen Sie öffentliche Seiten im Page Cache oder CDN und schließen Sie personalisierte Konten, Warenkörbe und Callbacks aus. Verwenden Sie den Object Cache für wiederholte Berechnungen und Abfragen, nicht als Ersatz für deren Optimierung. Definieren Sie den Cache-Key und die Invalidierung bei Änderungen von Inhalt, Preis oder Berechtigungen und testen Sie sowohl anonyme als auch angemeldete Benutzer.
Der WordPress-Cache beschleunigt die Website, indem nicht jedes Mal der gesamte Weg von PHP und Datenbank bis zu entfernten Dateien durchlaufen wird. Es gibt jedoch mehrere Ebenen: Page-Cache, Objekt-Cache, Opcode-Cache, CDN und Browser. Jede speichert ein anderes Ergebnis und hat andere Gültigkeitsregeln. Zwei Plugins, die dieselbe Ebene konfigurieren, können einen Konflikt verursachen, während eine fehlende Invalidierung einen veralteten Preis oder Inhalt anzeigt.
Ein korrektes Design beginnt mit der Einteilung der Seiten in öffentliche, personalisierte und sensible. Einen öffentlichen Artikel kann man gefahrlos mit vielen Besuchern teilen, ein Konto oder einen Warenkorb nicht. Der Cache-Schlüssel muss Sprache, Währung oder die erforderliche Rolle berücksichtigen, und nach einer Datenänderung muss der betreffende Eintrag entfernt werden. Die Performance wird zusammen mit der Funktionalität geprüft, nicht nur anhand der Hit Rate.
Unterscheiden Sie die einzelnen Cache-Ebenen
Der Page Cache speichert die fertige HTML-Antwort und umgeht einen Großteil von WordPress. Der Object Cache bewahrt die Ergebnisse von Datenoperationen zwischen Anfragen auf. Der Opcode Cache beschleunigt die Ausführung von PHP-Code, und der Browser speichert statische Dateien gemäß den Headern. Ein CDN kann Bilder, CSS oder ganze öffentliche Seiten am Netzwerkrand cachen.
Klären Sie vor dem Aktivieren eines neuen Plugins, was Hosting oder Proxy bereits bereitstellen. Ein doppelter Page-Cache erschwert das Leeren und die Diagnose. Dokumentieren Sie für jede Schicht die verantwortliche Person, den Administrationsweg und den Notfall-Purge. Das Leeren aller Caches kann den Server vorübergehend belasten; bevorzugen Sie daher bei großen Websites eine gezielte Invalidierung.
Klassifizieren Sie öffentliche und personalisierte Inhalte
Artikel, Leistungsseiten und öffentliche Archive sind geeignete Kandidaten, sofern ihre Ausgabe nicht von der Identität abhängt. Administration, Entwurfsvorschau, Konto, Warenkorb, Kasse, Nonce und Zahlungs-Callback sollten nicht aus einem öffentlichen Cache ausgeliefert werden. Ein Formular auf einer gecachten Seite muss Sicherheitstoken auf unterstützte Weise erzeugen oder erneuern.
Ein angemeldeter Redakteur kann die Admin-Leiste, den Bearbeitungslink und nicht öffentliche Inhalte sehen, daher unterscheidet der Cache nach Cookies oder wird für diese Sitzungen umgangen. Eine Mitglieder-Website benötigt einen feineren Schlüssel nach Rolle oder Berechtigung, darf aber nicht in eine unbegrenzte Zahl von Varianten ausufern. Minimieren Sie zuerst die Personalisierung der öffentlichen Seite.
- Öffentliches anonymes HTML
- Ausgeschlossene Konten und Transaktionen
- Getrennte angemeldete Sitzungen
- Keine Secrets im Cache-Schlüssel oder Log
Entwerfen Sie Cache-Key und Invalidierung
Der Schlüssel kann URL, Sprache, Währung, Gerät – nur wenn sich der Inhalt tatsächlich unterscheidet – sowie weitere kontrollierte Varianten umfassen. Ignorieren Sie Kampagnenparameter, die den Inhalt nicht verändern, damit keine Tausende von Kopien entstehen. Umgekehrt darf ein Filterparameter, der das Ergebnis verändert, nicht das HTML einer anderen Kombination erhalten. Testen Sie die Normalisierung auch mit kodierten Werten.
Leeren Sie beim Speichern eines Artikels dessen Detailseite, das relevante Archiv, den Startseitenbereich und die Sitemap entsprechend den Abhängigkeiten. Eine Änderung des globalen Headers kann die gesamte Website betreffen und erfordert daher eine umfassendere Invalidierung. Preis oder Lagerbestand erfordern eine kurze Gültigkeit oder ein Event aus der Integration. Eine zeitbasierte TTL ist eine Absicherung, kein Ersatz für einen gezielten Purge nach einer kritischen Änderung.
Setzen Sie den Objekt-Cache für geeignete Daten ein
Ein persistenter Objekt-Cache hilft bei wiederholten Abfragen und Berechnungen, wenn sie einen stabilen Schlüssel und eine sinnvolle Lebensdauer haben. Er sollte keine Abfrage retten, die alle Datensätze ohne Limit lädt. Überwachen Sie Hit Rate, Arbeitsspeicher, Evictions und die Latenz des Speichers. Ein falsch konfigurierter entfernter Cache-Server kann langsamer sein als die lokale Datenbank.
Versehen Sie Schlüssel mit einem Namespace nach Website und Umgebung, insbesondere bei Multisite oder gemeinsam genutztem Redis. Produktion und Staging dürfen nicht dieselben Objekte lesen. Erhöhen Sie bei einem Deployment mit geändertem Datenformat die Namespace-Version oder führen Sie eine sichere Invalidierung durch. Speichern Sie niemals eine sensible Antwort ohne Zugriffskontrolle als öffentliches Objekt.
- Stabiler Schlüssel mit Namespace
- Angemessene Lebensdauer und Größe
- Getrennte Umgebungen
- Überwachung von Speicher und Leerung
Testen Sie den Cache als funktionalen Bestandteil
Testen Sie den ersten und den wiederholten Besuch, ein anonymes und ein angemeldetes Fenster, zwei Sprachen, Mobilgeräte, Formulare und die Vorschau. Ändern Sie einen Artikel, ein Menü, einen Preis oder eine Berechtigung und messen Sie die Zeit bis zur korrekten Ausgabe. Prüfen Sie die Cache-Header, Age, Vary und den CDN-Status. Testen Sie nie nur als Administrator, für den der Cache häufig umgangen wird.
Gehen Sie bei einem Fehler schrittweise vom Browser über das CDN und den serverseitigen Page-Cache bis zum Object-Cache vor, statt alles gleichzeitig zu löschen. So finden Sie die verantwortliche Schicht. Führen Sie nach einem Update des Cache-Plugins einen Regressionstest der kritischen Pfade durch. Das Runbook sollte gezieltes Leeren, einen vollständigen Purge, die zu erwartende vorübergehende Last und den Kontakt zum Hosting beschreiben.
Häufige Fragen
Warum zeigt WordPress nach einer Änderung immer noch alte Inhalte an?
Eine veraltete Antwort kann im Browser, im CDN, im Page-Cache oder im Objekt-Cache gespeichert sein. Prüfen Sie die Header und leeren Sie die Ebenen schrittweise. Korrigieren Sie anschließend die Invalidierung bei der konkreten Änderung, damit der Redakteur nicht jedes Mal alles leeren muss.
Kann ich den WooCommerce-Warenkorb cachen?
Verwenden Sie für Warenkorb und Kasse keinen öffentlichen Page-Cache. Der Katalog kann mit Invalidierung von Preis und Lagerbestand gecacht werden. Konkrete Cookies, Fragmente und Endpunkte stellen Sie entsprechend WooCommerce, dem Hosting und den verwendeten Erweiterungen ein.
Sind mehr Cache-Schichten immer schneller?
Nein. Jede Schicht bringt zusätzliche Regeln, Invalidierung und einen möglichen Netzwerkschritt mit sich. Verwenden Sie nur Schichten mit messbarem Nutzen und einem klaren Verantwortlichen. Doppelte Page-Cache-Mechanismen können die Zuverlässigkeit verschlechtern.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
