Der PrestaShop-Cache besteht aus mehreren Ebenen

Wenn ich einen langsamen PrestaShop untersuche, kläre ich zuerst, worauf der Kunde eigentlich wartet. Antwortet die Kategorieseite zu spät, liegt das Problem an einer anderen Stelle als bei Produktfotos, deren Download zu lange dauert. Auch eine schnelle Startseite sagt wenig über die Geschwindigkeit des Bestellvorgangs aus. Ein Cache hilft, indem er bereits berechnete Ergebnisse erneut bereitstellt. Entscheidend ist jedoch, was gespeichert wird, welcher Kunde dieses Ergebnis erhalten darf und wann es seine Gültigkeit verliert.

In PrestaShop greifen unter anderem Template-Cache, Daten-Cache, PHP-Cache, Browser-Cache und gegebenenfalls ein vollständiger Seiten-Cache ineinander. Jede Ebene erfüllt eine andere Aufgabe. Zudem unterscheiden sich die verfügbaren Einstellungen und ihre Bezeichnungen je nach Version und Übersetzung des Backoffice. Dieser Überblick berücksichtigt deshalb sowohl heutige Möglichkeiten als auch ältere Technologien, die bei bestehenden Shops noch auftauchen. Ein Eintrag im Backoffice bedeutet nicht automatisch, dass die Hosting-Umgebung diese Technik unterstützt.

Smarty: Templates kompilieren und Ausgaben zwischenspeichern

Mein erster Blick gilt meist Erweiterte Einstellungen → Leistung. Smarty übersetzt die Templates des Themes in ausführbaren PHP-Code. Die Kompilierung bei jedem Seitenaufruf zu erzwingen, ist bei der Entwicklung oder Fehlersuche hilfreich, verursacht im Livebetrieb aber unnötige Arbeit. Häufig ist es sinnvoll, Templates nur nach einer Dateiänderung neu kompilieren zu lassen. Ganz auf die Prüfung von Änderungen zu verzichten, setzt voraus, dass der Cache bei jeder Bereitstellung zuverlässig erneuert wird. Davon zu unterscheiden ist das Zwischenspeichern fertiger Template-Ausgaben, das einzelne Shopbestandteile und entsprechend programmierte Module nutzen. Der Smarty-Cache erzeugt nicht automatisch für jede vollständige Seite eine statische Kopie, die bedenkenlos an jeden Kunden ausgeliefert werden darf. Maßgeblich ist, wie die Module den jeweiligen Kontext berücksichtigen. Nach Änderungen kontrolliere ich Preise, Verfügbarkeit, Sprache und die Ansicht angemeldeter Kunden. Die grundlegenden Optionen erläutert die Dokumentation zu den Leistungseinstellungen.

Dateisystem, Datenbank und automatisches Leeren des Caches

Bei Versionen mit wählbarem Smarty-Speicher muss zwischen Dateisystem und MySQL unterschieden werden. Für einen üblichen Shop auf einem einzelnen Server beginne ich meist mit einem dateibasierten Cache auf einem schnellen lokalen Laufwerk. Die Verlagerung nach MySQL kann einer bereits ausgelasteten Datenbank zusätzliche Arbeit aufbürden, statt den Shop zu beschleunigen. Langsamer Netzwerkspeicher oder sehr viele kleine Dateien müssen dagegen gesondert untersucht werden. Ebenso wichtig sind die Regeln, nach denen der Cache bei Produkt- oder Theme-Änderungen geleert wird. Geschieht das zu häufig, sinkt sein Nutzen; werden veraltete Einträge nicht rechtzeitig ungültig, bleibt alter Inhalt sichtbar. Bei mehreren Anwendungsservern braucht es ein durchdachtes Konzept für die Synchronisierung. Lokale Dateien eines Servers stehen den anderen nicht automatisch zur Verfügung. Hinweise zum Dateisystem-Cache und zur Untersuchung von Modulen enthält der Entwicklerleitfaden zur Optimierung.

CCC: intelligenter Cache für CSS

CCC steht für Combine, Compress and Cache. Bei Stylesheets werden CSS-Dateien aufbereitet und die Ergebnisse gespeichert, damit dieser Vorgang nicht für jeden Aufruf wiederholt werden muss. Je nach Version und Theme kann das die übertragene Datenmenge und die Anzahl der Dateien verringern. Das Ergebnis prüfe ich stets im tatsächlichen Shop, besonders beim mobilen Menü, der Produktgalerie, den Filtern und im Bestellvorgang. Fehlerhaftes CSS oder ungültige Bildpfade können durch die Verarbeitung erst sichtbar werden. Wenig gewonnen ist außerdem mit einer riesigen gemeinsamen Datei, die Regeln für zahlreiche ungenutzte Funktionen enthält. Unter HTTP/2 und HTTP/3 reicht eine geringere Anzahl von Anfragen allein nicht mehr als Begründung, alles zusammenzufassen. Ich achte auf Dateigröße, tatsächliche Nutzung und die Auswirkungen auf den ersten Seitenaufbau.

CCC: JavaScript-Cache und Webserver-Einstellungen

JavaScript erfordert mehr Vorsicht. Skripte eines Moduls können von einer bestimmten Ladereihenfolge oder einer Bibliothek des Themes abhängen. Nach dem Aktivieren des intelligenten Caches teste ich deshalb Variantenwechsel, das Hinzufügen zum Warenkorb, die Anmeldung, Versandarten und Zahlungsmethoden. Manche Fehler treten erst auf einem bestimmten Gerät oder nach dem Einloggen auf. Bietet die installierte Version weitere Optimierungen für HTML oder das Laden von Skripten, aktiviere ich auch diese einzeln und prüfe ihre Wirkung. Die Dateiverarbeitung durch CCC ist zudem etwas anderes als die Übertragungskomprimierung mit gzip oder Brotli; dafür sind Webserver oder CDN zuständig. Die Apache-Optimierung gilt für eine entsprechende Apache-Umgebung und ersetzt keine Nginx-Konfiguration. Die technische Umsetzung lässt sich im Quellcode der Klasse Media nachvollziehen.

Nativer Daten-Cache: Memcache, Memcached, APC und Xcache

Im gesonderten Bereich für das Cache-System wird das Backend des Daten-Caches ausgewählt. Diese Einstellung ist vom Smarty-Cache unabhängig und verlagert nicht automatisch sämtliche Datenbankarbeit in den Arbeitsspeicher. Der Nutzen hängt davon ab, welche Teile des Kerns und der Module diese Ebene verwenden, wie oft dieselben Daten benötigt werden und welcher Kommunikationsaufwand entsteht. Für diese Ebene wählt man ein Backend aus; die vier Optionen werden nicht gleichzeitig aktiviert. Vor einer dauerhaften Umstellung vergleiche ich die Antwortzeiten mit und ohne Cache sowie bei leerem und bereits gefülltem Cache. Die Dokumentation zur Cache-Architektur verdeutlicht, weshalb die verschiedenen Mechanismen innerhalb von PrestaShop getrennt betrachtet werden müssen.

Memcached über PHP::Memcache

Diese Option verwendet den Serverdienst Memcached und spricht ihn über die PHP-Erweiterung Memcache an, also ohne abschließendes „d“. Es genügt nicht, nur den Dienst zu installieren. Die Erweiterung muss auch in der PHP-Umgebung geladen sein, die den Shop ausführt. Eine Prüfung des Kommandozeilen-PHP sagt nicht zwangsläufig etwas über die verwendete PHP-FPM-Umgebung aus. In PrestaShop werden je nach Oberfläche Serveradresse, Port und gegebenenfalls Gewichtung hinterlegt. Der Dienst kann lokal laufen oder mehreren Anwendungsservern als gemeinsamer Speicher dienen. Ein entfernter Cache verursacht allerdings Netzwerkzugriffe; eine Beschleunigung muss daher gemessen werden. Zur Einrichtung gehören ausreichend Arbeitsspeicher und eine vom öffentlichen Netz abgeschottete Erreichbarkeit. Bei Speichermangel können Einträge verdrängt werden. Memcached ist somit kein dauerhafter Speicher für Bestellungen. Die Voraussetzungen erläutert das Handbuch zur Memcache-Erweiterung; die Anbindung zeigt der native PrestaShop-Adapter.

Memcached über PHP::Memcached

Die zweite Variante greift auf denselben Diensttyp zu, nutzt jedoch eine andere PHP-Erweiterung: Memcached, diesmal mit abschließendem „d“. Sie basiert auf libmemcached und hat eine eigene Schnittstelle sowie eigene Installationsabhängigkeiten. Memcache und Memcached sind nicht austauschbar. Die Auswahl im Backoffice muss zur tatsächlich installierten Erweiterung passen. Bei einer neuen Serverumgebung würde ich diese Variante anhand der Hosting-Unterstützung, der PHP-Version und konkreter Tests bewerten. Automatisch schneller ist sie nicht. Ich prüfe die Trefferquote, den Speicherverbrauch, verdrängte Einträge und Verzögerungen beim Verbindungsaufbau. Außerdem müssen die Schlüssel verschiedener Installationen ausreichend getrennt sein, damit das Leeren eines Caches keinen anderen Shop beeinträchtigt. Mehrere Anwendungsserver können von einem gemeinsamen Dienst profitieren; alle übrigen Cache-Ebenen werden dadurch aber nicht automatisch synchronisiert. Details liefern das Memcached-Handbuch und der Adapter CacheMemcached.

APC und APCu: lokaler Daten-Cache

Die Bezeichnung APC hat einen historischen Hintergrund. Das ursprüngliche APC vereinte das Zwischenspeichern von Anwendungsdaten mit einem Cache für kompilierten PHP-Code. In heutigen Umgebungen ist für die Anwendungsdaten APCu relevant, während PHP-Code üblicherweise von OPcache abgedeckt wird. Deshalb führt der Link bei der APC-Option häufig zur APCu-Installation. Es handelt sich nicht nur um eine Namensfrage: Die Unterstützung muss für die konkrete PrestaShop-Version geprüft werden. Der CacheApc-Adapter der Reihe 8.2 unterstützt beispielsweise ausdrücklich APC und APCu. Lokaler gemeinsamer Speicher benötigt keine Verbindung zu einem entfernten Cache-Server. Welche Prozesse ihn gemeinsam nutzen, hängt jedoch von der PHP-Konfiguration ab. Ein gemeinsamer Netzwerk-Cache für mehrere Maschinen entsteht daraus nicht. Ich kontrolliere die Speicherzuteilung und das Verhalten nach einem PHP-Neustart. Eine wichtige Fehlerquelle: Das Leeren von APCu über die Kommandozeile betrifft nicht unbedingt den Speicher der Webprozesse.

Xcache: eine Option mit historischem Hintergrund

Xcache taucht zu Recht in älteren Installationen und Backend-Listen von PrestaShop auf. Die Erweiterung konnte PHP-Code und Anwendungsvariablen zwischenspeichern; der PrestaShop-Adapter nutzte den Datenspeicher. Für einen neuen Shop mit aktuellem PHP würde ich sie allerdings nicht allein deshalb wählen, weil der Eintrag noch vorhanden ist. Die Versionshistorie des Projekts bezieht sich vor allem auf die PHP-5-Generation, also auf eine grundlegend andere Serverumgebung. Zunächst wären die Kompatibilität mit dem eingesetzten PHP und die weitere Pflege nachzuweisen. Bei einem übernommenen Altshop prüfe ich, ob Xcache tatsächlich läuft und welche Abhängigkeiten bestehen. Daraus lässt sich ein Plan zur Modernisierung der gesamten Umgebung entwickeln. Wegen einer Cache-Technik auf veraltetes PHP zurückzugehen, wäre keine sinnvolle Lösung. Das Xcache-Repository ist eine historische Referenz und keine allgemeine Installationsanleitung für einen heutigen PrestaShop.

OPcache und die internen Anwendungscaches

PHP OPcache speichert vorkompilierten PHP-Code, damit der Server ihn nicht für jede Anfrage neu übersetzen muss. Das ist ein wichtiger Bestandteil der Hosting-Umgebung, aber kein weiteres Daten-Backend aus der oben genannten Liste. Ich prüfe, ob OPcache für Webanfragen aktiv ist, genug Speicher erhält und ausreichend viele Dateien aufnehmen kann. Wird die automatische Änderungserkennung abgeschaltet, muss die Bereitstellung neuer Versionen den Code-Cache ausdrücklich erneuern. Daneben besitzt PrestaShop interne Anwendungscaches, in den modernen Komponenten auch Mechanismen von Symfony. Nach Änderungen an Diensten oder der Bereitstellung eines Moduls kann deren Leeren erforderlich sein. Die Schaltfläche „Cache leeren“ bedeutet jedoch nicht, dass damit auch alle Kopien im Browser, in Modulen und bei Cloudflare verschwinden. Bei veralteten Inhalten suche ich gezielt nach der verantwortlichen Ebene.

Browser-Cache und HTTP-Header

Ein korrekt eingerichteter Server erlaubt dem Browser, Bilder, Stylesheets, Skripte und Schriftarten erneut zu verwenden. Bei einem späteren Besuch müssen sie dann nicht vollständig heruntergeladen werden. Maßgeblich sind vor allem Cache-Control und gegebenenfalls Expires; ETag und Last-Modified helfen zu prüfen, ob sich eine Ressource geändert hat. Lange Gültigkeitszeiten passen zu statischen Dateien, deren URL sich bei einer Aktualisierung ändert. Fehlt diese Versionierung, können Kunden trotz geleertem Shop-Cache weiterhin alte CSS-Dateien verwenden. Personalisiertes HTML braucht andere Regeln als ein Produktfoto. Beispiele für statische Ressourcen enthält die Dokumentation zur Apache-Konfiguration. Für Nginx müssen entsprechende Serverregeln eingerichtet werden. Ich kontrolliere die tatsächlich beim Browser ankommenden Header, da zwischengeschaltete Proxys das Ergebnis beeinflussen können.

Cache-Module von addons.prestashop.com

Auf dem offiziellen Marktplatz finden sich beispielsweise Page Cache Pro und Page Cache Ultimate. Das sind mögliche Vergleichskandidaten, keine pauschalen Empfehlungen für jeden Shop. Module dieser Kategorie können vollständige Seiten oder größere Teile der fertigen Ausgabe speichern. Bei einem Cache-Treffer entfällt dadurch ein Teil der wiederholten PHP-Arbeit. Besonders interessant ist das häufig für öffentliche Katalogseiten. Vor einem Kauf prüfe ich aber die Unterstützung der konkreten PrestaShop-Version, PHP-Version, des Themes und der unverzichtbaren Module. Dazu kommen der Umgang mit dynamischen Bereichen, das automatische Verwerfen nach Produktänderungen und das Vorwärmen des Caches. Ein beworbener Leistungswert sagt wenig darüber aus, ob die eigenen Preisregeln und der Bestellablauf korrekt funktionieren.

Entscheidend ist ein passender Cache-Schlüssel. Dieselbe URL kann je nach Kontext eine andere Sprache, Währung, Steuerberechnung, Kundengruppenpreise oder shopspezifische Angebote liefern. Warenkorb, Kundenkonto, Bestellvorgang, personalisierte Antworten und Rückleitungen von Zahlungsanbietern benötigen geeignete Ausnahmen oder eine sichere dynamische Umsetzung. Bei nicht angemeldeten Besuchern prüfe ich außerdem den Übergang vom bloßen Stöbern zum Einkaufen. Ein geeignetes Modul muss diese Tests und ein gezieltes Verwerfen betroffener Seiten ermöglichen. Ich teste auf einer Shopkopie und messe neben der Geschwindigkeit auch die korrekte Funktion. Zwei vollständige Seiten-Caches gleichzeitig erschweren meist vor allem die Suche nach der Quelle veralteter Inhalte.

Medienserver: statische Inhalte auslagern

Mit der nativen Einstellung Medienserver können unterstützte statische Dateien über eine andere Domain oder Subdomain ausgeliefert werden, etwa über ein Content Delivery Network, kurz CDN. Das Eintragen einer Adresse kopiert allerdings keine Dateien und baut noch keine verteilte Infrastruktur auf. Das Ziel muss die benötigten Bilder, CSS-Dateien und Skripte bereits bereitstellen. Danach prüfe ich HTTPS-Zertifikat, Pfade und Erreichbarkeit sowie bei Schriftarten gegebenenfalls CORS-Regeln. Eine Subdomain auf demselben Server kann organisatorisch nützlich sein, schafft aber weder zusätzliche Rechenleistung noch geografisch nähere Dateikopien. Auch ältere Empfehlungen, Dateien für mehr parallele Downloads auf mehrere Domains aufzuteilen, müssen unter HTTP/2 und HTTP/3 neu bewertet werden. Zusätzliche Domains können weitere Verbindungen verursachen. Ich setze Medienserver daher mit einem konkreten Ziel ein, meist im Rahmen eines echten CDN, und messe den tatsächlichen Nutzen.

Cloudflare: zuerst statische Dateien, danach gegebenenfalls HTML

Cloudflare kann als Reverse Proxy und CDN vor dem Shop arbeiten. Bei korrekter Konfiguration liefert das verteilte Netzwerk geeignete statische Dateien aus und reduziert wiederholte Übertragungen vom Ursprungsserver. Normales HTML und JSON werden standardmäßig jedoch nicht gecacht. Eine DNS-Umstellung allein sorgt also nicht dafür, dass PHP keine Produktseiten mehr erzeugen muss. Für eine einfache Einrichtung ist auch nicht zwingend eine Änderung der Medienserver nötig: Cloudflare kann direkt vor der Hauptdomain arbeiten. Ich kontrolliere tatsächliche Cache-Treffer anhand der Antwort-Header und der Auswertungen des Dienstes. Dass die Funktion aktiviert ist, genügt als Nachweis nicht. Die Regeln und die Berücksichtigung der Ursprungs-Header beschreibt die Dokumentation zum standardmäßigen Cache-Verhalten von Cloudflare.

HTML am Netzwerkrand zu speichern, erfordert dagegen Regeln für den konkreten Shop. Ein pauschales „Cache Everything“ kann bei unvollständigen Ausnahmen kundenabhängige Inhalte speichern. Nur eine Warenkorb-Adresse auszuschließen, reicht nicht aus. Berücksichtigt werden müssen unter anderem Routen, Parameter, Cookies, Anmeldung und unterschiedliche Preiskontexte. Verfügbare Bedingungen und Cache-Schlüssel hängen zudem vom Dienst und Tarif ab. Das Umgehen des Caches anhand eines Cookies ist ein Werkzeug, aber keine fertige PrestaShop-Konfiguration. Nach Produktänderungen müssen auch die passenden Kopien gezielt ungültig gemacht werden. Bei der Kombination mit einem Cache-Modul lege ich vorher fest, welche Komponente welche Ebene zu welchem Zeitpunkt leert.

Für größere Installationen: Reverse Proxy, Varnish und Redis

Auf einem selbst verwalteten Server kommen auch der FastCGI-Cache von Nginx oder ein Reverse Proxy wie Varnish infrage. Sie speichern HTTP-Antworten und benötigen ebenfalls passende Ausnahmen, eine sichere Trennung der Kundenkontexte und abgestimmte Regeln zur Invalidierung. Redis lässt sich über ein geeignetes Modul oder eine individuelle Integration für bestimmte Caches oder Sessions einsetzen. Es ersetzt aber nicht automatisch eines der vier beschriebenen nativen Backends. Für solche Architekturen brauche ich klar zugewiesene Aufgaben und eine verlässliche Serveradministration. Technologien nur deshalb zu kombinieren, weil sie auf Optimierungslisten stehen, halte ich für wenig sinnvoll. Auch nach einem Dienstneustart, Katalogimport oder vollständigen Leeren des Caches muss sich der Shop vorhersehbar verhalten.

So würde ich bei einem konkreten Shop vorgehen

Am Anfang stehen Messungen des bestehenden Zustands: Antwortzeit, Datenbankabfragen, Aufwand der Module und übertragene Datenmengen. Danach würde ich offensichtliche Engpässe beheben und Produktionsmodus, OPcache und Smarty prüfen. Anschließend folgen CSS, JavaScript, Bilder und Header für statische Dateien. Erst anhand dieser Ergebnisse entscheide ich über ein Daten-Backend, ein Cache-Modul oder ein CDN. Eine gespeicherte Startseite beschleunigt schließlich keine langsame Datenbankoperation beim Absenden einer Bestellung.

Jede Änderung vergleiche ich beim ersten und wiederholten Aufruf, auf Mobilgeräten und für verschiedene Kundensituationen. Neben TTFB, also der Zeit bis zum ersten Byte der Antwort, und dem Aufbau des Hauptinhalts prüfe ich aktuelle Preise, Bestandsänderungen, Gutscheine, Versandarten und den gesamten Bestellablauf. Auch die Geschwindigkeit unmittelbar nach dem Leeren des Caches ist aufschlussreich: Dann zeigt sich die tatsächliche Belastung durch den Shop. Ein guter Cache macht den Einkauf schneller und hält die angezeigten Daten korrekt. Bei meiner PrestaShop-Performance-Optimierung untersuche ich deshalb zuerst die konkreten Grenzen Ihres Shops und leite daraus die passenden Maßnahmen ab.