Introduction

P2Lab Cache is a Shopware 6 plugin that stores complete HTML responses for cacheable storefront routes and serves them on subsequent hits. Instead of rebuilding the home page, a product page or a category listing for every visitor, your shop returns the pre-built response in milliseconds — dropping server load and improving the perceived page-load time.

The plugin is sold in the Shopware store as Speed Boost but is identified internally by its technical name P2LabCache.

What it does

• Full-page cache — captures and serves Shopware’s HTML output for home, navigation, product detail, CMS and async buybox routes
• Smart field-level invalidation — when a product or category changes, only the cache entries that depended on the changed field are purged
• Three storage backends — Filesystem (default), Redis (clustered), APCu (in-memory)
• Internal compression — optional gzip of stored payloads to save disk or memory
• Reverse proxy integration — Varnish purge over xkey with three strategies (Default / Precise / Smart), tag blocklist, splitting and shortening
• Cache warming — queue-driven warmup that pre-populates every cacheable URL after deployments or full clears
• Admin module — dashboard with statistics, quick-clear, per-type charts, invalidation log, reverse-proxy log and warmup history
• REST API + CLI — automate clearing and warming from deployment scripts

Every cached page tracks its original size, cached size, generation time and cache-hit time, so the dashboard can show real numbers — total space saved, average HIT speed, etc.

Who it is for

• Shop owners running mid-to-large Shopware 6 catalogues who hit page-build latency under traffic spikes
• DevOps teams running Shopware behind Varnish who want field-level purges instead of broad invalidation
• Agencies standardising a caching configuration across multiple stores

What you need

• Shopware 6.6 (the plugin’s composer.json constrains shopware/core to >=6.6 <6.7; a 6.7 build is shipped separately)
• A running async message worker (bin/console messenger:consume async) — required for cache warming and a few invalidation paths
• Depending on the backend you pick:
  • Filesystem — disk space under var/cache/ (or wherever your Symfony cache directory lives)
  • Redis — a reachable Redis instance and a DSN like redis://host:6379
  • APCu — the apcu PHP extension installed and enabled (single-server only)
• (Optional) Varnish with the xkey vmod loaded if you want reverse-proxy purges

Note

Varnish integration uses the standard Shopware reverse-proxy mechanism — you still configure Varnish itself the way the Shopware documentation describes. P2Lab Cache only enhances how purge tags (xkey) are computed and sent.

How it differs from Shopware’s built-in HTTP cache

Shopware 6 ships with a Symfony HttpCache that already stores responses and invalidates them by tag. P2Lab Cache replaces the default cache store with its own implementation and adds:

• A Smart invalidation mode that inspects which entity fields actually changed and maps them to a minimal tag set
• Compression of the stored payload (Shopware stores raw)
• Statistics per cache type — count, size, space saved, average HIT vs MISS time
• A per-type clear flow (clear all product pages, all listings, all CMS, …) instead of all-or-nothing
• Cache warming driven by the message queue
• A Varnish purge layer with field-aware tag generation, blocklist and header splitting

If you already use Varnish or a CDN, you keep those — P2Lab Cache layers on top.

Next steps

• Install the plugin
• Run the quick configuration
• Verify your first cache hit