Full-Page-Cache

P2Lab Cache ersetzt Shopwares Standard-HTTP-Cache-Store und liefert komplette HTML-Antworten für cachefähige Storefront-Routen aus. Sobald eine Seite im Cache liegt, erhält der nächste Besucher sie ohne Berührung von Template-Engine, Datenbank oder Framework-Boot — nur die HTTP-Schicht.

Was gecacht wird

Jede Storefront-Antwort wird einem Cache-Typ zugeordnet:

Typ	Was er abdeckt
product	Produktdetailseiten (`frontend.detail.page`)
category	Kategorie-Landingpages (`frontend.navigation.page`)
listing	AJAX-Listings + Filter-Antworten (`frontend.navigation.page.ajax`, `frontend.navigation.filter`)
cms	CMS-Seiten und Startseite (`frontend.home.page`, `frontend.cms.page`)
buybox	Async-Buybox-Antworten (Standard aus)

Schalten Sie jeden Typ einzeln unter Einstellungen → Speed Boost → Dashboard → Cachefähige Routen.

Was nicht gecacht wird

P2Lab Cache folgt denselben Regeln wie Shopwares Standard-HTTP-Cache fürs Umgehen:

Eingeloggte Kunden (Session-Cookie + Customer-Context)
Warenkörbe mit mindestens einer Position
POST / PUT / DELETE — nur GET-Antworten werden gecacht
Antworten mit Cache-Control: no-store oder private
Antworten, die sensible Cookies setzen
Anfragen mit nicht ignorierten Query-Parametern

Das Plugin ergänzt einen Schalter: Ignorierte Query-Parameter (siehe Query-Parameter-Filterung). Jeder dort gelistete Parameter wird vom Cache-Key entfernt — sodass ?utm_source=newsletter und die bloße URL denselben Eintrag teilen.

Cache-Lookup-Fluss

Für jede cachefähige GET-Anfrage:

Cache-Key berechnen — URL + Sales Channel + Währung + Theme + bereinigter Query-String.
Lookup im Backend — Filesystem, Redis oder APCu (was konfiguriert ist).
Wenn gefunden und nicht abgelaufen → aus Cache liefern (HIT). Cache-Control-Header senden und, falls Debug-Modus an, die X-P2Lab-Cache-*-Header.
Wenn nicht gefunden → Shopware rendern lassen, Antwort abfangen, unter dem Cache-Key mit passender TTL und Tag-Set speichern und zurückgeben (MISS).

Was gespeichert wird

Jeder Cache-Eintrag speichert:

Den vollen HTTP-Response-Body (optional gzip-komprimiert)
Die Response-Header, die Shopware setzt
Das Tag-Set, das für diese Antwort berechnet wurde — wird später zur Invalidierung verwendet
Metadaten fürs Dashboard: Originalgröße, Cache-Größe, Generierungszeit, Cache-Hit-Zeit, Typ

Metadaten jedes Eintrags werden zusätzlich in der Datenbank persistiert (p2lab_cache_entry), damit das Dashboard Zahlen unabhängig vom gewählten Backend ausweisen kann.

TTL und Frische

Drei Einstellungen kontrollieren, wie lange ein Eintrag lebt:

Cache-TTL (Standard: 1 Tag) — serverseitige TTL. Der Eintrag wird nach dieser Zeit aus dem Backend entfernt.
max-age (Standard: 0) — Cache-Control: max-age=… an den Browser. 0 bedeutet, dass der Browser jedes Mal revalidieren muss (der Cache liefert die Antwort trotzdem schnell).
s-maxage (Standard: 6 Stunden) — Cache-Control: s-maxage=… an Shared Caches zwischen Ihnen und dem Browser.

Siehe Cache-Control-Header, wie die drei sich kombinieren.

Komprimierung

Wenn Cache-Komprimierung aktivieren an ist (Standard), wird der gespeicherte Payload mit gzip auf der gewählten Stufe komprimiert. Der HTTP-Response-Body an den Client ist von dieser Einstellung nicht betroffen — das übernimmt separat der Webserver.

Typische Einsparungen:

Stufe	Ratio	CPU-Aufwand
1	~30 %	sehr niedrig
3	~40 %	niedrig
6	~50 %	ausgewogen (empfohlen)
9	~55 %	höchster

Siehe Komprimierung für Tuning-Notizen.

Per-Typ-Leeren

Das Dashboard hat einen Alle leeren-Button plus Per-Typ-Buttons (Produkte / Kategorien / Listings / CMS / Buybox). Verwenden Sie sie statt den ganzen Symfony-Cache zu leeren, wenn Sie nur einen Ausschnitt entfernen wollen — z. B. nach einem reinen CMS-Deploy.

Statistiken

Für jeden Eintrag notiert das Plugin:

Anzahl pro Typ
Cache-Gesamtgröße vs. Original-Gesamtgröße → gesparter Gesamtplatz
Durchschnittliche Generierungszeit (MISS-Rendering)
Durchschnittliche Cache-Hit-Zeit (HIT-Auslieferung)

Das Dashboard aktualisiert diese während Warmups in Echtzeit. Siehe Admin-Dashboard.