Shopware 6 CDN: what to cache and what to bypass

A CDN in front of Shopware 6 pays off in two places: static files such as theme CSS, JavaScript and product images, which can stay at the edge for a long time, and HTML pages for guests in Shopware's default state, which need short lifetimes and a purge plan. Everything personal, from cart and checkout to account pages, logged-in customers and guests who switched currency, has to go straight to your Shopware server. This guide shows where to draw that line, how to purge and how to test it.

Tuning the shop itself (HTTP cache, workers, OPcache, imports) is covered in our Shopware 6 performance guide. Here we focus on the layer in front of it.

Asset CDN or full-site CDN

Asset CDN. Shopware can generate the URLs of public files on a separate hostname. In the filesystem configuration you set a url for the public filesystem, and the theme, asset and sitemap filesystems inherit it by default. This only changes the URLs in the page. The CDN still pulls the files from your server or bucket, and every HTML request still reaches Shopware.

Full-site CDN. The whole domain runs through the CDN, set up via nameservers or DNS depending on the provider. The edge sees every request, including HTML, and can filter bad traffic before it reaches your server. The gain is bigger, and so is the responsibility: the CDN has to know exactly which responses it may store.

Static files are the easy part

Compiled theme files suit long edge lifetimes: on every compile, Shopware writes CSS and JavaScript into a new folder under theme/ named with a fresh hash, so the URLs change. Product images and thumbnails change rarely and often make up most of the bytes on a page. Our guide on optimizing images for the web covers formats and sizing.

The exception is a file replaced under the same URL, such as a CMS image with an unchanged file name. Purge that URL when you swap it.

Which Shopware pages are safe to cache

Shopware does not cache one page for everyone. According to the HTTP cache documentation, it sets a sw-cache-hash cookie as soon as a visitor's state differs from the default, which is: no logged-in customer, the default currency and an empty cart. The hash encodes login state, currency, tax state and the cache-relevant rules that matched, and Shopware keeps a separate cache variant per hash. Visitors in the default state share one variant.

A CDN that keys its cache on the URL alone knows nothing about these variants. So the rule for HTML is: cache only what a default-state guest sees, and send every request with sw-cache-hash to Shopware.

Customer group prices and other rule-driven content end up in the hash too, so such visitors must never get the cached default page.

Respect Cache-Control and cookies

The edge should not guess what is cacheable, because Shopware already says so. With the HTTP cache enabled, cacheable storefront responses carry a shared-cache lifetime (s-maxage); the reverse proxy docs show Cache-Control: public, s-maxage=7200 as an example. Responses for logged-in customers or filled carts don't get those headers.

Whatever CDN you use, two rules apply:

1. Store only what Shopware marks as public. Never store responses with private, no-cache or no-store, and never store a response that sets a cookie. A blanket "cache everything" rule overrides Shopware's decisions and is how one customer ends up seeing another customer's cart.
2. Bypass the edge cache for requests with sw-cache-hash, or include that cookie in the cache key. If the CDN ignores it, a guest who switched currency may get the default-currency page from the edge. Worse, their variant could be stored and served to everyone else.

To change lifetimes, adjust them in Shopware rather than at the edge. Newer versions offer HTTP caching policies with directives such as s_maxage and stale_while_revalidate per area or route. The docs mark this as experimental and planned as the default for Shopware 6.8, so check your version.

Varnish, Fastly and a generic CDN

Shopware officially supports two reverse proxies: Varnish with the XKey module and Fastly. Both are wired into its invalidation: cached responses carry tags (surrogate keys) for the data they were built from, and when you edit a product, Shopware sends the proxy an invalidation request for exactly those tags. Since Shopware 6.6 you configure this under shopware.http_cache.reverse_proxy. The reverse HTTP cache docs describe the full setup.

A generic CDN is not part of that loop. Shopware's tag invalidation reaches its own cache and a configured reverse proxy, but not an edge network it doesn't know about. A cached category page at the edge stays there until its lifetime runs out or you purge it.

A tag-based proxy gives you precise invalidation for large, fast-changing catalogs, but it is one more system to run. A generic full-site CDN is simpler to add and brings edge delivery and protection, but HTML freshness depends on short lifetimes and your own purges. Some shops combine both.

A purge strategy without tags

Short HTML lifetimes. Keep guest HTML at the edge for minutes rather than hours, while theme files and images stay much longer. An outdated edge copy then disappears after at most one lifetime, even without a purge. The built-in Shopware cache absorbs the extra misses.

URL purges after bigger changes. When a sale starts, prices change across a category or you edit the navigation, purge the affected URLs. Changes that appear on every page, such as the main menu, the footer or a recompiled theme, justify a whole-domain purge, ideally outside peak hours.

Purges from your scripts. Most CDNs, fast.site included, offer a purge API. Let your ERP or price import end with a call that purges the URLs it touched, and let your deployment pipeline purge after theme:compile.

Real client IPs and trusted proxies

Behind a CDN, every request reaches Shopware from an edge server. The visitor's real IP travels in a header such as X-Forwarded-For, which Symfony only reads from proxies you trust via SYMFONY_TRUSTED_PROXIES in your .env (the variable name since Shopware 6.6). If you chain a CDN and Varnish, trust both hops.

This matters beyond your logs. Payment and fraud plugins often check the client IP, and Shopware's rate limiters for login, password reset and the contact form get less precise when all requests seem to come from a few addresses.

How to test your Shopware CDN setup

1. Guest request, twice. The second request should come from the edge:

curl -sI https://shop.example.com/some-category/ | grep -iE 'cache-control|fs-cache|age|set-cookie'
curl -sI https://shop.example.com/some-category/ | grep -iE 'cache-control|fs-cache|age|set-cookie'

On fast.site, look for fs-cache: HIT and a growing fs-cache-age (see checking the cache). Other CDNs usually send an Age header and their own status header. If the page never becomes a HIT, compare its Cache-Control header with the rules above.

2. Personal routes. Check /checkout/cart and /account/login the same way. They must never show a HIT.

3. A complete checkout. In a private window, add a product, check that the cart counter updates, and complete checkout with a test payment method. Cancel the test order afterwards.

4. Logged-in customer. Log in with a test account, ideally one with customer group prices. Pages must show that customer's prices, and the guest view must return after logout.

5. Currency switch. As a guest, switch to a second currency and browse a few categories. Then open the same pages in a fresh private window: they must show the default currency. Repeat in the other order. This catches a CDN that ignores sw-cache-hash.

With several sales channels or languages, repeat steps 1 and 5 per domain. For speed, compare real-user data and a lab run on corewebvitals.page before and after, as described in measuring website speed properly.

How fast.site helps

fast.site is a full-site edge layer in front of your existing Shopware hosting. You keep your host, add the domain in the dashboard and point its nameservers to fast.site; our nameserver checklist helps you keep DNS records and email intact.

Fast Edge Cache™ respects the Cache-Control headers your shop sends. Private and dynamic responses such as cart, checkout and logged-in sessions show fs-cache: BYPASS, so you can run the test plan above directly. fast.site does not receive Shopware's tag invalidations. Instead, you purge individual URLs or the whole domain in the dashboard, with a purge log, or via the API from your import and deployment scripts. A cache warmer keeps important pages primed.

Images are converted to WebP on the fly (AVIF depending on your plan), text files are compressed with Brotli, and Layer 7 DDoS detection, rate limiting and bot rulesets filter traffic at the edge. The Shopware page has the details.

Measure the result on your own shop, with the same pages before and after. You can start with a free 7-day trial, no credit card needed.

FAQ

Does Shopware 6 have a built-in CDN?

No. Shopware has a built-in HTTP cache on your server, and you can set a separate URL for public files so they load from a CDN hostname. As reverse proxies, Shopware officially integrates Varnish with XKey and Fastly.

Can I cache Shopware HTML pages on a CDN?

Yes, for guests in the default state: not logged in, default currency, empty cart. The CDN must respect Shopware's Cache-Control headers, bypass requests with the sw-cache-hash cookie and never cache cart, checkout or account pages.

Why does the cart or the price look wrong after adding a CDN?

Usually the edge caches something personal: a response that sets a cookie, a page requested with sw-cache-hash, or a checkout route caught by a "cache everything" rule. Remove the rule, purge the domain and repeat the tests.

Do I still need Shopware's HTTP cache behind a CDN?

Yes. Every edge miss and every request with a sw-cache-hash cookie lands on your server. The built-in cache keeps those requests fast, and short edge lifetimes only work well with a quick origin.

How do I clear the CDN cache after changes in Shopware?

Shopware's bin/console cache:clear and cache:clear:http don't reach a generic CDN. Purge the affected URLs or the whole domain in the CDN's dashboard, or via its API from the script that made the change.