PrestaShop Smarty-Cache vs. OPcache vs. Browser-Cache

Die drei Caching-Schichten in PrestaShop verstehen

PrestaShop verwendet mehrere Caching-Mechanismen, um Seiten schnell auszuliefern. Jede Schicht arbeitet auf einer anderen Ebene des Stacks, und das Verständnis, was jede tut, wann sie greift und wann Sie sie leeren müssen, ist sowohl für die Leistungsoptimierung als auch für die Fehlerbehebung unerlässlich. Die drei wichtigsten Caching-Schichten sind der Smarty-Template-Cache, PHP OPcache und der Browser-Cache. Sie arbeiten zusammen, lösen aber unterschiedliche Probleme und erfordern unterschiedliche Verwaltungsansätze.

Wenn ein Kunde Ihren Shop besucht, durchläuft die Anfrage alle drei Schichten in umgekehrter Reihenfolge. Der Browser prüft zuerst seinen lokalen Cache. Wenn er eine aktuelle Kopie der Ressource hat, kontaktiert er Ihren Server überhaupt nicht. Wenn der Browser doch eine Anfrage sendet, verarbeitet PHP sie. OPcache stellt sicher, dass PHP-Dateien einmal kompiliert und aus dem Speicher wiederverwendet werden, anstatt bei jeder Anfrage neu geparst zu werden. Schließlich stellt der Smarty-Cache sicher, dass das Template-Rendering, das das Parsen der Template-Syntax und die Ausführung der Template-Logik umfasst, nur bei Bedarf stattfindet und nicht bei jedem Seitenaufruf.

Probleme entstehen, wenn diese Schichten veraltete Inhalte liefern. Sie ändern eine Template-Datei, aber die Seite sieht gleich aus. Sie aktualisieren eine PHP-Datei, aber das alte Verhalten bleibt bestehen. Sie ändern CSS, aber der Browser zeigt weiterhin die alten Stile an. Jedes dieser Symptome deutet auf eine andere Caching-Schicht hin, und das Leeren der falschen verschwendet Zeit, ohne das Problem zu lösen.

Smarty-Template-Cache: Funktionsweise

Smarty ist die Template-Engine, die PrestaShop zum Rendern von HTML verwendet. Jede .tpl-Datei in Ihrem Theme und Ihren Modulen durchläuft Smarty, bevor sie zu HTML wird, das an den Browser gesendet wird. Smarty-Caching arbeitet in zwei unterschiedlichen Phasen: Kompilierung und Ausgabe-Caching.

Template-Kompilierung

Wenn Smarty zum ersten Mal auf eine .tpl-Datei stößt, kompiliert es sie in eine PHP-Datei. Diese kompilierte Datei wird im Verzeichnis /var/cache/prod/smarty/compile/ gespeichert (oder /var/cache/dev/smarty/compile/ im Debug-Modus). Die kompilierte Datei enthält die Template-Logik, übersetzt in reines PHP, das viel schneller ausgeführt wird als das Parsen der Smarty-Syntax bei jeder Anfrage.

Smarty prüft, ob die kompilierte Version aktuell ist, indem es Zeitstempel vergleicht. Wenn die Quell-.tpl-Datei neuer ist als die kompilierte Version, kompiliert Smarty sie automatisch neu. Dies wird durch die Einstellung compile_check gesteuert. In der Produktion können Sie die Kompilierungsprüfung für maximale Leistung deaktivieren, was bedeutet, dass Smarty davon ausgeht, dass kompilierte Templates immer aktuell sind und die Quelldateien nie prüft.

Template-Ausgabe-Caching

Über die Kompilierung hinaus kann Smarty auch die gerenderte Ausgabe von Templates cachen. Wenn Ausgabe-Caching aktiviert ist, speichert Smarty die endgültige HTML-Ausgabe eines Templates und liefert sie bei nachfolgenden Anfragen direkt aus, ohne die Template-Logik auszuführen. Dies ist aggressiver als Kompilierungs-Caching, da es nicht nur den Parsing-Schritt, sondern auch die Datenverarbeitung und Logikausführung innerhalb des Templates überspringt.

Ausgabe-Caching in PrestaShop wird pro Modul-Hook verwaltet. Jedes Modul kann deklarieren, ob seine Hook-Ausgabe cachebar ist, und PrestaShop weist Cache-Schlüssel basierend auf Faktoren wie der aktuellen Sprache, dem Shop, der Währung und der Kundengruppe zu. Das bedeutet, dass ein französischer Kunde und ein englischer Kunde separate zwischengespeicherte Versionen erhalten.

Smarty-Cache-Einstellungen in PrestaShop

Sie konfigurieren Smarty-Caching im Back-Office unter Erweiterte Einstellungen > Leistung. Die relevanten Einstellungen sind:

Template-Kompilierung: Dies steuert, wie Smarty die Template-Kompilierung handhabt. Die Optionen sind typischerweise "Nie neu kompilieren" (am schnellsten, verwendet immer die kompilierte Version), "Neu kompilieren, wenn geändert" (prüft Dateizeitstempel, gute Balance) und "Kompilierung erzwingen" (kompiliert bei jeder Anfrage neu, nur für die Entwicklung). In der Produktion verwenden Sie "Neu kompilieren, wenn geändert", es sei denn, Sie sind sicher, dass sich Ihre Templates zwischen Deployments nie ändern; in diesem Fall bietet "Nie neu kompilieren" einen kleinen zusätzlichen Leistungsgewinn.

Cache: Dies schaltet das Smarty-Ausgabe-Caching um. Wenn aktiviert, speichert Smarty die gerenderte HTML-Ausgabe und liefert sie aus, ohne die Template-Logik erneut auszuführen. Dies bietet erhebliche Leistungsvorteile für Shops mit komplexen Templates oder vielen Modul-Hooks. Der Cache-Typ kann auf Dateisystem (Standard) oder einen benutzerdefinierten Caching-Handler gesetzt werden.

Multi-Front-Optimierungen: Dies aktiviert Caching über mehrere Front-End-Server. Nur relevant für Cluster-Setups.

Cache leeren: Die Optionen umfassen "Nie Cache-Dateien löschen", "Cache bei jeder Änderung leeren" und spezifische Löschstrategien. Für die meisten Shops ist das Leeren bei Änderung die richtige Wahl, da Updates sofort sichtbar werden und trotzdem vom Caching zwischen Änderungen profitiert wird.

Smarty-Cache leeren

Um den Smarty-Cache manuell zu leeren, können Sie die Schaltfläche "Cache leeren" auf der Leistungsseite des Back-Office verwenden. Dies löscht kompilierte Templates und zwischengespeicherte Ausgaben aus dem Verzeichnis /var/cache/. Sie können ihn auch leeren, indem Sie Dateien direkt vom Server löschen:

Kompilierte Templates löschen: Inhalt von var/cache/prod/smarty/compile/ entfernen

Zwischengespeicherte Ausgabe löschen: Inhalt von var/cache/prod/smarty/cache/ entfernen

Sie müssen den Smarty-Cache leeren, wenn Sie .tpl-Template-Dateien ändern (falls die Kompilierungsprüfung deaktiviert ist), wenn Sie ein Modul installieren oder aktualisieren, das Templates ändert, wenn Sie Themes wechseln oder wenn Sie Template-bezogene Konfigurationen ändern. Wenn Sie eine .tpl-Datei ändern und die Änderung nicht im Frontend erscheint, ist der Smarty-Compile-Cache fast immer die Ursache.

PHP OPcache: Funktionsweise

PHP OPcache ist ein in PHP integrierter Bytecode-Cache. Wenn PHP ein Skript ausführt, durchläuft es drei Phasen: Lexing (Zerlegung des Quellcodes in Token), Parsing (Aufbau eines abstrakten Syntaxbaums) und Kompilierung (Generierung von Bytecode, den die PHP-Engine ausführt). OPcache speichert den kompilierten Bytecode im gemeinsamen Speicher, sodass nachfolgende Anfragen für dasselbe Skript die Lexing-, Parsing- und Kompilierungsphasen vollständig überspringen.

Dies unterscheidet sich vom Smarty-Cache. Smarty cached die Template-Rendering-Ausgabe (HTML). OPcache cached die PHP-Kompilierungsausgabe (Bytecode). Sie arbeiten auf völlig verschiedenen Ebenen. Ein Smarty-Template, das von Smarty in eine PHP-Datei kompiliert wurde, profitiert dennoch von OPcache, da diese kompilierte PHP-Datei selbst als Bytecode von OPcache zwischengespeichert wird.

OPcache-Konfiguration für PrestaShop

OPcache wird in Ihrer php.ini-Datei konfiguriert. Die wichtigsten Einstellungen für PrestaShop sind:

opcache.enable=1 aktiviert OPcache. Dies sollte in der Produktion immer aktiviert sein. Der Leistungsunterschied ist dramatisch: Die PHP-Ausführung wird mit aktiviertem OPcache 2- bis 5-mal schneller.

opcache.memory_consumption=256 legt die Menge des gemeinsamen Speichers (in Megabyte) fest, der zum Speichern von kompiliertem Bytecode verfügbar ist. PrestaShop mit mehreren Modulen kann leicht 128 MB oder mehr verbrauchen. Wenn dieser Wert zu niedrig ist, verdrängt OPcache ältere Einträge, um Platz für neue zu schaffen, was den Zweck zunichte macht. Setzen Sie diesen Wert für Shops mit vielen Modulen auf 256 MB oder höher. Sie können die Nutzung mit opcache_get_status() prüfen, um den tatsächlichen Speicherverbrauch zu sehen.

opcache.max_accelerated_files=20000 legt die maximale Anzahl der PHP-Dateien fest, die gecacht werden können. PrestaShop-Kern plus Module können leicht 10.000 oder mehr PHP-Dateien umfassen. Der tatsächlich von OPcache verwendete Wert wird auf die nächste Primzahl aus einer vordefinierten Menge aufgerundet, sodass die Einstellung 20000 zu einem tatsächlichen Limit von 20479 führt. Prüfen Sie opcache_get_status(), um sicherzustellen, dass Sie dieses Limit nicht erreichen.

opcache.validate_timestamps=1 weist OPcache an, zu prüfen, ob sich Quelldateien geändert haben. Wenn aktiviert, prüft OPcache die Dateiänderungszeit in Intervallen, die durch revalidate_freq definiert sind. In der Produktion können Sie dies auf 0 (deaktiviert) für maximale Leistung setzen, müssen dann aber PHP-FPM neu starten oder opcache_reset() aufrufen, wann immer Sie neuen Code bereitstellen.

opcache.revalidate_freq=60 definiert, wie oft (in Sekunden) OPcache auf Dateiänderungen prüft, wenn validate_timestamps aktiviert ist. Ein Wert von 60 bedeutet, dass OPcache jede Datei höchstens einmal pro Minute prüft. Höhere Werte bedeuten bessere Leistung, aber längere Verzögerungen, bevor Codeänderungen wirksam werden. Für aktive Entwicklung setzen Sie diesen Wert auf 0 oder 2. Für die Produktion sind 60 ein guter Kompromiss.

opcache.interned_strings_buffer=16 reserviert Speicher für internierte Strings, die PHP verwendet, um identische Strings über verschiedene Skripte hinweg zu deduplizieren. PrestaShop profitiert davon, da viele Module dieselben Klassennamen, Funktionsnamen und Stringliterale teilen. Setzen Sie diesen Wert auf 16 MB oder höher.

opcache.save_comments=1 muss für PrestaShop aktiviert sein. PrestaShop und einige seiner Abhängigkeiten verwenden PHP-DocBlock-Annotationen, die zur Laufzeit gelesen werden. Wenn Sie dies deaktivieren, funktionieren bestimmte Features nicht mehr.

OPcache und die CLI- vs. Web-Trennung

Ein wichtiges Detail über OPcache ist, dass die CLI (Kommandozeile) und die Web-Umgebung (PHP-FPM oder mod_php) separate OPcache-Pools unterhalten. Das Leeren von OPcache über die Kommandozeile (z. B. das Ausführen eines PHP-Skripts, das opcache_reset() über CLI aufruft) löscht nicht den Web-OPcache. Um den Web-OPcache zu leeren, müssen Sie entweder den PHP-FPM-Dienst neu starten oder opcache_reset() über eine Web-Anfrage ausführen.

Diese Unterscheidung ist in Deployment-Workflows wichtig. Wenn Sie neuen Code bereitstellen und OPcache über einen CLI-Befehl leeren, liefert Ihre Website weiterhin den alten Bytecode, bis auch der Web-OPcache geleert wird. Viele Deployment-Tools bewältigen dies, indem sie einen speziellen URL-Endpunkt aufrufen, der opcache_reset() auslöst, oder indem sie PHP-FPM als Teil des Deployment-Prozesses neu starten.

Wann OPcache geleert werden muss

Sie müssen OPcache leeren, wann immer Sie PHP-Dateien auf Ihrem Server ändern, hochladen oder ersetzen. Dies umfasst die Bereitstellung einer neuen PrestaShop-Version, die Installation oder Aktualisierung von Modulen, die direkte Bearbeitung von PHP-Dateien auf dem Server und die Aktualisierung von Composer-Abhängigkeiten. Wenn Sie eine PHP-Datei ändern und das alte Verhalten trotz deutlicher Änderung der Datei auf der Festplatte bestehen bleibt, liefert OPcache den alten Bytecode. Der Neustart von PHP-FPM ist der zuverlässigste Weg, ihn zu leeren.

Browser-Cache: Funktionsweise

Browser-Caching ist die letzte Schicht und arbeitet vollständig auf der Client-Seite. Wenn ein Browser eine Ressource herunterlädt (CSS-Datei, JavaScript-Datei, Bild, Schriftart oder sogar eine HTML-Seite), kann er eine lokale Kopie speichern und sie für nachfolgende Anfragen wiederverwenden. Dies eliminiert Netzwerk-Roundtrips vollständig für gecachte Ressourcen, was die größtmögliche Leistungsverbesserung darstellt, da keine serverseitige Optimierung eine Netzwerklatenz von Null übertreffen kann.

Browser-Caching wird durch HTTP-Antwort-Header gesteuert, die Ihr Server zusammen mit jeder Ressource sendet. Die wichtigsten Header sind Cache-Control, Expires, ETag und Last-Modified.

Cache-Control-Header

Der Cache-Control-Header ist der primäre Mechanismus zur Steuerung des Browser-Cachings. Er unterstützt mehrere Direktiven:

max-age=31536000 teilt dem Browser mit, die Ressource bis zu 31.536.000 Sekunden (ein Jahr) zwischenzuspeichern. Während dieser Zeit verwendet der Browser seine lokale Kopie, ohne den Server überhaupt zu kontaktieren. Dies ist ideal für statische Ressourcen wie CSS, JavaScript und Bilder, die eine Versionskennung in ihrer URL enthalten (wie einen Hash oder Query-String).

no-cache bedeutet nicht "nicht cachen". Es bedeutet, dass der Browser die Ressource cachen darf, sie aber vor der Verwendung der gecachten Kopie beim Server validieren muss. Der Server antwortet entweder mit einem 304-Status (Not Modified), was bedeutet, dass die gecachte Version noch gültig ist, oder mit einem 200 mit dem neuen Inhalt.

no-store verhindert tatsächlich das Caching. Der Browser muss die Ressource jedes Mal frisch herunterladen. Verwenden Sie dies für sensible Inhalte, die niemals lokal gespeichert werden sollten.

public zeigt an, dass die Antwort von jedem Cache gespeichert werden kann, einschließlich CDNs und Proxy-Servern. Verwenden Sie dies für statische Ressourcen.

private zeigt an, dass die Antwort für einen einzelnen Benutzer spezifisch ist und nicht von gemeinsam genutzten Caches wie CDNs gespeichert werden sollte. Verwenden Sie dies für Seiten mit benutzerspezifischem Inhalt, wie die Kontoseite oder den Warenkorb eines Kunden.

ETag-Header

Ein ETag (Entity Tag) ist eine eindeutige Kennung für eine bestimmte Version einer Ressource. Der Server generiert sie (typischerweise ein Hash des Dateiinhalts) und sendet sie mit der Antwort. Wenn der Browser seine gecachte Kopie validieren muss, sendet er das ETag im If-None-Match-Header an den Server zurück. Der Server vergleicht die ETags und gibt entweder 304 (verwenden Sie Ihre gecachte Version) oder 200 (hier ist die neue Version) zurück.

ETags sind nützlich, wenn Sie Browser-Caching mit Validierung wünschen. Der Browser stellt weiterhin eine Anfrage an den Server, aber wenn sich der Inhalt nicht geändert hat, sendet der Server eine winzige 304-Antwort statt der vollständigen Ressource zurück. Dies spart Bandbreite und gewährleistet gleichzeitig Aktualität.

Last-Modified und If-Modified-Since

Diese Header funktionieren ähnlich wie ETags, verwenden aber Zeitstempel statt Content-Hashes. Der Server sendet den Last-Modified-Zeitstempel mit der Ressource, und der Browser sendet ihn als If-Modified-Since bei der Validierung zurück. Der Server prüft, ob die Datei seit diesem Zeitpunkt geändert wurde, und gibt entsprechend 304 oder 200 zurück.

ETags werden generell gegenüber Last-Modified bevorzugt, da sie auf Inhalt statt auf Zeit basieren, was Probleme mit Uhrsynchronisation vermeidet und präziser ist. Die meisten Server senden jedoch beides, und Browser verwenden das, was verfügbar ist.

Browser-Cache-Konfiguration für PrestaShop

PrestaShops statische Ressourcen (CSS, JavaScript, Bilder) sollten aggressiv von Browsern gecacht werden. Der Standardansatz ist, Ihren Webserver so zu konfigurieren, dass er statischen Dateiantworten entsprechende Cache-Control-Header hinzufügt.

Für Apache verwenden Sie die Module mod_expires und mod_headers in Ihrer .htaccess-Datei. PrestaShops Standard-.htaccess enthält einige Caching-Regeln, die Sie möglicherweise erweitern möchten. Eine typische Konfiguration setzt max-age=31536000 für Bilder, Schriftarten, CSS und JavaScript-Dateien, während HTML-Antworten no-cache erhalten, um frische Inhalte sicherzustellen.

Für Nginx fügen Sie expires-Direktiven in Ihren Location-Blöcken für statische Dateien hinzu. Zum Beispiel: location ~* \.(css|js|jpg|png|gif|ico|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } cached statische Ressourcen für ein Jahr und markiert sie als unveränderlich (weist den Browser an, sie nicht einmal zu validieren).

Cache-Busting in PrestaShop

Wenn Sie lange Cache-Laufzeiten für CSS- und JavaScript-Dateien setzen, wie bekommen Browser aktualisierte Versionen, wenn Sie Änderungen bereitstellen? Hier kommt Cache-Busting ins Spiel. PrestaShop handhabt dies unterschiedlich, je nachdem, ob CCC (Combine, Compress, Cache) aktiviert ist.

Mit aktiviertem CCC kombiniert PrestaShop CSS- und JavaScript-Dateien in Bundles und generiert Dateinamen, die einen Hash des Inhalts enthalten. Wenn sich der Inhalt ändert, ändert sich der Dateiname, und Browser laden die neue Datei herunter, weil sie diese URL noch nie gesehen haben. Dies ist der zuverlässigste Cache-Busting-Ansatz.

Ohne CCC liefert PrestaShop einzelne CSS- und JavaScript-Dateien unter ihren Original-URLs aus. Einige Themes und Module hängen einen Versions-Query-String (wie ?v=1.2.3) an diese URLs an, der sich bei der Modulaktualisierung ändert. Browser behandeln die URL mit einem anderen Query-String als andere Ressource und laden sie frisch herunter.

Bilder sind schwieriger, da sich ihre URLs typischerweise nicht ändern, es sei denn, das Bild selbst wird ersetzt. Wenn Sie ein Bild durch ein neues unter derselben URL ersetzen, zeigen Browser, die die alte Version gecacht haben, diese weiterhin an, bis der Cache abläuft. In diesem Fall müssen Sie entweder den Bilddateinamen ändern oder Browser-Caches leeren (was Sie für Ihre Besucher nicht tun können). Die praktische Lösung ist die Verwendung versionierter Bild-URLs oder das Warten auf das natürliche Ablaufen des Caches.

Wie die drei Schichten interagieren

Das Verständnis der Interaktion dieser drei Caching-Schichten ist entscheidend für eine effektive Fehlerbehebung. Hier ist der Lebenszyklus einer typischen Anfrage:

Ein Kunde besucht eine Produktseite. Der Browser prüft seinen Cache auf das HTML dieser Seite. Da HTML typischerweise mit no-cache ausgeliefert wird, sendet der Browser eine Anfrage an den Server (möglicherweise mit einem If-Modified-Since- oder If-None-Match-Header zur Validierung).

Der Webserver empfängt die Anfrage und leitet sie an PHP weiter. PHP-FPMs OPcache hat den Bytecode für PrestaShops index.php, den Dispatcher, die Controller und alle Moduldateien im gemeinsamen Speicher gecacht. PHP führt den Bytecode aus, ohne Quelldateien neu zu kompilieren.

PrestaShops Controller ruft Smarty auf, um das Template zu rendern. Smarty prüft seinen Cache auf eine kompilierte Version des Templates. Wenn Ausgabe-Caching aktiviert ist und eine gültige gecachte Ausgabe für diese Kombination aus Sprache, Kundengruppe und anderen Cache-Schlüsseln existiert, gibt Smarty das gecachte HTML direkt zurück. Wenn nicht, führt Smarty das kompilierte Template aus (das OPcache ebenfalls als Bytecode gecacht hat, da kompilierte Smarty-Templates PHP-Dateien sind), generiert das HTML, speichert es im Ausgabe-Cache und gibt es zurück.

PHP sendet die HTML-Antwort an den Browser zusammen mit HTTP-Headern, die das Browser-Caching steuern. Der Browser rendert das HTML und fordert alle CSS-, JavaScript- und Bilddateien an, die darin referenziert werden. Für jede dieser Ressourcen prüft der Browser seinen lokalen Cache. Wenn er eine aktuelle Kopie hat (basierend auf Cache-Control max-age), verwendet er die lokale Kopie, ohne den Server zu kontaktieren. Wenn die gecachte Kopie validiert werden muss, sendet er eine bedingte Anfrage mit ETag- oder If-Modified-Since-Headern.

Fehlerbehebung bei veraltetem Inhalt

Wenn Änderungen, die Sie vornehmen, nicht im Frontend erscheinen, müssen Sie identifizieren, welche Caching-Schicht verantwortlich ist. Hier ist ein systematischer Ansatz:

Schritt 1: Browser prüfen

Öffnen Sie die Seite in einem Inkognito- oder privaten Browserfenster oder führen Sie eine harte Aktualisierung durch (Strg+Umschalt+R bei den meisten Browsern). Wenn die Änderung im Inkognito-Modus erscheint, aber nicht in einem normalen Fenster, ist der Browser-Cache die Ursache. Leeren Sie den Browser-Cache oder warten Sie auf dessen Ablauf.

Prüfen Sie bei CSS- und JavaScript-Änderungen speziell den Netzwerk-Tab in den Browser-DevTools. Schauen Sie sich die Antwort-Header für die geänderte Datei an. Wenn die Antwort einen 304 (Not Modified) zeigt und der Inhalt alt ist, hat sich die serverseitige Datei möglicherweise nicht tatsächlich geändert (prüfen Sie OPcache). Wenn der Browser nicht einmal eine Anfrage für die Datei stellt (es zeigt "from disk cache" oder "from memory cache"), ist die Cache-Control max-age noch nicht abgelaufen.

Schritt 2: Smarty-Cache prüfen

Wenn die Änderung auch im Inkognito-Modus nicht erscheint, liegt das Problem serverseitig. Bei Template-Änderungen leeren Sie den Smarty-Cache über das Back-Office (Erweiterte Einstellungen > Leistung > Cache leeren) oder löschen den Inhalt von var/cache/prod/smarty/. Laden Sie die Seite neu und prüfen Sie, ob die Änderung erscheint.

Schritt 3: OPcache prüfen

Wenn das Leeren des Smarty-Caches nicht hilft und die Änderung eine PHP-Datei betrifft (kein Template), liefert OPcache wahrscheinlich alten Bytecode. Starten Sie PHP-FPM neu oder rufen Sie opcache_reset() über eine Web-Anfrage auf. Bei Shared Hosting, wo Sie PHP-FPM nicht neu starten können, bietet Ihr Hosting-Control-Panel möglicherweise eine Option zum Leeren von OPcache, oder Sie können eine kleine PHP-Datei erstellen, die opcache_reset() aufruft und über Ihren Browser darauf zugreifen.

Schritt 4: Andere Caches prüfen

PrestaShop hat zusätzliche Caching-Mechanismen über diese drei Schichten hinaus. Der Symfony-Cache (in PrestaShop 1.7 und 8.x) speichert kompilierte Symfony-Service-Container, Routendefinitionen und andere Framework-Daten. Leeren Sie ihn, indem Sie die Verzeichnisse var/cache/prod/ und var/cache/dev/ löschen. Wenn Sie einen Reverse Proxy wie Varnish oder ein CDN wie Cloudflare verwenden, fügen diese eine weitere Caching-Schicht hinzu, die separat geleert werden muss.

Optimale Konfiguration für die Produktion

Für einen Produktions-PrestaShop-Shop bringt die optimale Caching-Konfiguration Leistung und Wartbarkeit in Einklang:

Smarty: Setzen Sie die Template-Kompilierung auf "Neu kompilieren, wenn geändert". Aktivieren Sie Ausgabe-Caching. Setzen Sie das Cache-Leeren auf "Bei Änderung leeren". Dies bietet starke Caching-Leistung und stellt gleichzeitig sicher, dass Back-Office-Änderungen (wie das Bearbeiten von CMS-Seiten oder das Ändern der Modulkonfiguration) sofort wirksam werden.

OPcache: Aktivieren Sie mit mindestens 256 MB Speicher, 20000 max accelerated files, validate_timestamps aktiviert mit revalidate_freq von 60 Sekunden. Diese Konfiguration bedeutet, dass Codeänderungen bis zu 60 Sekunden brauchen, um wirksam zu werden, was für die Produktion akzeptabel ist. Wenn Sie selten Codeänderungen bereitstellen und maximale Leistung wünschen, deaktivieren Sie validate_timestamps und starten Sie PHP-FPM nach jeder Bereitstellung neu.

Browser-Cache: Setzen Sie Cache-Control mit langen max-age-Werten (mindestens einen Monat, idealerweise ein Jahr) für statische Ressourcen (CSS, JavaScript, Bilder, Schriftarten). Verwenden Sie no-cache für HTML-Antworten, damit Seiten immer validiert werden. Aktivieren Sie CCC in PrestaShop, um Content-gehashte Dateinamen für kombinierte CSS- und JavaScript-Dateien zu erhalten, was automatisches Cache-Busting bei Ressourcenänderungen ermöglicht.

Mit dieser Konfiguration profitiert Ihr Shop von allen drei Caching-Schichten, die zusammenarbeiten. Statische Ressourcen werden aus dem Browser-Cache ohne Serverkontakt ausgeliefert. PHP-Dateien werden aus gecachtem Bytecode ohne Neukompilierung ausgeführt. Und das Template-Rendering wird gecacht, sodass Smarty-Logik nur bei Inhaltsänderungen ausgeführt wird. Das Ergebnis ist ein Shop, der für wiederkehrende Besucher schnell lädt und hohen Traffic auf der Serverseite effizient verarbeitet.

Wann welche Cache-Schicht geleert werden muss

Um sowohl veraltete Inhalte als auch unnötiges Cache-Leeren zu vermeiden, folgen Sie diesen Richtlinien:

Smarty-Cache leeren, wenn Sie .tpl-Dateien bearbeiten, Modulpositionen oder Hooks ändern, Module installieren oder aktualisieren, die Templates ändern, oder Theme-bezogene Einstellungen ändern. Sie müssen den Smarty-Cache nicht leeren, wenn Sie PHP-Dateien ändern oder CSS- oder JavaScript-Dateien aktualisieren.

OPcache leeren, wenn Sie PHP-Dateien bearbeiten, Module installieren oder aktualisieren, den PrestaShop-Kern aktualisieren oder Composer zur Aktualisierung von Abhängigkeiten verwenden. Sie müssen OPcache nicht für Template- oder CSS-Änderungen leeren.

Browser-Cache leeren, wenn Sie CSS-, JavaScript- oder Bildänderungen sofort während der Entwicklung sehen müssen. Für die Produktion verlassen Sie sich auf Cache-Busting (versionierte URLs, CCC-Hash-Dateinamen) statt Benutzer zu bitten, ihre Caches zu leeren. Sie können die Browser-Caches Ihrer Besucher nicht kontrollieren, daher muss Ihr Bereitstellungsprozess dies durch die Verwendung ordnungsgemäßer Cache-Busting-Techniken berücksichtigen.

Eine umfassende Cache-Leerungs-Sequenz nach einem großen Deployment wäre: Smarty-Compile- und Cache-Verzeichnisse leeren, PHP-FPM neu starten, um OPcache zu leeren, Ihren CDN- oder Reverse-Proxy-Cache falls zutreffend bereinigen, und in einem Inkognito-Browserfenster verifizieren. Bei kleineren Änderungen (wie dem Bearbeiten eines einzelnen Templates) ist das Leeren nur der relevanten Schicht ausreichend und schneller.