In ecommerce, every millisecond between a click and a page load is a millisecond your shopper can change their mind. Shopware just rolled out the biggest change to its caching architecture in years rolling out gradually between version 6.7.3 and the upcoming 6.8 release. The short version: pages load faster, more shoppers benefit from caching, and headless storefronts finally get proper API caching too.
This article breaks down exactly what's changing, why it matters for your store's speed and conversion rate, and how Mavenbird configures it correctly including the parts that can break things if you're not careful.
What is Caching, and Why Does It Matter?
Without caching, every single visitor to your store forces Shopware to "cook from scratch" boot the application, query the database, and build the page from raw ingredients. With caching, popular dishes are pre-made and sitting ready to serve. The kitchen (your server) handles far more customers without breaking a sweat, and everyone eats faster.
To be precise: this isn't about object caching (like Redis storing calculation results behind the scenes). This is the HTTP Cache the layer that stores a fully rendered page or API response, ready to serve instantly without Shopware doing any work at all.
That's roughly a 10x speed difference and beyond raw speed, a well-cached store can also serve dramatically more concurrent visitors without needing more server resources. The catch, until now, was that Shopware's cache had a serious efficiency problem.
The Problem: Too Many "Versions" of Every Page
Imagine a single product page. It can look different depending on the visitor's language, their currency, whether tax is shown net or gross, and which Rule Builder rules are currently active for them is it Sunday? Are they in a specific customer group? Each of these factors creates a different "version" of the page that needs its own cache entry.
Because cache keys included every rule on the site, visitors rarely shared the same cached version so the cache was rebuilt constantly instead of reused.
The moment a customer logged in or added something to their cart, Shopware switched off caching for them entirely exactly the visitors most likely to convert.
The Store API the backbone of headless and app-based storefronts was largely uncached, leaving a major performance gap for modern frontend setups.
What's Changing The Big Picture
Shopware's engineering team rebuilt the caching system from the ground up to fix all three problems at once. Here's the high-level summary, before we get into the technical detail:
Instead of hashing every rule into every cache key, Shopware now only includes rules actually relevant to the page being viewed. A "Sunday Sale" rule no longer affects the cache key of your Contact Us page.
Headless and app-based storefronts can now benefit from caching too including search requests, by converting them into cacheable GET requests behind the scenes.
The default has flipped. Logged-in sessions and filled carts are now cached automatically instead of being excluded from caching the moment someone logs in.
A new policy system in shopware.yaml gives fine-grained control over Cache-Control headers no more fighting hardcoded values to tune caching behaviour for your specific store.
Rollout Timeline Where Things Stand
This is a major architectural change, so Shopware is rolling it out gradually rather than all at once:
The smarter, rule-relevant cache key logic becomes available, hidden behind the CACHE_CONTEXT_HASH_RULES_OPTIMIZATION feature flag.
The complete new caching behaviour Store API caching, logged-in user caching, and configurable policies becomes available behind the CACHE_REWORK feature flag.
The complete rework is targeted for this release (expected shortly), with the feature flag still required to opt in.
The feature flag is removed and the new caching behaviour becomes the default for everyone. This is also when breaking changes for older extensions take full effect.
The Technical Breakdown How It Actually Works
If you're a merchant, the next sections are useful context. If you're a developer or just want the full picture, here's exactly what's happening under the hood. Click each section to expand it.
For headless and app-based storefronts, this is the headline change. To benefit fully, your frontend needs to send the current cache hash along with each request. Shopware returns this as both a response header and a cookie, labelled sw-cache-hash.
If your frontend lets the browser handle cookies automatically (the typical case), you get this benefit with zero code changes. If you handle headers manually instead, just make sure you echo the sw-cache-hash value back on subsequent requests. Note: if both the header and cookie are present, the header value takes priority.
The POST-to-GET trick: Most Store API endpoints (like product search) use POST requests, because filter and sort criteria are too large for a URL. But standard HTTP caches only cache GET requests. Shopware solves this by letting you pass criteria as a compressed string in a GET request, using a new ?_criteria parameter formatted as base64url(gzip(json_encode(criteria))). If you use Shopware's official JS API client, this happens automatically.
Previously, caching was "opt-in" for logged-in users and filled carts it was switched off by default the moment someone logged in or added a product to their cart. This default has now flipped to "opt-out."
Starting with 6.8, logged-in users and filled carts are cached automatically. If a specific page genuinely needs to stay dynamic and uncached for these visitors for example, a heavily personalised dashboard developers create a Listener on the HttpCacheCookieEvent to explicitly disable caching for that route.
The recommended approach for most stores: keep the base page cached for speed, then load any genuinely dynamic content (like a personalised greeting or loyalty points) asynchronously via JavaScript after the page loads. You get the speed of caching and the personalisation you need, without compromise.
Shopware now offers a standardised way to define Cache-Control headers through policies set in your shopware.yaml configuration file no more fighting hardcoded values buried in core code.
A policy lets you configure directives including public, private, no_cache, no_store, must_revalidate, max_age, s_maxage, stale_while_revalidate, and stale_if_error. You can set a default policy for cacheable and non-cacheable responses, and override it at the individual route level.
# Illustrative shopware.yaml cache policy shopware: cache: policy: default: max_age: 7200 s_maxage: 86400 stale_while_revalidate: 600
Why this matters: it lets you instruct your reverse proxy (Varnish, Fastly) to hold content longer (s_maxage) while keeping browser-side caching shorter-lived. This is ideal if you only update product data daily or weekly you can safely extend caching periods and serve pages faster for longer.
This is the fix for the "1 quadrillion variations" problem. A new extension point called ResolveCacheRelevantRuleIdsExtension means Shopware now limits the cache hash to only the rules actually relevant to the current page area for example, only Product rules affect Product page caching.
Previously, an active "Sunday Sale" rule changed the cache hash for every single page on the site, including pages with zero relation to products, like your Contact Us page. That's now fixed at the architecture level.
The result: a measurably smaller cache (fewer stored variations of the same page) and a much higher hit rate, since irrelevant rules no longer fragment the cache unnecessarily.
If your store sits behind Varnish or Fastly (common for high-traffic stores), this update directly benefits you. Shopware now uses standard Cache-Control and Vary headers, removing the custom hashing logic that previously made integrating external caching layers difficult.
A simplified Varnish configuration is now possible, relying on standard cookie parsing instead of bespoke logic meaning broader compatibility with other reverse proxy caches beyond just Varnish and Fastly going forward.
Before vs. After At a Glance
| Behaviour | Before (Current Default) | After (CACHE_REWORK / 6.8) |
|---|---|---|
| Cache key includes | Every active rule, on every page | ✓ Only rules relevant to that page area |
| Logged-in users | ✗ Cache disabled (opt-in) | ✓ Cached by default (opt-out) |
| Filled cart | ✗ Cache disabled | ✓ Cached by default |
| Store API (headless) | ✗ Largely uncached | ✓ Cacheable, incl. POST search via GET |
| Cache-Control headers | Hardcoded values | ✓ Configurable policies in shopware.yaml |
| Reverse proxy support | Custom hashing, harder to integrate | ✓ Standard headers, simplified Varnish config |
| Typical cache hit rate | Low fragmented by irrelevant rules | ✓ Significantly higher |
We review your installed plugins and custom code for anything that renders dynamic, user-specific content directly in HTML the main source of breakage before enabling the new caching behaviour.
We enable and test CACHE_REWORK in a staging environment first, validating real user flows login, cart, checkout before promoting the change to your live store.
We configure shopware.yaml cache policies tuned to your store's actual update frequency longer caching for stable content, shorter for frequently changing pages and campaigns.
For high-traffic stores, we set up and tune reverse proxy caching using the new simplified configuration maximising your server capacity without sacrificing freshness of content.
If you run a custom React, Vue, or Next.js storefront on Shopware's Store API, we validate your client correctly handles the sw-cache-hash cookie and header for maximum caching benefit.
We benchmark your store's response times and cache hit rates before and after the rollout, so you have clear, measurable proof of the performance improvement delivered.
Frequently Asked Questions
What is the new Shopware caching system?
It's a rebuilt HTTP caching architecture rolling out between Shopware 6.7.3 and 6.8. It dramatically reduces the number of cache variations a page needs by only including page-relevant rules in the cache key, enables caching for the Store API used by headless storefronts, and flips the default so logged-in users and filled carts are cached automatically instead of bypassing the cache.
What exactly is a "cache permutation"?
A cache permutation is one unique variation of a cached page, determined by factors like language, currency, tax display, and active Rule Builder rules. Previously, every active rule on your store affected the cache key for every page even pages unrelated to that rule creating an enormous, inefficient number of possible variations and a low cache hit rate.
When can I start using the new caching system?
Permutation optimisation is available starting in Shopware 6.7.3.x and 6.7.4.x. The full feature set, behind the CACHE_REWORK feature flag, is available from 6.7.5.0. The complete rework is targeted for 6.7.6.0, and the new behaviour becomes the default with the flag removed in Shopware 6.8.
Will this break my existing Shopware extensions?
It can, specifically for extensions that render dynamic, user-specific content (like a personalised "Hello, [Name]" message) directly in the page's PHP/HTML output. That content could now be cached and mistakenly shown to other visitors. The fix is to move such content to JavaScript-based loading, or to explicitly opt that specific route out of caching. All changes are backward compatible your extension can support both old and new caching behaviour simultaneously without separate code paths. Mavenbird audits for this before enabling the new behaviour on a live store.
Do I need to change my headless storefront's code?
If your frontend automatically handles cookies (the typical browser behaviour), no code changes are required the sw-cache-hash cookie is sent and read automatically. If you manage requests manually, ensure you echo back the sw-cache-hash value as a header on subsequent requests. If you use Shopware's official JS API client, POST search requests are automatically converted to cacheable GET requests for you.
How does Mavenbird help enable this safely on my store?
Mavenbird audits your installed extensions and custom code for caching compatibility, tests the CACHE_REWORK feature flag thoroughly in a staging environment, configures Cache-Control policies tailored to your store's content update frequency, sets up or tunes Varnish/Fastly reverse proxy integration, and validates headless Store API caching if you run a custom frontend. We also provide before/after performance benchmarks so you can see the measurable impact.
Want this configured correctly on your Shopware store?
Mavenbird audits your extensions, safely enables the new caching behaviour, and benchmarks the performance improvement so your store gets faster without anything breaking.
