PrestaShop-Full-Page-Cache, Redis und CDN-Caching

Unser Vorgehen

Wir würden den Anfrageweg im Produktivbetrieb messen, bevor wir einen weiteren Cache auswählen. Behalten Sie einen funktionierenden Cache bei, wenn er korrekte Ergebnisse gewährleistet und die gemessene Last reduziert. Nutzen Sie Full-Page-Caching für geeignete wiederholte öffentliche Aufrufe und beheben Sie parallel aufwendige ungecachte Verarbeitung, insbesondere bei Warenkorb und Kasse. Redis kommt infrage, wenn ein implementierter Adapter die Daten wiederverwenden kann, die die Verzögerung verursachen.

Der passende Weg hängt von Ihren bestehenden PrestaShop- und PHP-Versionen, Modulen, Integrationen, Theme, Katalogdaten, Kundengruppen, Absatzmärkten und Zugriffszahlen ab. Berücksichtigen Sie, ob Ihr Team jeden zusätzlichen Dienst überwachen, leeren und wiederherstellen kann. Ein ERP-Bestandsimport, länderabhängige Preise oder eine personalisierte Kopfzeile können andere Sicherheitsregeln erfordern, selbst wenn zwei Shops dasselbe Cache-Modul nutzen.

Nehmen Sie die Änderung auf einer privaten Staging-Kopie mit repräsentativen Daten und denselben relevanten Modulen, Integrationen und demselben Theme vor. Trennen Sie deren Cache-Namensraum und Session-Speicher vom Produktivbetrieb und verhindern Sie, dass Testbestellungen, E-Mails und Exporte Produktivsysteme erreichen. Ändern Sie jeweils nur eine Ebene, proben Sie Seitenaufrufe, Aktualisierungen und die Wiederherstellung nach Ausfällen und planen Sie anschließend die Produktivumstellung. Halten Sie die bisherige Konfiguration bereit und benennen Sie eine Person, die Bestellungen und Datenaktualität prüft.

Wenn Sie den Engpass vor der Cache-Auswahl beurteilen lassen möchten, liefert das PrestaShop Speed & Core Web Vitals Audit einen auf Messungen beruhenden, priorisierten Maßnahmenplan; die Umsetzung wird separat abgegrenzt.

Welcher Weg passt zu Ihren Befunden?

Bestimmen Sie die Cache-Ebene, die Sie ändern

Ein Cache hilft nur, wenn die Anwendung daraus liest. Die Installation von Redis verlagert nicht automatisch jeden PrestaShop-Cache in den Arbeitsspeicher.

Smarty verwendet kompilierte Templates normalerweise wieder. Es kompiliert nicht jedes Template bei jeder Anfrage. PrestaShop startet Smarty mit deaktiviertem globalem Ausgabecaching und steuert das Caching gezielt. Verwenden Sie die unterstützten Backoffice-Einstellungen, statt das globale Ausgabecaching wahllos zu ändern.

Die Leistungsformulare von PrestaShop 1.7.8 und 9 führen je nach installierten Erweiterungen Memcache, Memcached, APC/APCu und XCache als Backends auf. Redis oder ein Dateisystem-Backend bieten sie in dieser Auswahl nicht an. Das ältere CacheFs ist eine separate Implementierung. Redis benötigt einen Adapter oder ein Modul, das die gewünschte Ebene implementiert.

Cache::store() verwendet ein anfragelokales Array, während Configuration statische Caches besitzt. Geeignete Datenbankergebnisse können das persistente Cache-Backend nutzen. Eine Änderung dieses Backends leitet nicht jede Kategorie-, Hook-, Konfigurations- oder Templateabfrage um.

Wählen Sie sichere Regeln für den Full-Page-Cache

Full-Page-Caching speichert eine geeignete gerenderte Antwort für spätere Besucher. Bei einem Cache-Miss findet weiterhin die normale Darstellung statt. Ein PHP-Seitencache kann spätere Controller- und Templatearbeit reduzieren, während der Bootstrap-Aufwand bestehen bleibt. Ein Proxy- oder CDN-Treffer kann den Ursprungsserver vollständig umgehen.

Beginnen Sie mit öffentlichen Seiten für anonyme Besucher. Umgehen Sie den Cache bei Warenkorb, Kasse, Authentifizierung, Kontoseiten, Backoffice-Routen, privaten Modulendpunkten, Webservices, Callbacks und zustandsändernden Anfragen. Berücksichtigen Sie auch AJAX, Abfrageparameter, Vorschaulinks, Session-Cookies und Antworten, die Cookies setzen.

Ein Cache-Schlüssel muss jeden Kontext unterscheiden, der die öffentliche Antwort verändert. Je nach Shop gehören dazu Hostname, Shop, Sprache, Währung, Land, Steuerkontext, geräteabhängige Darstellung und unterstützte Abfrageparameter. Kundengruppenpreise und personalisierte Aktionen erfordern besondere Sorgfalt.

Liefern Sie private Inhalte eines Kunden keinem anderen aus. Lässt sich ein Kontext nicht sicher in einem Schlüssel abbilden, umgehen Sie den Cache dafür. Entfernen Sie Cookies nicht nur, um einen Treffer zu erzwingen. Testen Sie sowohl die Cache-Abfrage als auch die Entscheidung, eine neu gerenderte Antwort zu speichern.

Dynamische Fragmente, AJAX-Hydration, Edge Side Includes und Cache-Ausnahmen für personalisierte Anfragen sind unterschiedliche Ansätze. Hydration und Flackern sind keine unvermeidlichen Eigenschaften des Full-Page-Cachings. Ersetzt Ihre Implementierung nach dem Laden Fragmente der Kopfzeile oder des Warenkorbs, reservieren Sie Platz und testen Sie langsame Geräte. Eine sichtbare Warenkorbanzahl von null beweist für sich genommen nicht, dass der serverseitige Warenkorb leer ist.

Performance Revolution führt seinen Seitencache am Ursprungsserver innerhalb von PHP nach dem Bootstrap aus. Seine Zulässigkeitsregeln prüfen Kunden-, Warenkorb- und weitere Anfragekontexte. Die Hilfeseite behandelt unterstützte Abläufe für Seitencache, kritisches CSS, Cache-Aufwärmung und CDN.

Invalidierung gehört zum Konzept

• Leeren oder aktualisieren Sie betroffene Einträge nach Änderungen an Produkten, Kategorien, Bestand, Preisen, Aktionen, Übersetzungen und Konfiguration.
• Berücksichtigen Sie die geplante Aktivierung und den Ablauf von Preisregeln.
• Verlangen Sie, dass Importe und Integrationen die passende Invalidierung auslösen. Direkte Datenbankschreibvorgänge können Anwendungshooks umgehen.
• Nutzen Sie TTL als Grenze der Aktualität, nicht als Beweis, dass Änderungen sofort sichtbar werden.
• Wärmen Sie nur geeignete öffentliche Seiten auf und vermeiden Sie eine Überlastung des Ursprungsservers durch gleichzeitige Cache-Misses.

Testen Sie eine Preis- und eine Bestandsänderung über jeden von Ihnen genutzten Aktualisierungsweg. Manuelles Leeren kann einen Vorfall beheben, wiederkehrende veraltete Daten erfordern jedoch eine Korrektur der Invalidierung.

Praxisbeispiel: öffentliche Preise und ERP-Bestandsimport

Ihr Shop verkauft an Privatkunden in verschiedenen Ländern und bietet angemeldeten Geschäftskunden eigene Preise. Wärmen Sie eine öffentliche Produkt- und Kategorieseite in jedem unterstützten Preiskontext auf und melden Sie sich anschließend als Geschäftskunde an. Vergleichen Sie angezeigten Preis, Steuerdarstellung und Warenkorbsumme mit einer ungecachten Referenz; für den Geschäftskundenaufruf muss die vereinbarte Cache-Umgehung gelten.

Wärmen Sie im Staging die öffentlichen Varianten von Produkt- und Listenseiten auf und bestätigen Sie Treffer auf jeder aktivierten HTML-Cache-Ebene. Ändern Sie im Backoffice nur den Preis und vergleichen Sie anschließend jede Variante mit einer ungecachten Referenz, bevor Sie manuell leeren. Wärmen Sie erneut auf, bestätigen Sie Treffer, ändern Sie dann nur den Bestand über den tatsächlichen ERP-Import und wiederholen Sie die Prüfungen einschließlich Verfügbarkeitshinweisen und Edge-Kopien. Testen Sie jeden Aktualisierungsweg einzeln: Bleiben bei einem Weg alte Daten stehen, umgehen Sie den betroffenen Seitencache, bis dieser Weg ihn zuverlässig invalidiert.

Verbinden Sie Redis mit einer implementierten Integration

Redis ist ein Schlüssel-Wert-Dienst im Arbeitsspeicher, der auf Ihrem Server läuft oder von Ihrem Hoster bereitgestellt wird. Er kann Cache-Werte, Seitencache-Einträge oder PHP-Sessions speichern, wenn eine entsprechende Integration ihn nutzt. Bestimmen Sie zunächst Adapter, unterstützte PrestaShop-/PHP-Versionen, Schlüsselformat, TTL-Regeln, Invalidierung und Verhalten bei Ausfällen.

1. Prüfen Sie, ob Ihr Hoster einen erreichbaren Redis-Dienst bereitstellt. Ein vom Hoster verwalteter Dienst erfordert keinen eigenen SSH-Zugang.
2. Prüfen Sie den erforderlichen PHP-Client in der PHP-Weblaufzeit, nicht nur in CLI-PHP. PHP-FPM und CLI können unterschiedliche Konfigurationen laden.
3. Konfigurieren Sie Host, Port, Authentifizierung, gegebenenfalls TLS, Datenbank und Namensraum in der gewählten Integration. Verwenden Sie in Containern die richtige Dienstadresse; localhost bezeichnet den aktuellen Container.
4. Geben Sie jeder Installation und jedem erforderlichen Shop-/Gruppenbereich einen expliziten Namensraum. Ein gemeinsames Standardpräfix wie ps_ isoliert Shops nicht.
5. Besuchen Sie repräsentative Seiten und prüfen Sie adapterspezifische Schlüssel, TTLs sowie Lese- und Schreibvorgänge.
6. Testen Sie Invalidierung, Verbindungsfehler und Wiederherstellung in einer Staging-Umgebung.

Lokale Diagnosebeispiele unter der Annahme, dass Redis bewusst auf demselben Host über Port 6379 erreichbar ist:

redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 INFO stats
redis-cli -h 127.0.0.1 -p 6379 INFO memory
redis-cli -h 127.0.0.1 -p 6379 -n 0 DBSIZE

Beachten Sie die Authentifizierungs- und Transportanforderungen Ihres Dienstes. PONG bestätigt die Erreichbarkeit, nicht die Nutzung von Redis durch PrestaShop. Eine Schlüsselanzahl über null kann zu einer anderen Anwendung gehören. Untersuchen Sie Namensraum und Aktivität der gewählten Integration. Instanzweite Cache-Treffer und Cache-Misses zeigen nicht den Nutzen für einen einzelnen Shop.

Nutzen Sie SCAN mit einem bekannten Präfix zur kontrollierten Untersuchung. MONITOR kann Befehlsdaten offenlegen und Zusatzlast verursachen; beschränken Sie kurze Diagnoseeinsätze auf eine kontrollierte Umgebung.

Redis Cache Manager & Monitor bietet administrative Verbindungstests, Überwachung sowie Namensraum- und Schlüsselverwaltung; seine Hilfeseite behandelt die Modulabläufe.

Anwendungs-Cache-Adapter, PHP-Session-Konfiguration und Full-Page-Caching bleiben separate Integrationsarbeiten. Ein gespeicherter Schalter oder eine erfolgreiche Dashboard-Verbindung beweist nicht, dass sich ein Anwendungscache geändert hat. Bleibt der erwartete Namensraum leer, prüfen Sie ausgewählte Datenbank, Präfix und Seitenzulässigkeit, bevor Sie die Kapazität ändern. Prüfen Sie Verbindungsfehler der Web-Laufzeit und die Adapterkonfiguration; allein die Installation einer PHP-Erweiterung ergänzt die native Auswahl nicht um Redis.

Memcached ist eine weitere In-Memory-Cache-Option mit anderem Funktionsumfang. Für Redis und Memcached lassen sich PHP-Session-Handler separat konfigurieren. Wählen Sie anhand unterstützter Adapter, betrieblicher Anforderungen und Messungen, statt eines pauschal für schneller zu halten.

Trennen Sie Sessions, Verdrängung und Dauerhaftigkeit

PrestaShop-Warenkörbe sind Datenbankeinträge. Die Kundenidentität umfasst außerdem PrestaShop-Cookies und datenbankgestützte Einträge. PHP-/Symfony-Sessions bilden eine weitere Ebene. Das Verschieben von PHP-Sessions nach Redis verschiebt keine Warenkorbeinträge und garantiert keine ununterbrochene Kundenanmeldung.

Wenn Sie den PHP-Session-Handler ändern, befolgen Sie die phpredis-Konfigurationshinweise für Ihre installierte Version und wenden Sie sie auf den richtigen PHP-FPM-Pool an. Prüfen Sie, wo das Framework Ihrer Anwendung die Session-Konfiguration erwartet.

Definieren Sie Session-TTLs, Sperren, Authentifizierung, Kapazität, Persistenz und Fehlerverhalten. Auch Redis-gestützte Sessions können Sperren benötigen, damit parallele Anfragen keinen Zustand überschreiben. Testen Sie parallele Anfragen derselben Session und verschiedener Sessions.

Separate Redis-Datenbanknummern können Schlüssel unterscheiden helfen, teilen aber Instanzspeicher, Verdrängungsregeln und Ausfallrisiken. Ein Cache-Flush kann Sessions betreffen, wenn der Geltungsbereich falsch ist. Bevorzugen Sie einen separat bereitgestellten Session-Dienst, wenn Sessions andere Anforderungen an Dauerhaftigkeit und Verdrängung haben.

Redis-Verdrängungsregeln gelten für die Instanz. volatile-lru verdrängt Schlüssel mit TTLs, darunter gegebenenfalls Sessions. Es schützt sie nicht. Wählen Sie die Cache-Verdrängung bewusst und überwachen Sie Schreibfehler, wenn eine Regel ohne Verdrängung verwendet wird.

Wählen Sie für Sessions RDB-/AOF-Persistenz, Replikation und Wiederherstellungsziele ausdrücklich. Persistenz reduziert manche Verlustszenarien, garantiert aber weder Verlustfreiheit noch ununterbrochene Anmeldungen.

Prüfen Sie bei einem Shop mit Lastverteilung, ob jeder Webknoten das vorgesehene gemeinsame Backend und einen kompatiblen Namensraum verwendet. Proben Sie einen Ablauf, der zwischen Knoten wechselt. Gemeinsamer PHP-Session-Speicher allein behebt keine Unterschiede bei Anwendungskonfiguration, Cookie-Geltungsbereich oder geheimen Schlüsseln und ersetzt nicht die Datenbank mit den Warenkörben.

Dimensionieren Sie Redis anhand gemessener Schlüsselanzahlen, Nutzlastgrößen, Varianten, TTLs und Spitzenlast. Beobachten Sie used_memory, used_memory_peak, maxmemory, evicted_keys, abgelehnte Schreibvorgänge und Verbindungen. In einem begrenzten Cache für entbehrliche Daten kann Verdrängung erwartbar sein; bewerten Sie sie zusammen mit Latenz und Treffermustern. Es gibt keine Speicherformel nach Kataloggröße und kein universelles Ziel von 90 % Trefferquote.

Berechnen Sie die Trefferquote für einen Beobachtungszeitraum als Zuwachs von keyspace_hits geteilt durch die Summe der Zuwächse von keyspace_hits und keyspace_misses. Schließen Sie Zeiträume mit zurückgesetzten Zählern oder ohne Abfragen aus. Diese Zähler umfassen die gesamte Redis-Instanz, nicht nur den Shop. Eine geringe Wiederverwendung kann auf viele Länder-/Währungsvarianten oder selten erneut besuchte URLs zurückgehen. Setzen Sie sie mit Ablaufzeiten, Importen, Leerungen und Speicherdruck in Beziehung, bevor Sie maxmemory erhöhen. Beobachten Sie connected_clients zusammen mit Zugriffszahlen und Verbindungsfehlern; ein Anstieg allein beweist kein Leck.

Konfigurieren Sie Cloudflare oder Varnish passend zur Anwendung

Cloudflares Standard-Cache-Verhalten richtet sich vor allem auf geeignete statische Ressourcen; HTML-Caching erfordert eine bewusste Konfiguration. Beginnen Sie mit statischer Auslieferung und bestätigen Sie, dass dynamische Anfragen privat bleiben. Nutzen Sie Full (Strict) TLS mit gültigem Ursprungszertifikat und passendem Hostnamen. Der Flexible-Modus verwendet HTTP zum Ursprungsserver und kann mit HTTPS-Weiterleitungen kollidieren.

• Schließen Sie Warenkorb, Kasse, Konto, Adminbereich, API, AJAX und Zahlungs-Callbacks vom gemeinsamen HTML-Cache aus.
• Beachten Sie private/no-store-Anweisungen und das Set-Cookie-Verhalten. Testen Sie die tatsächlich wirksamen Edge-Regeln, nicht nur Ursprungsheader.
• Lassen Sie E-Mail-bezogene DNS-Einträge ohne Proxy, sofern der Maildienst dies verlangt.
• Übernehmen Sie echte Besucheradressen nur von vertrauenswürdigen Cloudflare-Proxys. Vertrauen Sie keinem beliebigen vom Client gelieferten Weiterleitungsheader.
• Testen Sie WAF- und Bot-Regeln mit Zahlungs-Callbacks, Bestellabschluss und Integrationen.
• Deaktivieren Sie Rocket Loader oder schließen Sie Kassenskripte ausdrücklich aus, wenn er deren erforderliche Reihenfolge verändert; testen Sie den gesamten Ablauf.

Eine kontrollierte CDN-HTML-Integration kann nur geeignete anonyme GET-/HEAD-Antworten zum Cachen kennzeichnen und für andere Kontexte Bypass-Header senden. Konfigurieren Sie unterstützte Löschmechanismen und prüfen Sie die aktuellen Möglichkeiten Ihres Kontos. Header allein beweisen nicht, dass die Edge eine Antwort gecacht oder den Cache umgangen hat.

Varnish ist ein HTTP-Reverse-Proxy. Bei einem Treffer kann er vor der PHP-Ausführung antworten. Er benötigt Regeln für Methoden, Cookies, Cache-Schlüssel, private Antworten, Invalidierung und Fehlerverhalten. Viele Installationen terminieren TLS in einer separaten Komponente. Dynamische Fragmente sind optionale Implementierungsarbeit.

Fügen Sie einen Reverse-Proxy hinzu, wenn gemessener anonymer Traffic oder die Auslastung der PHP-Worker seinen Betrieb rechtfertigen. Er beseitigt nicht die Verarbeitung ungecachter Kassenanfragen. Planen Sie ausreichend Kapazität am Ursprungsserver für Cache-Misses, Löschungen und Ausfälle ein und schützen Sie Invalidierungsendpunkte.

Leeren und untersuchen Sie den richtigen Cache

Beginnen Sie mit Erweiterte Einstellungen > Leistung > Cache leeren. Halten Sie fest, welches Symptom Sie untersuchen. Ein Neuladen im Browser leert weder den Ursprungs-, OPcache- noch Edge-Cache.

1. Nutzen Sie nach Möglichkeit Staging. Ändern oder umgehen Sie jeweils nur eine Ebene.
2. Leeren Sie die unterstützten Anwendungscaches und prüfen Sie die Seite direkt am Ursprungsserver über Ihren autorisierten Diagnoseweg.
3. Invalidieren Sie gegebenenfalls den beteiligten separaten Modul- oder Redis-Namensraum.
4. Setzen Sie den Web-OPcache nur zurück, wenn das Deployment es erfordert. Ein CLI-Aufruf von opcache_reset() setzt den PHP-FPM-Pool der Webanwendung normalerweise nicht zurück.
5. Leeren Sie betroffene Proxy-/CDN-Einträge, nachdem der Ursprungsserver korrekt antwortet.
6. Prüfen Sie eine neue anonyme und eine personalisierte Anfrage erneut und stellen Sie dann die vorgesehenen Einstellungen wieder her.

var/cache/prod und var/cache/dev bleiben nach der Installation eines separaten Redis-Adapters für Framework- und Smarty-Caches aktiv. Ältere 1.6-Strukturen verwenden cache/smarty; das ältere CacheFs nutzt cache/cachefs. Bestätigen Sie vor jeder Dateisystembereinigung Ihre genaue Version und das Stammverzeichnis.

Bevorzugen Sie die unterstützte Funktion zum Cache-Leeren. Erfordert die Wiederherstellung eine manuelle Bereinigung, isolieren Sie die Website, erhalten Sie Verzeichnisstruktur und Zugriffsrechte, führen Sie sie als Anwendungsbenutzer aus und prüfen Sie Eigentümer sowie Cache-Neuaufbau. Löschen Sie nicht rekursiv ohne klaren Geltungsbereich aus einem unklaren Arbeitsverzeichnis.

Nutzen Sie eine auf die Integration abgestimmte Namensraum-Invalidierung. FLUSHDB löscht jeden Schlüssel der gewählten Datenbank; FLUSHALL löscht jede Datenbank der Instanz. Auf gemeinsam genutzter Infrastruktur ist keines davon ein sicherer Ersatz für das gezielte Leeren eines Shops.

Liefert das Caching falsche Preise, persönliche Informationen oder einen falschen Kassenzustand, umgehen Sie die betroffene Ebene bis zur Korrektur und Prüfung. Produktive Cache-Einstellungen sollten sich nach Korrektheit und gemessener Last richten statt nach einer pauschalen Regel, jeden Cache aktiviert zu lassen.

Messen Sie die Leistung und optimieren Sie die Verarbeitung ungecachter Anfragen

Erfassen Sie kalte und warme Antworten für dieselben URLs, Daten, Sprachen, Währungen, Geräte und Anmeldestatus. Berücksichtigen Sie Parallelität, Ursprungslast und Cache-Status. Vergleichen Sie gewöhnliches Browsen mit Warenkorb- und Kassenanfragen. Messen Sie wiederholte Durchläufe statt einer einzelnen Anfrage.

TTFB misst die Verzögerung bis zum Beginn der Antwort. Die Kennzahl hilft bei der Ladezeitdiagnose, ist aber kein Core Web Vital. Die Core Web Vitals sind LCP, INP und CLS. Geben Sie LCP und INP als Zeit, CLS als dimensionslosen Wert und einen Lighthouse-Leistungsscore separat an. Bessere Werte garantieren keine Rankings.

Nutzen Sie den klassischen PrestaShop-Profiler für gewöhnliche Anfragen des klassischen Storefront-Stacks auf geschütztem Staging. Verwenden Sie Symfony-Profiling für Anfragen, die Symfony verarbeitet. Produktives APM, Slow-Query-Logs und Webserver-Metriken können helfen, ohne eine Debug-Seite offenzulegen.

• Analysieren Sie aufwendige Hooks, wiederholte Abfragen und direkte externe Aufrufe. Cachen Sie nur Daten, deren Aktualität und Geltungsbereich Sie definieren können.
• Beheben Sie fehlende Indizes und teure Abfragen. Wenden Sie vor dem Bereinigen von Logs, E-Mail-Einträgen oder Verbindungsdaten eine Aufbewahrungsregel an.
• Nutzen Sie unterstützte Smarty-Kompilierungseinstellungen und leeren Sie kompilierte Templates bei Bedarf nach dem Deployment.
• Aktivieren und dimensionieren Sie OPcache für die Weblaufzeit. JIT ist separat und erfordert einen Anwendungsbenchmark. Ist die Zeitstempelprüfung deaktiviert, setzen Sie OPcache beim Deployment zuverlässig zurück.
• Wählen Sie PHP anhand der Kompatibilitätsmatrix der genauen Version. PrestaShop 1.7.8 unterstützt PHP 8 offiziell nicht.
• Stimmen Sie MySQL auf Ihre Last und das gesamte Speicherbudget ab. MySQL 8.0.30+ verwendet innodb_redo_log_capacity; MariaDB und ältere MySQL-Versionen unterscheiden sich.
• Testen Sie CSS-/JavaScript-Optimierung, kritisches CSS, responsive Bilder und Drittanbieterskripte. Reservieren Sie Bildabmessungen und Platz für dynamische Oberflächenelemente, um Layoutverschiebungen zu begrenzen.

Bleibt dieselbe Anfrage nach Aktivierung eines Caches langsam, untersuchen Sie auch die Cache-Verarbeitung: Schlüsselerstellung, Serialisierung, Sperren und wiederholte Asset-Hashberechnung können den Anfrageweg zusätzlich belasten. Vergleichen Sie diesen Aufwand mit der eingesparten Arbeit, auch bei einem Cache-Miss.

Ein Cache kann wiederholte Arbeit reduzieren, während Cache-Misses langsam bleiben. Behalten Sie ihn, wenn er die gemessene Leistung sicher verbessert; entfernen oder ersetzen Sie ihn erst nach Tests der resultierenden Last und Kundenerfahrung.

Umstellung proben und Wiederherstellung übergeben

1. Dokumentieren Sie aktuelle Einstellungen, Anfragezeiten und Cache-Status für repräsentative Start-, Kategorie- und Produktseiten sowie Warenkorb und Kasse. Halten Sie die genauen Testkontexte fest, damit sich der Vergleich wiederholen lässt.
2. Wärmen Sie im Staging die vorgesehenen öffentlichen Varianten auf. Verwenden Sie separate Browserprofile für anonyme Besucher und Kunden mit unterschiedlichen Gruppen oder Währungen. Prüfen Sie neben dem Seiteninhalt auch Warenkorb, Anmeldung und personalisierte Kopfzeile.
3. Führen Sie Aktualisierungen über das Backoffice, geplante Aktionen und jeden genutzten Import oder jede Integration aus. Vergleichen Sie Anwendungscache und mögliche Proxy-/CDN-Kopien mit den erwarteten aktuellen Daten.
4. Proben Sie eine Leerung und Aufrufe mit kaltem Cache bei repräsentativer Gleichzeitigkeit. Machen Sie anschließend Redis oder den Seitencache-Dienst in der kontrollierten Umgebung unerreichbar und prüfen Sie Fehler, zusätzliche Last beim Ausweichen und Wiederherstellung für jede aktivierte Ebene separat.
5. Vereinbaren Sie das Umstellungsfenster, den Auslöser für die Rücknahme und die zuständige Person. Übernehmen Sie die getestete Konfiguration, invalidieren oder wärmen Sie nur den vorgesehenen Bereich und prüfen Sie echte Seitenaufrufe, Käufe und den nächsten Import nach der Umstellung.

Bei entbehrlichem gecachtem HTML kann eine Rücknahme darin bestehen, diese Ebene zu umgehen und ihre Kopien zu leeren. Die Rücknahme eines Session-Handlers benötigt ein eigenes Verfahren: Der vorherige Speicher enthält möglicherweise keine nach der Umstellung erstellten Sessions. Vereinbaren Sie vor einem Handlerwechsel die erwartete Sitzungskontinuität und proben Sie beide Richtungen. Ersetzen Sie die produktive Datenbank nicht durch die Staging-Datenbank, um eine Cache-Konfiguration einzuführen.

Fragen an Ihren Entwickler oder Ihre Agentur

• Welche Ebene ändert sich, wo stoppt ein Treffer die Verarbeitung, und was läuft weiter?
• Welche Anfragekontexte werden über Schlüssel unterschieden oder vom Cache ausgenommen, und wo liegt der Nachweis, dass private Inhalte nicht in gemeinsam genutzten Speicher gelangen können?
• Welche Aktualisierungen invalidieren welche Kopien, und wer ist für die Invalidierung bei ERP-Importen und geplanten Aktionen zuständig?
• Was geschieht bei einer Leerung, einem Cache-Ausfall oder der Rücknahme eines Session-Handlers, und kann der Ursprungsserver die entstehende Last tragen?
• Wo sind getestete Einstellungen, Namensraumübersicht, Überwachung, Anleitungen zur gezielten Leerung und Wiederherstellungsverfahren für Mitarbeiter dokumentiert?

Fragen von Shopbetreibern

Welchen Cache sollte ich zuerst kaufen?

Orientieren Sie sich an der langsamen Anfrage und der Arbeit, die sie wiederholt. Verlangen Sie eine Ausgangsmessung und einen reversiblen Test, bevor Sie Infrastruktur oder ein weiteres Modul kaufen. Ist die Diagnose unklar, hilft der Leistungsleitfaden, die Messungen zu strukturieren.

Ersetzt Redis OPcache oder die Datenbank?

Nein. OPcache verwendet kompilierten PHP-Code wieder; eine Redis-Integration verwendet ausgewählte Werte wieder oder speichert Sessions. Die Datenbank enthält weiterhin Ihre Shopdatensätze und ungecachte Anfragen benötigen weiterhin ausreichend Kapazität.

Warum ist ein erneuter Besuch schnell, während ein neuer Besucher wartet?

Der erneute Besuch trifft möglicherweise einen Browser-, Seiten- oder Datencache, den die neue Anfrage verfehlt. Prüfen Sie den tatsächlichen Cache-Status und Besucherkontext und vergleichen Sie anschließend kalte und warme Ergebnisse. Ihr eigener aufgewärmter Browser belegt nicht das Erlebnis beim Erstbesuch.

Sollte ich bei einer Störung alle Caches aktiviert lassen?

Umgehen Sie die Ebene, die falsche oder private Inhalte ausliefert, und untersuchen Sie sie anschließend anhand einer ungecachten Referenz. Prüfen Sie die Last des Ursprungsservers, während er mehr Anfragen übernimmt, und stellen Sie nach der Fehlerbehebung die getesteten Regeln wieder her.

Kann ich Full-Page-Caching nach der Shopoptimierung entfernen?

Erproben Sie das Umgehen zunächst im Staging unter repräsentativer Last. Behalten oder entfernen Sie es abhängig von korrekten Ergebnissen, Spitzenkapazität und Kundenerlebnis; eine schnellere ungecachte Seite allein zeigt nicht, dass auch Spitzenlast abgedeckt ist.