WooCommerce mit LiteSpeed Cache prüfen: Produktseiten, Warenkorb, Kasse, Minicart, persönliche Sitzungen sowie Preis- und Bestandsänderungen.
Ein Shop braucht schnelle öffentliche Seiten und zuverlässige persönliche Abläufe. Ein Produkttext kann gemeinsam gecacht werden; ein Warenkorb muss zur jeweiligen Sitzung gehören. Die Abnahme besteht deshalb aus einer kleinen Einkaufsgeschichte mit mehreren Zuständen. Ein guter Wert für die Startseite beantwortet diese Frage noch nicht.
Öffnen Sie zuerst die erweiterten WooCommerce-Einstellungen und kontrollieren Sie die Zuordnung von Warenkorb, Kasse und Kundenkonto. Die Pfade können übersetzt oder individuell benannt sein. Eine englische Ausschlussliste aus einem fremden Projekt beweist daher nichts über die eigene Website. Notieren Sie die zugewiesenen WordPress-Seiten, die endgültigen URLs und die aktiven Endpunkte. Änderungen an dieser Zuordnung gehören in das Testprotokoll.
LiteSpeed dokumentiert, dass die korrekt zugeordneten Seiten für Cart, Checkout und My Account standardmäßig vom Seitencache ausgenommen werden. Prüfen Sie diese Schutzwirkung an Ihrer Installation trotzdem. Ein falsch zugewiesener Pfad oder eine individuelle Checkoutlösung kann anders behandelt werden. Die Abnahme richtet sich nach der Funktion der Seite und der wirklich beobachteten Antwort, nicht nach einem erwarteten Seitentitel.
Halten Sie zusätzlich fest, ob der Shop klassische Ansichten, WooCommerce-Blöcke oder eine eigene Integration nutzt. Unterschiedliche Frontends können persönliche Informationen über unterschiedliche Requests laden. Betrachten Sie neben dem HTML-Dokument deshalb auch die Antworten für Warenkorbinhalt und Checkoutaktualisierung. Eine öffentliche Hülle ist nur dann unproblematisch, wenn die darunterliegenden persönlichen Daten weiterhin korrekt getrennt und geschützt verarbeitet werden.
Wählen Sie wenige gezielte Testprodukte: einen einfachen Artikel, eine Variante mit Auswahl und einen Artikel mit sichtbarer Bestandsinformation. Legen Sie erwartete Preise, Varianten und Verfügbarkeit in der Testumgebung fest. Ein Testdatensatz muss nicht groß sein, aber er soll die fachlichen Unterschiede des Shops abbilden. Bei einem reinen Katalog ohne Bestellung entstehen andere Prüffälle als bei einem Shop mit Rabatten und Versandberechnung.
Benennen Sie den erwarteten Ablauf vor dem Start. Beispielsweise fügt Sitzung A einen roten Artikel hinzu, ändert die Menge und wählt eine Lieferregion. Sitzung B besucht nur die Produktseite und besitzt einen leeren Warenkorb. Es handelt sich um ein illustratives Testszenario, nicht um gemessene Ergebnisse. Die erwarteten Werte ermöglichen später eine eindeutige Entscheidung, ob ein Cachezustand korrekt war oder lediglich schnell erschien.
Verwenden Sie für Zahlungsabläufe den vom Zahlungsanbieter vorgesehenen Testmodus in einer dafür geeigneten Umgebung. Prüfen Sie keine reale Abbuchung aus Versehen. Auch E-Mails, Versandintegrationen und Warenwirtschaft können bei einer Testbestellung echte Folgeaktionen auslösen. Klären Sie diese Verbindungen vor dem Test und verwenden Sie die vorgesehenen Testwege. Die Cacheprüfung soll die Shoplogik beobachten, ohne unkontrollierte externe Vorgänge anzustoßen.
| Schritt | Erwartung | Prüfpunkt |
|---|---|---|
| Öffentliche Produktseite | Richtige Beschreibung und Auswahl | HTML, Preis, verfügbare Varianten |
| Artikel hinzufügen | Nur diese Sitzung erhält den Artikel | Warenkorb und Minicart |
| Menge oder Gutschein ändern | Summen werden konsistent neu berechnet | Dokument und Aktualisierungsrequest |
| Lieferregion wechseln | Passende Versand- und Steueranzeige | Sitzungsbezogene Berechnung |
| Testbestellung abschließen | Eindeutiger Erfolg ohne veraltete Daten | Bestätigung, Konto, erneuter Aufruf |
| Zweite Sitzung öffnen | Kein Zugriff auf fremde Auswahl | Leerer Warenkorb, eigenes Konto |
Untersuchen Sie zunächst die Produktseite ohne persönliche Sitzung. Wiederholen Sie denselben Aufruf und lesen Sie die Antwortheader des Dokuments. Das Verfahren aus HIT und MISS prüfen liefert einen konkreten Cachebeleg. Kontrollieren Sie zugleich, dass die Produktbeschreibung, die Auswahl und ein sichtbarer Verfügbarkeitshinweis richtig sind. Ein HIT ist nur dann ein brauchbares Ergebnis, wenn die Antwort fachlich passt.
Wird der Preis nach Nutzerrolle, Währung oder Lieferland verändert, reicht dieser eine Test nicht aus. Definieren Sie alle tatsächlich angebotenen Ansichten und vergleichen Sie sie mit getrennten Sitzungen. Eine öffentliche Variante darf keine individuelle Rabattberechtigung voraussetzen. Werden Preise erst nach Anmeldung sichtbar, prüfen Sie auch den Wechsel von der allgemeinen zur angemeldeten Ansicht. Die Cachekonfiguration muss der bestehenden Geschäftslogik folgen.
Vermeiden Sie pauschale Regeln, die sämtliche Produkt-URLs dynamisch machen, bevor der Fehler eingegrenzt ist. Es kann nur ein persönliches Fragment oder eine unpassende Variante betroffen sein. Ebenso ist ein erzwungener öffentlicher Cache für jede Produktseite keine sichere Standardlösung. Halten Sie den betroffenen Zustand klein und beschreiben Sie die Abweichung. Damit bleibt eine Korrektur nachvollziehbar und lässt sich später wieder testen.
Beginnen Sie mit zwei getrennten Browserprofilen. Fügen Sie in Profil A ein Produkt hinzu und besuchen Sie in Profil B dieselben Seiten. Wiederholen Sie den Test nach einem Purge und mit vertauschter Reihenfolge. Profil B darf weder Artikel, Lieferadresse noch Kundennamen aus A sehen. Kontrollieren Sie die Darstellung nach dem ersten Aufruf genauso wie nach wiederholten Aufrufen; manche Fehler entstehen erst beim gemeinsamen Befüllen einer Cachekopie.
Ändern Sie in A die Menge und entfernen Sie den Artikel anschließend wieder. Der kleine Warenkorb in der Kopfzeile, die ausführliche Warenkorbseite und die Kasse sollen denselben fachlichen Zustand zeigen. Eine korrekte Hauptseite mit veraltetem Minicart ist noch keine erfolgreiche Abnahme. Öffnen Sie dafür den Netzwerkbereich und beobachten Sie, welcher Request die jeweilige Anzeige aktualisiert. Notieren Sie das betroffene Element, statt nur allgemein von einem Cacheproblem zu sprechen.
Prüfen Sie An- und Abmeldung mit einem Testkonto. Nach der Anmeldung müssen dessen eigene Daten erscheinen; nach der Abmeldung darf ein neuer anonymer Request keine persönliche Kontoansicht liefern. Nutzen Sie keine Screenshots mit realen Kundendaten für das Supportticket. Die Zuordnung von Sitzung und Antwort lässt sich auch mit eindeutig benannten Testkonten zeigen. So bleibt der Befund präzise und kann von einer zweiten Person nachvollzogen werden.
LiteSpeed beschreibt die WooCommerce-Integration und ESI als Möglichkeit, öffentliche Seiten mit privaten Bestandteilen zusammenzusetzen. Die tatsächliche Unterstützung hängt vom Auslieferungspfad ab; OpenLiteSpeed unterstützt ESI laut Hersteller nicht. Klären Sie deshalb zuerst Servervariante und gegebenenfalls CDN. Der ESI-Leitfaden erläutert die getrennte Behandlung der Fragmente und ihre Abnahme. Ein Plugin-Schalter allein beweist keine funktionierende Serverunterstützung.
Ein Warenkorbindikator kann auch über eine andere Integration aktualisiert werden. Entscheidend ist die beobachtete Funktion in Ihrem Theme und Ihrer WooCommerce-Version. Prüfen Sie einen leeren Warenkorb, einen befüllten Warenkorb und den Zustand nach Entfernung des letzten Artikels. Vergleichen Sie dabei Mobilansicht und Desktop, weil Themes dort manchmal unterschiedliche Kopfzeilen besitzen. Ein nur auf einer Bildschirmbreite getestetes Fragment kann eine zweite, versteckte Ausgabe übersehen.
Die offizielle Kompatibilitätsübersicht ist ein guter Startpunkt für bekannte Integrationen. Sie ersetzt keine aktuelle Prüfung Ihrer Kombination aus Theme, Erweiterungen und konkreten Einstellungen. Notieren Sie die Versionen von Komponenten, die Warenkorb, Währung, Preise oder Anmeldung verändern. Wenn ein Fehler erst nach einem Update auftritt, lässt sich mit dieser Liste eine konkrete Änderung untersuchen. Ohne Versionsbezug bleibt die Suche unnötig breit.
Ändern Sie auf der Testumgebung eine sichtbare Produkteigenschaft und prüfen Sie die Produktseite danach als anonymer Besucher. Besuchen Sie zusätzlich die Kategorie und gegebenenfalls eine Startseitenauswahl, auf denen diese Eigenschaft erscheint. Ein erfolgreicher Purge des Einzelprodukts reicht nicht aus, wenn eine andere öffentliche Seite weiterhin den alten Preis oder Bestand zeigt. Die Abnahme umfasst die Stellen, an denen die Information wirklich ausgegeben wird.
LiteSpeed bietet im WooCommerce-Bereich Regeln für Aktualisierungen bei Bestandsänderungen. Wählen Sie deren Wirkung anhand Ihrer Darstellung. Ein Shop, der genaue Mengen auf Kategorien zeigt, hat andere Anforderungen als ein Katalog mit allgemeinem Verfügbarkeitsstatus. Übermäßig breite Purges können viele Seiten neu befüllen lassen; zu enge Regeln können sichtbare Angaben veralten lassen. Dokumentieren Sie die gewählte Abwägung und bestätigen Sie sie mit einem kleinen Änderungsfall.
Ein Cache ersetzt keine Bestandsprüfung im Bestellprozess. Eine öffentlich gespeicherte Anzeige kann zwischen zwei Aufrufen bereits überholt sein. Die Anwendung muss die kaufrelevanten Bedingungen im vorgesehenen Ablauf erneut bewerten. Untersuchen Sie deshalb nicht nur die Produktdarstellung, sondern auch die Reaktion beim Hinzufügen und beim Abschluss. Eine aktuelle Informationsseite und eine korrekte Transaktion sind zwei zusammengehörige, eigenständige Nachweise.
Wenn der Shop ohne zusätzliche CSS- und JavaScript-Umformung korrekt arbeitet, können Sie eine einzelne Optimierung untersuchen. Verzögertes JavaScript kann beispielsweise die Reaktion eines Buttons oder einer Formularprüfung beeinflussen. Die CSS- und JS-Anleitung beschreibt einen kontrollierten Vergleich. Prüfen Sie dabei ausdrücklich Tastaturbedienung und die erste Interaktion, bevor eine bessere Kennzahl als Erfolg gewertet wird.
Bleibt ein Fehler bestehen, notieren Sie die kleinste reproduzierbare Handlung: betroffene URL, Sitzungszustand, Klick, erwartete Anzeige und tatsächlich beobachtete Antwort. Halten Sie fest, welche einzelne Optimierung aktiviert war. Eine solche Beschreibung ermöglicht eine gezielte Ausnahme oder Korrektur. Das gleichzeitige Abschalten aller Funktionen kann als Diagnosevergleich dienen, erklärt aber noch nicht die Ursache und sollte nicht das einzige Ergebnis des Tests bleiben.
Eine veraltete Versandangabe kann aus einer gespeicherten HTML-Antwort, einem nicht ausgeführten Aktualisierungsrequest oder einer fachlich falschen Berechnung stammen. Vergleichen Sie deshalb zuerst den sichtbaren Zustand mit der beobachteten Antwort des zugehörigen Requests. Liefert die Antwort bereits den richtigen Wert, untersuchen Sie die Verarbeitung im Frontend. Liefert sie den falschen Wert, halten Sie Anfrageparameter und Sitzung fest und prüfen Sie den serverseitigen Ablauf. Diese Zuordnung spart unnötige Änderungen an unbeteiligten Cacheebenen und macht die spätere Korrektur überprüfbar.
Ein gezielter weiterer Test untersucht eine abgebrochene Einkaufssitzung. Beginnen Sie mit einem Testartikel, öffnen Sie die Kasse und kehren Sie ohne Abschluss zur Produktseite zurück. Der Warenkorb soll den vorgesehenen Zustand behalten. Öffnen Sie danach eine neue getrennte Sitzung, in der dieser Artikel weiterhin fehlt. Dieser Ablauf prüft einen anderen Pfad als die erfolgreiche Testbestellung und kann eine Kopfzeile erreichen, die nur auf öffentlichen Seiten angezeigt wird. Halten Sie die Reihenfolge fest, damit der Fall wiederholt werden kann.
Bei einem Fehler vergleichen Sie die HTML-Antwort der Produktseite und den Request, der den Minicart versorgt. Trägt bereits das öffentliche Dokument die Auswahl von A, liegt die Trennung vor der Frontendaktualisierung falsch. Ist das Dokument allgemein und die spätere Antwort korrekt, kann die sichtbare Verarbeitung verantwortlich sein. Wird dagegen der Aktualisierungsrequest durch eine neue Optimierung erst nach dem zweiten Klick gestartet, untersuchen Sie diese Einstellung. Eine einzelne beobachtete Verzögerung sollte nicht zu einer pauschalen Änderung aller Cachefunktionen führen.
Ergänzen Sie für Ihr Projekt einen kleinen Erwartungssatz zu jedem Sonderfall. Bei Abonnements kann eine andere Darstellung gelten als bei einem einmaligen Kauf; bei digitalen Artikeln fehlt möglicherweise eine Versandberechnung. Testen Sie die tatsächlich angebotenen Wege. Eine unbenutzte Funktionsliste aus einem Musterprojekt macht die Abnahme länger, aber nicht aussagekräftiger.
Die Checkliste enthält keine automatische Freigabe für einen Shop. Sie hilft, konkrete Prüfergebnisse zu sammeln. Ergänzen Sie besondere Abläufe wie Abonnements, Geschäftskundenpreise oder Buchungen um eigene Fälle. Für den Serverbetrieb führen die Artikel zu Redis Object Cache und Staging und sicherem Betrieb weiter.
7. Oktober 2026. Einstellungen und Prüffälle müssen an die tatsächliche Shopintegration angepasst werden.