Eine gecachte Seite darf nie die Daten eines einzelnen Besuchers enthalten. Das schließt Seiten für angemeldete Benutzer sowie Warenkorb, Kasse und Konto aus. Dasselbe gilt für Seiten, die mit einer Sitzung oder einem gefüllten Warenkorb erzeugt wurden, und für Antworten, die ein Cookie setzen oder als privat markiert sind. Alles andere lässt sich cachen, solange Filterparameter in den Cache-Schlüssel eingehen, Tracking-Parameter draußen bleiben, Preisänderungen einen Purge auslösen und keine Seite länger lebt als ihre Nonces.
Die Regeln gelten für jeden Page Cache. Zahlen und Dateinamen stammen vom Page Cache von CachePilot, einem Beispiel dafür, wie die Regeln im Code aussehen.
Was darf nie in den Cache?
Der Caching-Leitfaden von WooCommerce nennt die Seiten Warenkorb, Kasse und Konto und führt die Cookies auf, die WooCommerce verwendet. Ein Page Cache muss zweimal entscheiden, einmal vor der Antwort auf eine Anfrage und einmal nach dem Erzeugen einer Seite, bevor er sie speichert.
Anfragen, die am Cache vorbeigehen
| Regel | Grund |
|---|---|
| Regel: Angemeldete Benutzer, geschützte Beiträge, Kommentarautoren | Grund: Die Cookies wordpress_logged_in, wp-postpass und comment_author kennzeichnen persönliche Ausgaben |
| Regel: Warenkorb, Kasse und Kontoseiten | Grund: Ihr Inhalt gehört zu einem einzelnen Besucher |
| Regel: Alles außer GET und HEAD | Grund: Andere Methoden ändern Daten, Warenkorb-Fragmente sind die einzige Ausnahme |
| Regel: Admin, AJAX, Cron, REST-API, Feeds, Embeds, XML- und PHP-Dateien | Grund: Diese Antworten sind keine Seiten für Besucher |
| Regel: Unbekannte Query-Parameter | Grund: Parameter wie add-to-cart oder der Suchparameter s ändern, was die Anfrage bewirkt |
| Regel: Das Cookie woocommerce_recently_viewed | Grund: Das Widget listet die Produkte dieses Besuchers auf |
| Regel: Ein Sitzungscookie, wenn sich die Steuer nach der Kundenadresse richtet | Grund: Angezeigte Preise hängen vom Besucher ab |
Seiten, die nie gespeichert werden
| Regel | Grund |
|---|---|
| Regel: Angemeldeter Benutzer oder DONOTCACHEPAGE | Grund: WordPress-Plugins nehmen mit dieser Konstante eine Seite vom Cache aus |
| Regel: Gefüllter Warenkorb oder WooCommerce-Sitzung | Grund: Die Seite kann Warenkorb-Hinweise oder Preise für die Adresse des Besuchers zeigen |
| Regel: Preis, der mit Geolokalisierung erzeugt wurde | Grund: Der Preis gilt für einen Standort |
| Regel: Set-Cookie-Header oder Cache-Control mit no-cache, no-store oder private | Grund: Die Antwort kennzeichnet sich selbst als persönlich |
| Regel: Suchergebnisse, 404-Seiten, Feeds und Embeds | Grund: Sie werden selten zweimal abgerufen |
| Regel: Unvollständiges HTML | Grund: Unter 255 Byte oder ohne schließendes html-Tag würde eine fehlgeschlagene Ausgabe jeden Besucher erreichen |
Besucher mit gefülltem Warenkorb
Die einfache Variante umgeht den Cache für jeden Besucher mit Warenkorb-Cookie. Das ist sicher, nur bekommen diese Besucher keine Cache-Treffer. Die andere Variante liefert ihnen gecachte Seiten aus und füllt den Mini-Warenkorb über Warenkorb-Fragmente, während Seiten, die für sie erzeugt werden, nicht gespeichert werden.
CachePilot nutzt die zweite Variante. Sie hängt vom Theme ab. Ein Theme, das die Artikelzahl des Warenkorbs ins HTML der Seite schreibt, braucht die erste.
Warum sind Tracking-Parameter wichtig?
Links aus Newslettern, Anzeigen und sozialen Netzwerken tragen Parameter wie utm_source, gclid oder fbclid. An der Seite ändern sie nichts. Im Cache-Schlüssel würde jeder Kampagnenlink eine eigene Kopie der Seite erzeugen, und fast jeder Besucher aus einer Kampagne bekäme einen Fehlschlag (MISS).
Ein Page Cache sollte diese Parameter aus dem Schlüssel herauslassen. Die Liste von CachePilot orientiert sich an WP Rocket 3.24 und hat 61 Einträge, darunter vier Präfixe für eine ganze Familie: utm_*, mtm_*, pk_* und hsa_*.
Wie werden Shop-Filter gecacht?
Filter-, Sortier- und Paginierungsparameter verändern die Seite und gehören deshalb samt Werten in den Schlüssel. Werden sie vorher sortiert, teilen sich ?orderby=price&paged=2 und ?paged=2&orderby=price einen Eintrag. Die Liste von CachePilot hat 14 Einträge, darunter orderby, paged, min_price, max_price und die Präfixe filter_*, query_type_* und attribute_*.
Ein Limit verhindert, dass Crawler, die jeden Filter kombinieren, Redis mit Seiten füllen, die nie wieder jemand abruft. In CachePilot umgeht eine Anfrage mit mehr als 6 cachebaren Parametern den Cache.
Währungscookies brauchen dieselbe Behandlung, damit ein Besucher, der eine andere Währung gewählt hat, die Seite in dieser Währung bekommt. Sprachen und Währungen behandelt die Seite zu mehrsprachigen Websites.
Was ist mit Warenkorb-Fragmenten?
WooCommerce aktualisiert den Mini-Warenkorb mit einer POST-Anfrage an ?wc-ajax=get_refreshed_fragments. Jede dieser Anfragen startet WordPress, und für einen Besucher mit leerem Warenkorb ist die Antwort immer gleich.
CachePilot cacht diese eine Anfrage, solange beide Warenkorb-Cookies, woocommerce_cart_hash und woocommerce_items_in_cart, leer sind. Sobald der Warenkorb Artikel enthält, geht die Anfrage wie gewohnt an WooCommerce.
Wann müssen gecachte Seiten gelöscht werden?
Änderungen über die WooCommerce-API, REST, WP-CLI, Importe und geplante Angebote lösen kein normales Speichern eines Beitrags aus. Ein Cache, der nur auf gespeicherte Beiträge reagiert, behält danach alte Preise. CachePilot löscht nach diesen Regeln:
- Bestand. Eine Änderung von Bestand oder Lagerstatus löscht die Produktseite samt ihren Shop- und Kategorieseiten.
- Preise. Eine Änderung von Preis, Angebotszeitraum, Steuerstatus oder Steuerklasse leert den ganzen Page Cache, weil ähnliche Produkte, Upsells und Produktblöcke diesen Preis auch auf anderen Seiten zeigen.
- Shop-Einstellungen. Währung, Preisformat, Steuereinstellungen, Steuersätze und WCML-Preise leeren den Page Cache einmal am Ende der Anfrage, eine Massenbearbeitung leert ihn also nur einmal.
- Inhalte. Das Speichern eines Beitrags löscht dessen paginierte Seiten, Nachbarbeiträge, Autoren-, Datums- und Elternseiten, Terme und WPML-Übersetzungen. Menüs, Widgets, Website-Titel und Permalinks leeren den ganzen Cache.
Warum höchstens 12 Stunden?
Viele Shop-Seiten enthalten Nonces, zum Beispiel für die Store API oder REST-Anfragen aus der Seite heraus. Eine WordPress-Nonce gilt 12 bis 24 Stunden, je nachdem, wann in ihrem Zyklus sie erzeugt wurde. Eine gecachte Seite, die älter als 12 Stunden ist, kann eine abgelaufene Nonce enthalten, und ein Button oder Formular darauf funktioniert dann nicht.
CachePilot begrenzt die Lebensdauer von Seiten auf 43.200 Sekunden, also 12 Stunden, unabhängig von den Einstellungen. Autopilot verwendet 10 Stunden.
Wie prüfe ich, was mit einer Seite passiert ist?
Drei Tests auf einer Staging-Kopie decken bei jedem Page Cache die wichtigsten Risiken ab:
- Legen Sie in einem Browser ein Produkt in den Warenkorb und öffnen Sie dieselbe Seite in einem anderen Browser. Der zweite muss einen leeren Warenkorb zeigen.
- Ändern Sie einen Preis und laden Sie dann die Produktseite und ihre Kategorieseite neu.
- Laden Sie eine Seite zweimal mit ?utm_source=test. Die zweite Anfrage sollte ein Treffer (HIT) sein.
In CachePilot ergänzt das Modul Debug HTML-Seiten um einen Kommentar. Er nennt den Status des Page Cache und den Grund für eine Umgehung, zum Beispiel „WooCommerce page“ oder „Cart not empty“.
Wie CachePilot in einem Shop arbeitet, beschreibt die Seite zu WooCommerce.
Quellen
- WooCommerce-Entwicklerdokumentation, Caching-Plugins konfigurieren: Seiten und Cookies.
- WordPress-Entwicklerdokumentation, Nonces: Lebensdauer von 12 bis 24 Stunden.
- plugin/pagecache-rules.php: cachepilot_pc_defaults() mit 61 ignorierten und 14 cachebaren Parametern, cachepilot_pc_decide() mit der Regel für Warenkorb-Fragmente, CACHEPILOT_PC_MAX_PARAMS = 6.
- PageCacheModule.php in modules/PageCache des Plugins: shouldBypass(), getNoStoreReason(), wooCommerceRules(), MAX_PAGE_TTL = 43200, AUTOPILOT_TTL = 36000, PRICE_PROPS, FLUSH_HOOKS.
- plugin/readme.txt, Changelog 1.3.0 und 1.4.1.
