Cache-Control-Header
P2Lab Cache steuert vier unabhängige Cache-Lebenszeiten auf jeder cachefähigen Antwort. Falsche Kombination führt entweder dazu, dass veraltete Inhalte am Edge überreichlich gecacht werden, oder dass nicht genug gecacht wird und der Geschwindigkeitsvorteil verloren geht.
Alle vier konfiguriert unter Einstellungen → Speed Boost → Dashboard → Konfiguration.
Die vier Lebenszeiten
Abschnitt betitelt „Die vier Lebenszeiten“Server-TTL (serverTtl)
Abschnitt betitelt „Server-TTL (serverTtl)“Wie lange der Eintrag im Cache Ihres Origins (Filesystem / Redis / APCu) lebt. Standard 1 Tag.
Wenn das abläuft, löst die nächste Anfrage unabhängig von HTTP-Headern eine Regenerierung aus.
Setzen Sie das auf Ihre “maximal tolerierbare Staleness” — wie lange es akzeptabel ist, dass eine Seite ungenutzt im Cache liegt.
Cache-Control: max-age (Browser)
Abschnitt betitelt „Cache-Control: max-age (Browser)“Wie lange der Browser die gecachte Antwort wiederverwenden darf, ohne gegen Ihren Origin zu revalidieren. Standard 0 (kein Browser-Cache).
0 bedeutet, jedes Seitenladen trifft Ihren Origin (der die Antwort wahrscheinlich aus dem Cache liefert — schnell — aber der Roundtrip passiert). Erhöhen Sie auf z. B. 300 (5 Minuten), wenn der Browser den Roundtrip für eine kurze Zeit überspringen soll.
Cache-Control: s-maxage (Shared Cache)
Abschnitt betitelt „Cache-Control: s-maxage (Shared Cache)“Wie lange ein Shared Cache zwischen Browser und Ihrem Origin (Varnish, Nginx, ein CDN, das CDN-Cache-Control nicht versteht) die Antwort wiederverwenden darf. Standard 6 Stunden.
Erhält Varnish eine Antwort mit s-maxage: 21600, speichert es die Antwort für 6 Stunden und bedient nachfolgende Anfragen aus eigenem Speicher — ohne Ihren Origin zu treffen (es sei denn, ein expliziter Purge feuert).
CDN-Cache-Control: max-age (nur CDN)
Abschnitt betitelt „CDN-Cache-Control: max-age (nur CDN)“Eine CDN-spezifische Direktive, die Cloudflare, Fastly und Akamai erkennen. Standard deaktiviert (Header wird nicht gesendet).
Der Wert wirkt nur am CDN und nur bei den CDNs, die ihn verstehen. Browser und andere Shared Caches ignorieren den Header.
Verwenden, wenn Sie am CDN und an anderen Shared Caches unterschiedliche Cache-Dauern wollen (z. B. 1 Tag am CDN, 6 Stunden in Varnish).
Wie sie sich kombinieren
Abschnitt betitelt „Wie sie sich kombinieren“Für jede Anfrage handeln die Cache-Schichten unabhängig:
[Browser] ←─ Cache-Control: max-age=0 ↓[CDN] ←─ CDN-Cache-Control: max-age=86400 ↓[Varnish] ←─ Cache-Control: s-maxage=21600 ↓[Origin / P2Lab Cache] ←─ serverTtl=86400 ↓[Shopware-Rendering]Ein typisches “schnell, aber genau”-Setup:
serverTtl: 86400(1 Tag — lang, weil Invalidierung ohnehin purged)max-age: 0(Browser soll immer prüfen)s-maxage: 21600(Varnish bedient 6 Stunden, dann re-fetch)CDN-Cache-Control: 86400(CDN bedient 1 Tag; CDN-Purge bei Deploy)
“Maximale Geschwindigkeit, etwas Staleness akzeptieren”:
serverTtl: 86400max-age: 300(Browser hält 5 Minuten)s-maxage: 86400(Varnish hält 1 Tag; Deploys müssen Purges auslösen)CDN-Cache-Control: 86400
“Immer frisch, keine Staleness”:
serverTtl: 3600max-age: 0s-maxage: 0CDN-Cache-Control: deaktiviert
Sales-Channel-Geltungsbereich
Abschnitt betitelt „Sales-Channel-Geltungsbereich“Alle vier sind pro Sales Channel. Typisch: ein B2B-Channel mit s-maxage: 0 (kein Shared Caching) und ein B2C-Channel mit längeren Dauern.
Und Invalidierung?
Abschnitt betitelt „Und Invalidierung?“Die vier Lebenszeiten sind expiry-basiert. Invalidierung ist event-basiert und läuft unabhängig:
- Ein Produkt-Save mit Smart-Invalidierung purged die betroffenen Einträge aus dem Origin-Cache sofort, unabhängig von
serverTtl. - Ein xkey-Purge an Varnish entfernt die Antwort sofort aus Varnish, unabhängig von
s-maxage. - Der Browser wird nicht gepurged —
max-agewirkt weiterhin. Setzen Siemax-age: 0, wenn Sie keine browsergecachten stalen Seiten tolerieren können. - Das CDN wird nur gepurged, wenn Sie CDN-Purges separat eingerichtet haben (diese Integration liefern wir nicht out of the box).
Per-Route-Überschreibungen
Abschnitt betitelt „Per-Route-Überschreibungen“Das Plugin setzt dieselben Header auf jeder cachefähigen Antwort. Um für eine bestimmte Route zu überschreiben (z. B. niedrigeres s-maxage für eine bestands-sensible Seite), fügen Sie einen Custom-Event-Subscriber hinzu, der die Antwort mutiert.