Einführung

P2Lab Cache ist ein Shopware-6-Plugin, das vollständige HTML-Antworten für cachefähige Storefront-Routen speichert und sie bei weiteren Aufrufen ausliefert. Statt die Startseite, eine Produktseite oder ein Kategorie-Listing für jeden Besucher neu aufzubauen, gibt Ihr Shop die vorbereitete Antwort in Millisekunden zurück — Serverlast sinkt, die wahrgenommene Ladezeit verbessert sich.

Das Plugin wird im Shopware Store als Speed Boost verkauft, intern aber durch den technischen Namen P2LabCache identifiziert.

Was es tut

Full-Page-Cache — fängt Shopwares HTML-Ausgabe für Home, Navigation, Produktdetail, CMS und Async-Buybox ab und liefert sie aus
Intelligente feldbasierte Invalidierung — wenn sich ein Produkt oder eine Kategorie ändert, werden nur die Cache-Einträge gelöscht, die vom geänderten Feld abhingen
Drei Storage-Backends — Filesystem (Standard), Redis (Cluster), APCu (In-Memory)
Interne Komprimierung — optionales gzip der gespeicherten Payloads, spart Speicher
Reverse-Proxy-Integration — Varnish-Purge über xkey mit drei Strategien (Default / Precise / Smart), Tag-Blocklist, Splitting und Verkürzung
Cache-Warming — queue-gesteuertes Warming, das nach Deployments oder vollständigem Leeren alle cachefähigen URLs vorbefüllt
Admin-Modul — Dashboard mit Statistiken, Schnellleerung, Diagramme pro Typ, Invalidierungslog, Reverse-Proxy-Log und Warmup-Historie
REST-API + CLI — Automatisierung von Leerung und Warming aus Deploy-Skripten

Jede gecachte Seite verfolgt ihre Originalgröße, ihre Cache-Größe, ihre Generierungszeit und ihre Cache-Hit-Zeit, sodass das Dashboard echte Zahlen anzeigt — gesparter Gesamtplatz, durchschnittliche HIT-Geschwindigkeit usw.

Für wen ist es

Shop-Betreiber mit mittelgroßen bis großen Shopware-6-Katalogen, die unter Lastspitzen Generierungslatenz spüren
DevOps-Teams, die Shopware hinter Varnish betreiben und feldbasierte Purges statt breiter Invalidierung wollen
Agenturen, die eine Caching-Konfiguration über mehrere Stores standardisieren

Was Sie brauchen

Shopware 6.6 (die composer.json des Plugins schränkt shopware/core auf >=6.6 <6.7 ein; ein 6.7-Build wird separat ausgeliefert)
Ein laufender Async-Message-Worker (bin/console messenger:consume async) — erforderlich für Cache-Warming und einige Invalidierungspfade
Je nach gewähltem Backend:
- Filesystem — Speicherplatz unter var/cache/ (oder wo Ihr Symfony-Cache-Verzeichnis liegt)
- Redis — erreichbare Redis-Instanz und ein DSN wie redis://host:6379
- APCu — die PHP-Erweiterung apcu installiert und aktiviert (nur Single-Server)
(Optional) Varnish mit geladenem xkey-VMOD, wenn Sie Reverse-Proxy-Purges möchten

Wie es sich vom eingebauten HTTP-Cache von Shopware unterscheidet

Shopware 6 liefert einen Symfony-HttpCache mit, der Antworten bereits speichert und nach Tags invalidiert. P2Lab Cache ersetzt den Default-Cache-Store durch eine eigene Implementierung und ergänzt:

Einen Smart-Invalidierungsmodus, der prüft, welche Entitätsfelder sich tatsächlich geändert haben, und sie auf ein minimales Tag-Set abbildet
Komprimierung der gespeicherten Payloads (Shopware speichert roh)
Statistiken pro Cache-Typ — Anzahl, Größe, gesparter Platz, durchschnittliche HIT- vs. MISS-Zeit
Einen Per-Typ-Leeren-Flow (alle Produktseiten, alle Listings, alle CMS, …) statt Alles-oder-Nichts
Cache-Warming über die Message Queue
Eine Varnish-Purge-Schicht mit feldbewusster Tag-Generierung, Blocklist und Header-Splitting

Wenn Sie bereits Varnish oder ein CDN nutzen, behalten Sie diese — P2Lab Cache liegt obenauf.