Schnellkonfiguration

Nach der Installation arbeitet P2Lab Cache mit sicheren Defaults: Filesystem-Backend, Smart-Invalidierung, Browser-Cache deaktiviert, Server-TTL ein Tag. Für die meisten Shops müssen Sie vor dem Go-Live nur eine Handvoll Entscheidungen treffen.

Alle Einstellungen liegen unter Einstellungen → Speed Boost und sind auf vier Tabs verteilt:

• Dashboard — Runtime-Schalter, die Sie am häufigsten ändern (TTLs, cachefähige Routen)
• Core — Invalidierungsmodus, Storage-Backend, Komprimierung
• Reverse Proxy — Varnish-Einstellungen
• Hilfe — Links und Referenz

Jede numerische Einstellung kann pro Sales Channel über den Sales-Channel-Switcher in der Seitenkopfzeile überschrieben werden.

Schritt 1 — Storage-Backend wählen

Öffnen Sie Core → Cache-Speicher und wählen:

• Filesystem (Standard) — keine zusätzliche Infrastruktur. Gut für Single-Server. Cache liegt unter var/cache/ auf der Festplatte.
• Redis — empfohlen für Multi-Server und Cluster. Tragen Sie Redis DSN ein (redis://host:6379) und optional Cache-Namespace (Standard p2lab_cache).
• APCu — schnellste Option für einen Single-Host. Erfordert die PHP-Erweiterung apcu. Nicht für Multi-Server verwenden — APCu ist prozesslokal.

Siehe Storage-Backends für die Trade-offs.

Schritt 2 — Invalidierungsmodus wählen

Öffnen Sie Core → Einstellungen → Cache-Invalidierungsmodus:

• Manual — invalidiert nie automatisch. Nur verwenden, wenn Sie Purges selbst über CLI / REST-API auslösen.
• Basic — cacht Produktseiten, invalidiert bei Produktänderungen.
• Extended — erweitert Basic um kaskadierende Invalidierung für Kategorien und Listings.
• Precise — cacht alles, invalidiert Produkte + Listings, keine Kategorie-Kaskade.
• Smart (empfohlen, Standard) — prüft, welche Felder sich tatsächlich geändert haben, und löscht nur die betroffenen Einträge.

Siehe Invalidierungsmodi für die vollständige Aufschlüsselung.

Schritt 3 — Cachefähige Routen bestätigen

Öffnen Sie Dashboard → Cachefähige Routen. Jede Route hat einen eigenen Schalter:

• Startseite cachen (an)
• Navigationsseiten cachen (an) — Kategorie / Listing
• Navigationsseiten (AJAX) cachen (an) — Listing-Paginierung + Filter
• Navigationsfilter (AJAX) cachen (an) — Filter-Aggregationen
• Produktseiten cachen (an)
• CMS-Seiten cachen (an)
• Async Buybox (AJAX) cachen (aus, Standard) — nur einschalten, wenn Ihr Storefront die Async-Buybox nutzt und die Antwort nicht kundenspezifisch ist

Achtung

Async-Buybox-Antworten enthalten Preise und Rule-basierte Modifikatoren. Aktivieren Sie Async Buybox cachen nur, wenn Ihr Storefront sie nicht pro Kunde personalisiert (B2B, kundenspezifische Preise usw.).

Schritt 4 — Über Browser- / CDN-Caching entscheiden

Öffnen Sie Dashboard → Konfiguration:

• Cache-TTL (Standard: 1 Tag) — wie lange Einträge im Backend leben.
• max-age (Standard: 0 — kein Browser-Cache) — wird als Cache-Control: max-age=… an Browser gesendet. Belassen Sie 0, wenn jeder Besucher revalidieren soll (der Cache liefert die Antwort trotzdem schnell).
• s-maxage (Standard: 6 Stunden) — wird als Cache-Control: s-maxage=… an Shared Caches (CDN, Varnish) gesendet.
• CDN-Cache-Control (Standard: deaktiviert) — separater Header für Cloudflare, Fastly, Akamai. Verwenden, wenn das CDN eine andere Cache-Dauer haben soll als andere Shared Caches.

Siehe Cache-Control-Header für die Semantik.

Schritt 5 — Komprimierung (optional)

Öffnen Sie Core → Cache-Speicher → Cache-Komprimierung aktivieren (Standard: an, Level 6).

Die Komprimierung wirkt auf die im Backend gespeicherten Daten — sie beeinflusst nicht den HTTP-Transfer. Typische Einsparungen sind 40–60 % von Speicher, gegen einen geringen CPU-Aufwand beim Schreiben und Lesen. Stufen:

• 1 — am schnellsten, kleinste Ratio
• 3 — schnell
• 6 — ausgewogen (empfohlen)
• 9 — kleinste, langsamste

Schritt 6 — Reverse Proxy (nur wenn Sie Varnish betreiben)

Öffnen Sie Reverse Proxy → Einstellungen:

1. Varnish-Cache aktivieren (an Standard — wirkt nur, wenn Shopware selbst auf Reverse Proxy konfiguriert ist).
2. xkey-Invalidierungsstrategie — Default / Precise / Smart. Wählen Sie Smart für einen typischen Shop.
3. (Optional) xkey-Header aufteilen — falls Varnish lange xkey-Header ablehnt, auf mehrere HTTP-Header aufteilen.
4. (Optional) xkey-Tags kürzen — lange Tag-Namen per MD5 hashen, um Header-Größenlimits einzuhalten.
5. (Optional) xkey-Tag-Blocklist — Tag-Kategorien (Theme, Übersetzungen, Snippets usw.) ausschließen, die keine Purges auslösen sollen.

Siehe Reverse Proxy (Varnish) für das volle Bild.

Speichern und neu laden

Klicken Sie oben rechts auf Speichern. Die neuen Einstellungen wirken sofort für neue Anfragen. Bestehende Cache-Einträge bleiben gültig, bis ihre TTL abläuft oder eine Invalidierung feuert.

Weiter: Verifizieren, dass es funktioniert

Weiter zu Erster Cache-Treffer, um zu bestätigen, dass der Cache wirklich Seiten ausliefert.