Full-Page-Cache in PrestaShop: wann er sich lohnt und was draußen bleiben muss

Jedes Mal, wenn jemand eine Produktseite öffnet, startet PrestaShop, fragt die Datenbank Dutzende oder Hunderte Male ab, setzt das Template zusammen und gibt das HTML zurück. Beim nächsten Besucher derselben Seite wiederholt es exakt dieselbe Arbeit. Der Full-Page-Cache speichert dieses HTML beim ersten Mal und liefert es danach direkt aus, ohne PrestaShop auszuführen.

Der Unterschied in der Antwortzeit des Servers kann enorm sein. Aber ein Shop ist kein Blog: Er hat Warenkorb, Sitzung, kundenspezifische Preise und ein Cookie-Banner. Das Falsche zu cachen ist der schnellste Weg, einem Kunden den Warenkorb eines anderen zu zeigen.

Die Caches, die PrestaShop schon hat (und der Unterschied)

• Smarty-Template-Cache: speichert die kompilierten Templates. Das beschleunigt das Zusammensetzen, aber PrestaShop läuft weiterhin bei jedem Besuch.
• Objekt- oder Abfrage-Cache (Memcached, Redis, APCu): speichert Abfrageergebnisse. Weniger Last auf der Datenbank, aber PHP läuft weiterhin.
• OPcache: speichert den kompilierten PHP-Code. Unverzichtbar und hat mit dem HTML nichts zu tun.
• Full-Page-Cache: speichert das Endergebnis. Er ist der einzige, der die Ausführung von PrestaShop vermeidet.

Sie konkurrieren nicht, sie ergänzen sich. Ein gut aufgesetzter Shop hat immer OPcache und je nach Traffic und Katalog einen Abfrage- und einen Seiten-Cache.

Welche Seiten sich cachen lassen

Die Faustregel: Gecacht wird für den anonymen Besucher ohne Warenkorb. Sobald eine Kundensitzung besteht oder Produkte im Warenkorb liegen, wird die Seite normal erzeugt.

Was vor dem Aktivieren zu klären ist

Dynamische Teile in einer cachebaren Seite

Die Produktseite ist für alle gleich, der Warenkorbzähler im Header aber nicht. Ebenso wenig das „Hallo, Marta“ oder die Preise, wenn Sie Kundengruppen mit unterschiedlichen Preislisten haben. Es gibt zwei Lösungen: nicht cachen für alle mit Sitzung oder Warenkorb, oder diese Teile nachträglich per AJAX laden. Die erste ist die sicherste.

Preise nach Gruppe, Land oder Währung

Sieht ein B2B-Kunde andere Preise, darf er nie die gecachte Version des anonymen Besuchers erhalten, und umgekehrt. Dasselbe gilt für Währungen und Länder mit anderen Steuern: Entweder wird pro Kombination eine Version gespeichert, oder diese Besuche werden nicht gecacht.

Mobil und Desktop

Erzeugt Ihr Theme für Mobilgeräte anderes HTML, brauchen Sie getrennte Versionen pro Gerät. Bei einem rein responsiven Theme genügt eine Version.

Cookies und Einwilligung

Dieser Punkt wird am häufigsten übersehen. Entscheidet Ihr Cookie-Banner serverseitig, welche Skripte ausgegeben werden, „friert“ die erste gecachte Seite die Entscheidung desjenigen ein, der sie erzeugt hat. Ein Besucher, der alles akzeptiert hat, erzeugt die Seite mit aktiven Pixeln, und der nächste, der sich noch nicht entschieden hat, bekommt sie trotzdem.

Die üblichen Lösungen: Das Banner blockiert im Browser, auf einer für alle gleichen Seite, oder der Cache speichert je nach Einwilligungsstatus getrennte Versionen.

Invalidieren: das eigentliche Problem

Cachen ist einfach. Schwierig ist zu wissen, wann eine gespeicherte Seite nicht mehr stimmt. In einem Shop passiert das ständig:

• Sie ändern einen Preis oder eine Beschreibung.
• Sie aktivieren eine Warenkorbregel oder einen Sonderpreis.
• Ein Produkt ist nach einer Bestellung ausverkauft.
• Sie bearbeiten eine Kategorie, einen Hersteller oder eine CMS-Seite.

Bekommt der Cache das nicht mit, sehen Kunden den alten Preis oder ein „verfügbares“ Produkt, das es nicht mehr ist. Es gibt zwei Strategien: Ablauf nach Zeit (die Seite gilt eine Stunde und wird dann neu erzeugt) und Leeren nach Ereignis (beim Speichern eines Produkts wird geleert, was es betrifft). Richtig ist die Kombination: Leeren bei Änderungen und Ablauf als Sicherheitsnetz.

Und das sollten Sie wissen: Änderungen, die nicht über das Backoffice laufen, etwa ein Import per direktem SQL oder ein ERP, das ohne API in die Datenbank schreibt, lösen kein Ereignis aus. Kommt Ihr Bestand so herein, müssen Sie den Cache am Ende jeder Synchronisierung leeren.

Wann es sich nicht lohnt

• Shops mit fast nur angemeldetem Traffic, etwa ein B2B-Shop, in dem sich alle anmelden: Die Trefferquote wird niedrig sein.
• Kataloge, die sich alle paar Minuten ändern, weil sie mit Lieferanten synchronisiert werden: Der Cache wird geleert, bevor er etwas ausliefert.
• Ein Server, der aus einem anderen Grund langsam ist: eine schlecht indizierte Abfrage oder ein Modul, das auf jeder Seite eine externe API aufruft. Der Cache verdeckt das für anonyme Besucher, aber der kaufende Kunde leidet weiter im Checkout, und genau dort zählt es.

Zuerst eine aktuelle Basis

Ein Seiten-Cache auf PHP 7.x und PrestaShop 1.6 liefert anonymen Besuchern zwar schnell aus, aber Warenkorb und Zahlung, die nie gecacht werden, bleiben genauso langsam. Mit PHP 8, gut konfiguriertem OPcache und aktuellem PrestaShop ist der nicht cachebare Teil bereits viel schneller. Deshalb ist in einem stark veralteten Shop das Update meist der erste Schritt für die Performance und der Cache der zweite.

Checkliste vor dem Aktivieren

• OPcache aktiv und mit ausreichend Speicher.
• Warenkorb, Bestellung, Zahlung, Konto und Modul-Controller ausgeschlossen.
• Kein Cache für Besucher mit Sitzung oder Warenkorb, oder dynamische Teile per AJAX.
• Einwilligungstest in zwei privaten Fenstern.
• Preistest: einen Preis ändern und prüfen, ob die Produktseite ihn zeigt.
• Bestandstest: das letzte Stück bestellen und die Produktseite ansehen.
• Leeren am Ende jeder externen Synchronisierung.

So lösen Sie es in PrestaShop

All In One Cache verwaltet drei Caches in einem Panel: Full-Page-Cache auf der Festplatte, SQL-Abfragen in Redis (PrestaShop 8 oder höher, wobei die Tabellen für Bestellungen, Warenkörbe, Sitzungen und Bestand standardmäßig gesperrt sind) und OPcache. Beim Seiten-Cache legen Sie fest, was draußen bleibt, auch URLs per regulärem Ausdruck, können Versionen nach Gerät trennen, und das Leeren hängt an PrestaShop: Beim Speichern eines Produkts, einer Kategorie, eines Sonderpreises, einer Warenkorbregel oder einer CMS-Seite wird geleert, und beim Bestätigen einer Bestellung oder einer Bestandsänderung wird der Bestand betreffende Teil geleert. Sie können auch eine einzelne URL oder alles im Panel leeren und sehen Treffer und Fehlschläge. Wenn Sie ihn lieber von uns in Ihrem Shop konfiguriert und getestet haben möchten, gibt es den All-In-One-Cache-Service.