LSCache für WooCommerce richtig einstellen

LSCache liefert fertige Seiten direkt aus dem Webserver aus — PHP und Datenbank bleiben außen vor. Bei einem Blog ist das trivial: Jede Seite sieht für jeden Besucher gleich aus. Bei einem WooCommerce-Shop nicht. Warenkorb, Kasse und Kundenkonto sind für jeden Besucher anders, und eine falsch gecachte Kasse ist kein Performance-Problem, sondern ein Datenschutz-Vorfall. Dieser Artikel zeigt, wie Du das offizielle LiteSpeed-Cache-Plugin für WooCommerce so einstellst, dass Produktseiten aus dem Cache kommen und trotzdem niemand den Warenkorb eines Fremden sieht.

Voraussetzung: WordPress mit WooCommerce auf unserem LiteSpeed Webhosting, das Plugin „LiteSpeed Cache“ ist installiert und aktiv. Die Grundaktivierung dauert zwei Minuten — Plugin installieren, fertig, der Rest dieses Artikels ist Feintuning.

Public Cache und Private Cache — der Unterschied in einer Minute

LSCache kennt zwei Ablagen:

• Public Cache: eine Kopie pro URL, ausgeliefert an alle Besucher. Perfekt für Produktseiten, Kategorien und die Startseite.
• Private Cache: eine Kopie pro Besucher, gebunden an dessen Session-Cookie. Nur der eine Besucher bekommt sie zu sehen.

Die Regel für Shops: Alles, was für jeden gleich aussieht, gehört in den Public Cache. Alles Personalisierte — Warenkorb (/warenkorb/), Kasse (/kasse/), Mein Konto (/mein-konto/) — darf niemals im Public Cache landen. Der Worst Case ist schnell erklärt: Kunde B sieht Rechnungsadresse und Warenkorb von Kunde A.

Die gute Nachricht: LSCache erkennt WooCommerce automatisch und nimmt diese Seiten von sich aus vom Public Cache aus. Verlassen würden wir uns darauf trotzdem nicht blind — typische Gründe, warum es doch schiefgeht, sind umbenannte Seiten-Slugs (englisches /cart/ statt /warenkorb/, nachträglich geänderte Permalinks) oder Checkout-Plugins mit eigener URL. Prüfen kannst Du das in zwei Minuten, siehe Abschnitt Erfolgskontrolle.

Wenn Dein Checkout unter einer eigenen URL läuft: LiteSpeed Cache → Cache → Tab „Ausschlüsse“ (Excludes) → „URIs nicht cachen“, eine URI pro Zeile:

/schnellkasse/
/mein-sonderbereich/

Die WooCommerce-Grundeinstellungen

Unter LiteSpeed Cache → Cache erscheint der Tab „WooCommerce“ automatisch, sobald WooCommerce aktiv ist. Drei Einstellungen zählen:

• Product Update Interval: steuert, was bei Lager-Änderungen aus dem Cache fliegt. Der Standard („Produkt bei Änderung von Menge oder Lagerstatus leeren, Kategorien nur bei Änderung des Lagerstatus“) ist in 95 % der Fälle die richtige Wahl. Nur wenn Deine Kategorieseiten Lagerbestände anzeigen, nimm die Variante, die auch Kategorien bei jeder Mengenänderung leert.
• Use Front Page TTL for the Shop Page: an — die Shop-Übersicht bekommt dann dieselbe Lebensdauer wie die Startseite.
• Privately Cache Cart: darf an. Die Warenkorb-Seite landet dann im privaten Cache des jeweiligen Besuchers — beschleunigt wiederholte Aufrufe, ohne dass je ein fremder Warenkorb auftaucht.

Der Mini-Warenkorb: hier kommt ESI ins Spiel

Der Mini-Warenkorb im Header steht auf jeder Seite — und zeigt pro Besucher etwas anderes. Sobald ein Besucher etwas in den Warenkorb legt, setzt WooCommerce das Cookie woocommerce_items_in_cart, und LSCache liefert diesem Besucher standardmäßig keine öffentlichen Cache-Kopien mehr aus, weil der Zähler sonst falsch wäre. Ergebnis ohne Gegenmaßnahme: Genau die Besucher, die kurz vor dem Kauf stehen, surfen ungecacht und damit am langsamsten durch Deinen Shop.

Die Lösung heißt ESI (Edge Side Includes): Die Seite kommt weiter aus dem Public Cache, hat aber „Löcher“, die der Webserver pro Besucher aus dem Private Cache füllt — der Mini-Warenkorb ist so ein Loch. Das funktioniert bei uns ohne Verrenkungen, weil auf den Servern LiteSpeed Enterprise läuft und die ESI-Unterstützung damit vollständig ist.

Einschalten unter LiteSpeed Cache → Cache → Tab „ESI“:

1. „ESI aktivieren“ auf AN.
2. „Admin-Bar cachen“ und „Kommentarformular cachen“ angeschaltet lassen — beides wird dann als privater ESI-Block ausgeliefert.
3. Nutzt Du den klassischen Mini-Warenkorb als Widget: Design → Widgets → Widget öffnen — dort hängt eine LSCache-Box dran. „ESI aktivieren“ auf „Privat“ stellen, TTL kann bei den vorgeschlagenen Werten bleiben.

Ein Hinweis aus der Praxis: Viele aktuelle Themes laden den Mini-Warenkorb ohnehin per AJAX nach (im Netzwerk-Tab als ?wc-ajax=get_refreshed_fragments sichtbar). Dann stimmt der Zähler auch aus dem Public Cache, ganz ohne ESI. Erst testen, dann konfigurieren — wenn der Warenkorb-Zähler im privaten Browserfenster nach dem Hinzufügen eines Produkts korrekt hochzählt, musst Du an ESI gar nicht ran.

TTL für Produktseiten

TTL (Time to Live) bestimmt, wie lange eine Cache-Kopie gültig bleibt. Einstellbar unter LiteSpeed Cache → Cache → Tab „TTL“ → „Standard-TTL für öffentlichen Cache“. Der Plugin-Default liegt bei 604800 Sekunden — eine Woche.

Das klingt für einen Shop riskant, ist es aber nicht: Preis- und Lager-Änderungen räumen die betroffenen Seiten gezielt aus dem Cache (nächster Abschnitt), die TTL ist nur das Sicherheitsnetz dahinter. Wir stellen bei Shops trotzdem gern 86400 Sekunden (1 Tag) ein — falls doch mal ein Purge nicht greift, ist der Schaden auf einen Tag begrenzt. Die private TTL kann beim Default von 1800 Sekunden bleiben.

Purge bei Lagerbestand und Preisänderung

Im Normalbetrieb musst Du nichts tun: Speicherst Du ein Produkt mit neuem Preis, leert das Plugin die Produktseite automatisch. Geht durch eine Bestellung der Lagerbestand runter, greift die „Product Update Interval“-Regel von oben und leert Produkt- und gegebenenfalls Kategorieseiten.

Die typische Stolperfalle sind Massen-Änderungen, die an WordPress vorbeilaufen: CSV-Importe, Warenwirtschafts-Anbindungen oder direkte Datenbank-Updates lösen die WordPress-Hooks nicht immer aus — dann bleibt die alte Kopie bis zum TTL-Ablauf sichtbar. Nach jedem Import deshalb einmal komplett leeren: Admin-Leiste → LiteSpeed Cache → „Alles leeren“, oder per SSH mit WP-CLI (in jedem Tarif dabei):

wp litespeed-purge all

Den Befehl kannst Du auch ans Ende eines Import-Skripts oder Cronjobs hängen.

Erfolgskontrolle: läuft der Cache wirklich?

Der Beweis steht im Response-Header x-litespeed-cache. Per SSH oder vom eigenen Rechner:

curl -sI https://dein-shop.de/produkt/beispiel/ | grep -i x-litespeed

Erster Aufruf: x-litespeed-cache: miss (Seite wurde frisch gebaut und abgelegt). Zweiter Aufruf: hit — der Cache arbeitet.

Dann die Gegenprobe auf den kritischen Seiten:

curl -sI https://dein-shop.de/kasse/ | grep -i x-litespeed

Hier darf niemals ein hit erscheinen. Taucht doch einer auf: sofort die Ausschlüsse prüfen (Slugs, Checkout-Plugin-URLs, siehe oben).

Im Browser geht das über F12 → Netzwerk-Tab → Seite neu laden → Response-Header des ersten Eintrags. Wichtig dabei: Als eingeloggter Admin siehst Du fast immer miss oder gar keinen Header — eingeloggte Nutzer bekommen standardmäßig keinen Public Cache. Zum Testen immer ein privates Fenster nehmen.

Stolperfalle: Session-Cookies von Drittplugins

Der häufigste Grund, warum ein Shop trotz korrekter Einstellungen kaum Cache-Hits produziert: Ein Plugin startet auf jeder Seite eine PHP-Session. Klassische Kandidaten sind Währungsumschalter, Buchungs- und Termin-Plugins oder ältere Wunschlisten-Plugins. Die Folge: Jede Antwort trägt einen Set-Cookie-Header, LSCache stuft die Seite als personalisiert ein, und die Hit-Rate liegt im Keller — ohne eine einzige Fehlermeldung.

So findest Du es heraus:

curl -sI https://dein-shop.de/produkt/beispiel/ | grep -i set-cookie

Ein PHPSESSID beim allerersten anonymen Aufruf einer Produktseite ist das Warnsignal. (Ein wp_woocommerce_session_…-Cookie, das erst nach einer Warenkorb-Aktion auftaucht, ist dagegen normal.)

Die Behebung in dieser Reihenfolge: Verursacher eingrenzen — Plugins nacheinander deaktivieren, am besten auf einem Staging-Klon über das WordPress Toolkit in Plesk statt am Live-Shop. Dann in den Einstellungen des Verursachers nach einem AJAX- oder „cache-kompatiblen“ Modus suchen; viele Währungs-Plugins haben so eine Option. Gibt es keine, lohnt der Blick auf eine Alternative. Und wenn Du nicht weiterkommst: Ticket über mein.xaweho.de/kontakt — wir schauen uns die Header gemeinsam an.

Häufige Fragen

Brauche ich zusätzlich WP Rocket, W3 Total Cache oder ähnliches? Nein — im Gegenteil. Zwei Page-Cache-Plugins wissen nichts voneinander und leeren sich gegenseitig nicht; das führt zu genau den veralteten Seiten, die Du vermeiden willst. Auf LiteSpeed ist das LSCache-Plugin die richtige Wahl, weil es den Cache im Webserver nutzt statt einer PHP-Behelfslösung. Bildoptimierung oder CSS-Minify aus anderen Plugins kannst Du behalten, den Page-Cache-Teil dort abschalten.

Werden eingeloggte Kunden auch beschleunigt? Nicht über den Public Cache — der ist für anonyme Besucher, und die machen in fast jedem Shop den Großteil des Traffics aus. Eingeloggte Nutzer profitieren von privatem Cache und ESI-Blöcken, der große Hebel bleibt aber der öffentliche Cache für Produkt- und Kategorieseiten.

Ein Kunde meldet, sein Warenkorb zeigt falsche Artikel — was tun? Erst „Alles leeren“, dann mit den curl-Tests von oben prüfen, ob /warenkorb/ und /kasse/ wirklich vom Cache ausgenommen sind. Der Klassiker dahinter: Seiten-Slugs, die nach einem Theme- oder Sprachpaket-Wechsel nicht mehr zu den Ausschlüssen passen.

Wie oft sollte ich den Cache komplett leeren? Im Normalbetrieb: gar nicht. Produkt-Updates und Bestellungen purgen automatisch und gezielt. Komplett leeren nur nach Theme-Änderungen, Plugin-Updates mit Frontend-Wirkung und CSV-Importen. Wer täglich „Alles leeren“ klickt, verschenkt genau die Hits, für die der Cache da ist.

Nach welcher Kennzahl sehe ich, ob sich das alles gelohnt hat? Time-to-First-Byte (TTFB) einer Produktseite, gemessen im privaten Fenster oder per curl -w. Ungecacht liegt WooCommerce je nach Plugin-Last oft bei mehreren hundert Millisekunden — aus dem Cache sind zweistellige Werte normal. Vorher messen, einstellen, nachher messen.

Weiter geht’s

• LiteSpeed Webhosting — die Produktseite. Dort steht auch der Pauschalpreis, falls wir Deinen Shop komplett umziehen sollen.
• PHP-Version wählen und einstellen — der zweite Performance-Hebel neben dem Cache.
• WordPress-Toolkit in Plesk — Staging-Klon anlegen, um Plugin-Tests nicht am Live-Shop zu machen.