Quick configuration

After installation, P2Lab Cache works with safe defaults: Filesystem backend, Smart invalidation, browser cache disabled, server-side TTL of one day. For most stores you only need to confirm a handful of choices before going live.

All settings live under Settings → Speed Boost and are split across four tabs:

• Dashboard — runtime knobs you change most often (TTLs, cacheable routes)
• Core — invalidation mode, storage backend, compression
• Reverse proxy — Varnish settings
• Help — links and reference content

Every numeric setting can be overridden per sales channel from the standard Shopware sales-channel switcher in the page header.

Step 1 — Pick a storage backend

Open Core → Cache Storage and choose:

• Filesystem (default) — no extra infrastructure. Good for single-server setups. Cache lives under var/cache/ on disk.
• Redis — recommended for multi-server setups and clusters. Fill in Redis DSN (redis://host:6379) and optionally Cache namespace (default p2lab_cache).
• APCu — fastest option for a single host. Requires the apcu PHP extension. Do not use this for multi-server deployments — APCu is process-local.

See Storage backends for the trade-offs.

Step 2 — Pick an invalidation mode

Open Core → Settings → Cache Invalidation Mode:

• Manual — never invalidates automatically. Use only if you trigger purges via the CLI or REST API yourself.
• Basic — caches product pages, invalidates on product changes.
• Extended — extends Basic with cascading invalidation for categories and listings.
• Precise — caches everything, invalidates products + listings, no category cascade.
• Smart (recommended, default) — inspects which fields actually changed and purges only the affected entries.

See Invalidation modes for the full breakdown.

Step 3 — Confirm cacheable routes

Open Dashboard → Cacheable Routes. Each route can be toggled independently:

• Cache Home Page (on)
• Cache Navigation Pages (on) — category / listing
• Cache Navigation Pages (AJAX) (on) — listing pagination + filter
• Cache Navigation Filters (AJAX) (on) — filter aggregations
• Cache Product Pages (on)
• Cache CMS Pages (on)
• Cache Async Buybox (AJAX) (off by default) — turn on only if your storefront uses async buybox and the response does not depend on the customer

Caution

Async buybox responses include pricing and rule-based modifiers. Only enable Cache Async Buybox if your storefront does not personalise it per customer (B2B, customer-specific prices, etc.).

Step 4 — Decide on browser / CDN caching

Open Dashboard → Configuration:

• Cache TTL (default: 1 day) — how long entries live in the backend.
• max-age (default: 0 — no browser cache) — sent as Cache-Control: max-age=… to browsers. Leave at 0 if you want every visitor to re-validate against your origin (the cache still serves the response fast).
• s-maxage (default: 6 hours) — sent as Cache-Control: s-maxage=… to shared caches (CDN, Varnish).
• CDN-Cache-Control (default: disabled) — separate header recognised by Cloudflare, Fastly, Akamai. Use when you want the CDN to cache for a different duration than other shared caches.

See Cache-Control headers for the response-header semantics.

Step 5 — Compression (optional)

Open Core → Cache Storage → Enable Cache Compression (default: on, level 6).

Compression applies to the data stored in your backend — it does not affect HTTP transfer. Typical savings are 40–60% of disk or memory, in exchange for a small CPU cost on cache write and read. Levels:

• 1 — fastest, lowest ratio
• 3 — fast
• 6 — balanced (recommended)
• 9 — smallest, slowest

Step 6 — Reverse proxy (only if you run Varnish)

Open Reverse proxy → Settings:

1. Enable Varnish Cache (on by default — applies only if Shopware itself is configured to use a reverse proxy).
2. Xkey Invalidation Strategy — Default / Precise / Smart. Pick Smart if you have a typical store.
3. (Optional) Split xkey Headers — if Varnish rejects long xkey headers, split into multiple HTTP headers.
4. (Optional) Shorten xkey Tags — MD5-hash long tag names to keep within header size limits.
5. (Optional) Xkey Tag Blocklist — exclude tag categories (theme, translations, snippets, etc.) that you do not want to trigger purges.

See Reverse proxy (Varnish) for the full picture.

Save and reload

Hit Save in the top-right corner. The new settings take effect immediately for new requests. Existing cache entries stay valid until their TTL expires or an invalidation fires.

Next: verify it works

Continue to First cache hit to confirm the cache is actually serving pages.