Cache-Strategie PrestaShop 2026: Redis, Memcached, Varnish — welche Stack für welchen Shop

Bei einem nicht optimierten PrestaShop-8- oder 9-Shop überschreitet die TTFB (Time To First Byte) auf Shared Hosting häufig 800 ms und liegt auf einem Mid-Range-VPS bei etwa 400 ms. Direkter Effekt auf LCP (schlechter Core-Web-Vitals-Score), auf das Googlebot-Crawl-Budget und auf die Absprungrate. Das alles 2026, während Googles Benchmark auf 200 ms TTFB und 2,5 s LCP heruntergegangen ist.

Cache ist weder ein Nischenthema noch großen Volumina vorbehalten. Es ist die Optimierung mit dem höchsten ROI bei PrestaShop und diejenige, die am schlechtesten gemacht wird: Verwechslung zwischen PHP-Cache, Objekt-Cache, HTTP-Cache und Reverse Proxy; wenig effektive Default-Konfigurationen; Modul-Stapel, die sich gegenseitig stören. Dieser Artikel zieht Bilanz über die vier Schichten einer sauberen Stack und gibt die Entscheidungsregel Redis / Memcached / Varnish nach Shop-Profil.

Die vier Cache-Schichten eines PrestaShop-Shops

Ein Shop bedient jede Seite durch Stapeln mehrerer Cache-Schichten. Die Schichten zu kennen bedeutet, nicht mehr aufeinanderzustapeln, als nötig — jede Schicht fügt Komplexität und Purge-Punkte hinzu, die zu beherrschen sind.

1. PHP-Opcode-Cache

OPcache cached den Bytecode interpretierter .php-Dateien. Unverzichtbar: ohne OPcache interpretiert jede Anfrage Tausende von PrestaShop-Dateien neu. Typischer Gewinn: 30 bis 50 % TTFB. Es ist kostenlos, nativ in PHP, und ist der erste Reflex, der in Produktion über php -i | grep opcache zu validieren ist. Zu dimensionieren: mindestens 256 MB für PrestaShop 8/9, opcache.validate_timestamps=0 in Produktion mit manuellem Recycling beim Deployment.

2. Objekt-Cache (In-Memory Key-Value)

PrestaShop cached bestimmte anwendungsbezogene Ergebnisse: Nutzersitzungen, Smarty-Metadaten (Template-Pfade, Hook-Konfigurationen), Ergebnisse wiederholter Abfragen. Standardmäßig laufen diese Caches über das Dateisystem, langsam. In ernsthafter Produktion verlagert man sie zu einer In-Memory-Datenbank: Redis oder Memcached.

3. HTTP-Cache und Reverse Proxy

Oberhalb von PrestaShop fängt ein Reverse Proxy (Varnish, NGINX-Cache oder Edge-Cache-CDN) HTTP-Anfragen ab und liefert vorgerenderte Antworten aus, ohne PHP zu belasten. Das ist die Optimierung mit der höchsten Hebelwirkung — typischer Gewinn von 90 % Serverzeit bei anonymen Seiten im Cache-Hit.

4. Browser-Cache und CDN

Statische Ressourcen (Bilder, CSS, JS, Schriften) müssen Cache-Control: public, max-age=31536000, immutable-Header tragen und von einem CDN ausgeliefert werden. 2026 selbstverständlich, aber bei 40 % der auditierten Shops schlecht gemacht: zu kurzes max-age, nicht versionierte Ressourcen, falsch konfigurierte Cache-Variationen.

Redis vs Memcached: die praktische Entscheidung

Beim Objekt-Cache dominieren zwei Optionen: Redis und Memcached. Die Debatte «welcher ist schneller» ist überholt — beide übertreffen den Bedarf eines PrestaShop-Shops. Der echte Unterschied liegt anderswo.

Memcached

• Einfacher, weniger Funktionen, kleinere Angriffsfläche und weniger Konfigurationsfallen.
• Hervorragend für ephemeren reinen Key-Value-Cache.
• Keine Festplattenpersistenz: ein Neustart leert alles, was einen vorübergehenden Thundering Herd auf PHP-FPM erzeugt.
• Keine erweiterten Strukturen (Listen, Sorted Sets, Pub-Sub) — Verwendung auf strengen Cache begrenzt.

Redis

• Reicher: Datenstrukturen (Lists, Sets, Sorted Sets), Pub-Sub, Lua-Scripting.
• Optionale Persistenz (RDB oder AOF): überlebt Neustarts.
• Weit über den PrestaShop-Cache hinaus verwendet: Multi-Server-Sessions, Symfony-Messenger-Queue, Rate Limiting.
• Speicher-Konfiguration zu überwachen (maxmemory, Eviction Policy) — sonst verbraucht es mehr als vorgesehen.

Praxis-Regel 2026: Redis ist die Standardwahl. Memcached bleibt relevant, wenn der Shop bewusst minimalistisch ist und die einzigen Bedürfnisse reiner Objekt-Cache sind. Jeder Shop, der mittelfristig eine Job-Queue, API-Rate-Limiting oder geteilte Multi-Server-Sessions plant, gewinnt, indem er direkt mit Redis startet.

Wann Varnish Sinn ergibt (und wann nicht)

Varnish (oder Full-Page-NGINX-Cache) ist die Optimierung mit der höchsten Hebelwirkung auf PrestaShop: Es bedient anonyme Seiten in wenigen Millisekunden statt 400-800 ms. Aber Varnish ist nicht in allen Konfigurationen ein Game-Changer.

Fälle, in denen Varnish alles ändert

• Mehrheitlich anonymer Traffic: nicht angemeldete Besucher, keine kundenspezifischen Preise, kein serverseitiges A/B-Testing. Massenmarkt-B2C-Katalog.
• Hohes Volumen konzentriert auf wenige URLs: eine Homepage, 50 Kategorien, 500 Produktseiten machen 80 % des Traffics aus. Der Cache macht den Großteil der Arbeit.
• Vorhersehbare saisonale Spitze: Black Friday, Sale. Varnish absorbiert den Traffic, ohne PHP-FPM zu sättigen.

Fälle, in denen Varnish eine Falle ist

• B2B-Shop mit Anmeldepflicht: jede Seite ist personalisiert (Kundengruppenpreis, Multi-User, laufende Angebote). Varnish bedient nur die öffentlichen (seltenen) Seiten, und die Komplexität übersteigt den Gewinn.
• Serverseitige Personalisierung: KI-Empfehlungen pro Nutzer, serverseitiges A/B-Testing, dynamische Preise. Der Full-Page-Cache macht die ganze Personalisierung hinfällig.
• Anonymer Traffic verteilt auf Tausende Long-Tail-URLs: Wird jede URL einmal am Tag besucht, bleibt die Hit-Ratio niedrig, und Varnish bringt nichts.

Die Edge-Cache-CDN-Alternative

2026 erledigen Cloudflare Cache Rules, BunnyCDN Permacache, Fastly und andere Edge-Caches die Arbeit von Varnish auf CDN-Ebene, ohne zusätzlichen Server. Vorteil: keine Schicht zu pflegen, geografische Verteilung, native WAF-Integration. Nachteil: das feingranulare Purge ist weniger flexibel als bei Varnish, und die Kosten können bei großen Volumina steigen. Für 80 % der Mid-Market-Shops ist Edge-Cache-CDN zur überlegenen Alternative zu einem selbst gehosteten Varnish geworden.

Reale Kosten und ROI einer sauberen Cache-Stack

Kosten

• OPcache: 0 €. Aktivieren und richtig dimensionieren.
• Redis: 0 € lokal (gleicher Server wie PHP-FPM) bis 15-30 €/Monat auf dediziertem VPS (Hetzner CX11) oder managed Redis (Upstash, Redis Cloud) ab 10 €/Monat.
• Varnish: 0 € Open Source, aber 1 bis 3 Tage Installation und Tuning durch einen kompetenten Sysadmin. In Zeit budgetieren, nicht in Lizenz.
• Edge-Cache-CDN: Cloudflare Pro 25 $/Monat, BunnyCDN ca. 1 $/GB übertragen, Fastly ab 50 $/Monat usage-based.
• Initial-Implementierung: 2 bis 5 Tage Entwicklung für einen Standard-Shop (Konfiguration, Tests, automatische Purge über PrestaShop-Webhook).

Gemessener ROI

Bei Audits von Mid-Market-PrestaShop-8-Shops nach Deployment einer sauberen Cache-Stack:

• TTFB sinkt von 600-800 ms auf 80-150 ms im Cache-Hit.
• LCP fällt von 3,2 s auf 1,4 s auf anonymer Produktseite.
• Mobile-Absprungrate sinkt im Durchschnitt um 12 bis 18 %.
• Mobile-Konversion steigt um 6 bis 12 %.
• Google-Crawl-Budget verdoppelt sich, was sich in 4-8 Wochen in +15 % indexierten URLs niederschlägt.

Die Opportunitätskosten, keinen sauberen Cache einzurichten, überschreiten oft 1 % des Jahresumsatzes. Ein Shop mit 1 M€/Jahr verliert typischerweise 10 bis 20 K€/Jahr durch verschlechterte Performance.

Fallen, die zu vermeiden sind

1. Cache-Module ohne Kohärenz stapeln

Viele Shops häufen an: offizielles PrestaShop-Cache-Modul, Drittanbieter-Redis-Modul, separates Varnish-Modul, CDN-Plugin. Ohne klare Hierarchie invalidieren sich die Caches schlecht gegenseitig, und einige Hits annullieren die anderen. Es braucht eine einzige dokumentierte Cache-Politik mit einem klaren Schema kaskadierender Purge.

2. Event-basierten Purge schlecht verwalten

Wenn ein Preis ändert, ein Stock aktualisiert wird, ein Produktattribut modifiziert wird, muss die betroffene Seite gepurgt werden. PrestaShop hat keinen einheitlichen Hook — es müssen actionProductUpdate, actionObjectStockMvtAddAfter, actionObjectCategoryUpdateAfter verdrahtet und der richtige Purge ausgelöst werden (Varnish PURGE, Redis DEL, CDN-API). Sonst sieht der Besucher einen veralteten Preis, was unter die Omnibus-Richtlinie fallen kann.

3. Personalisierte Seiten cachen

Der Warenkorb, das Kundenkonto, der Checkout und jede Seite mit Nutzerdaten dürfen niemals in den Full-Page-Cache. Die Varnish- oder CDN-Regel muss diese Routen explizit ausschließen (/cart, /mein-konto, /bestellung, /identitaet). Häufiger Fehler: ein Shop, der standardmäßig alles cached, zeigt den Warenkorb eines anderen Kunden an. Schwerer Vorfall, schwer im Nachhinein zu diagnostizieren.

4. Nicht unter Last testen

Ein sauberer Cache wird unter Last validiert. Ein Tool wie k6 oder Locust ermöglicht es, 500-1000 gleichzeitige Besucher zu simulieren und Hit-Ratio, TTFB unter Last, PHP-FPM-Stabilität zu messen. Ohne diesen Test entdeckt man Probleme in Produktion an einem Spitzentag — der schlechteste Moment zum Korrigieren.

5. Multishop und Multi-Currency vergessen

Ein zu aggressiver Cache auf einem Multishop kann allen Shops dieselbe HTML-Seite servieren oder den EUR-Preis einem GBP-Besucher anzeigen. Der Cache-Key muss mindestens id_shop, id_lang, id_currency enthalten. Den generierten Cache-Key explizit prüfen — das ist der teuerste stille Fehler in Konversionsverlust.

Die 2026 standardmäßig empfohlene Stack

Für 80 % der Mid-Market-PrestaShop-8/9-Shops (Umsatz 200 K€ bis 5 M€/Jahr):

1. OPcache aktiviert mit 256 MB und opcache.validate_timestamps=0 in Produktion.
2. Redis als PrestaShop-Objekt-Cache-Backend (Sessions, Smarty, Metadaten). Eine Instanz reicht in den meisten Fällen.
3. Edge-Cache-CDN (Cloudflare oder BunnyCDN) auf öffentlichen Katalog- und CMS-Seiten, mit explizitem Ausschluss der Nutzerrouten.
4. Aggressiver Browser-Cache auf statischen Ressourcen (1 Jahr), per Hash über das PrestaShop-Asset-System versioniert.
5. Kein Varnish außer im spezifischen Fall hohen homogenen Traffics, wo sich Tuning und Wartung rechtfertigen.

Diese Stack wird in 2 bis 5 Tagen deployt, kostet 10 bis 30 € pro Monat an wiederkehrenden Kosten und bringt einen Performance-Gewinn, der weit über dem liegt, was man durch Optimierung des Anwendungscodes erreichen kann. Vor jeder Backend-Optimierung (Modul-Refactoring, SQL-Queries) bleibt die Durchsicht dieser fünf Punkte der erste rentable Schritt.