Shopware 6 performance: HTTP cache, CDN and common pitfalls

A slow Shopware 6 storefront is rarely a mystery. In most cases the HTTP cache is off or constantly invalidated, background work runs in the wrong place, or the server is doing expensive work on every request that it could skip. This guide explains how the Shopware 6 HTTP cache works, how to check it, where a CDN helps, and the most common configuration mistakes.

How the Shopware 6 HTTP cache works

Shopware 6 has a built-in full-page cache for the storefront. When it's enabled, the first request for a page (say a category or product detail page) is rendered by PHP, stored, and later requests for the same page get the stored copy without running the whole application again. That is the single biggest lever for storefront speed.

A few things matter for how well it works:

• It must be switched on. The cache is controlled by the environment variable SHOPWARE_HTTP_CACHE_ENABLED=1, usually set in .env.local.
• Storage. By default the cache lives on the filesystem under var/cache. That's fine for a single server. With several app servers, the Shopware caching docs recommend a shared cache such as Redis.
• Variants per context. A page can look different depending on whether the visitor is logged in, the currency, the tax state or which price rules apply. Shopware sums this up in the sw-cache-hash cookie and stores a separate variant per hash, so one customer never sees another customer's prices. Visitors in the default state (not logged in, default currency, empty cart) share the same cached pages.
• Tag-based invalidation. Cached responses carry tags for the data they were built from. When you change a product, Shopware drops the cached pages tagged with it instead of wiping everything. List-type routes such as product listings, category listings and search results are not tagged with every entity they return and rely on their cache lifetime instead, so a change can take a while to show up there.

Built-in cache vs. reverse proxy

For larger shops, Shopware supports an external reverse proxy, namely Varnish with the XKey module or Fastly. The proxy stores the pages and Shopware sends it invalidation requests with the affected tags. Since Shopware 6.6 you configure this under shopware.http_cache.reverse_proxy (older versions use storefront.reverse_proxy) and set SYMFONY_TRUSTED_PROXIES so the app sees real client IPs. The reverse HTTP cache docs have the full setup.

A reverse proxy takes load off PHP entirely for cached hits, which matters in peak hours. It is also one more component to run and monitor. For many small and mid-sized shops, the built-in cache with Redis is enough.

Check whether the cache is working

Before changing anything, find out what's actually happening. Open a category page twice in a private window and compare the response times in your browser's network tab. A working cache shows a clear drop on the second request. On the command line:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/some-category/
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://shop.example.com/some-category/
curl -sI https://shop.example.com/some-category/ | grep -i cache-control

If both requests are equally slow, the cache is either disabled, bypassed by a cookie, or invalidated between the two requests. Also check the Cache-Control header. It tells any proxy or CDN in front of Shopware whether it may store the page.

For a structured before-and-after comparison, TTFB is the metric to watch on the server side. Our guide on reducing TTFB covers the server and application side in more depth.

Common configuration pitfalls

These are the issues that most often explain a sluggish Shopware 6 shop.

Running in dev mode or with debug on

APP_ENV=dev enables the profiler and debugging features that make every request slower. Production shops need APP_ENV=prod. Also set the log level to error or similar in production, since verbose logging writes on every request.

The admin worker handles background jobs

By default, Shopware can process queued messages (indexing, emails, imports) through the administration while an admin user has the backend open. That's convenient for development, but in production it makes background work unpredictable and puts load on the web server. The message queue docs say it plainly: in production, process the queue via the CLI. Set shopware.admin_worker.enable_admin_worker: false in config/packages/shopware.yaml and run bin/console messenger:consume async as a background process kept alive by systemd or supervisor, plus bin/console scheduled-task:run for scheduled tasks.

Cache invalidation storms

ERP syncs, stock updates and price imports touch many products at once. Each change invalidates cached pages, so an import that runs every few minutes can keep your cache almost permanently empty. Options: batch imports into fewer runs, only write fields that actually changed, and use delayed invalidation. Shopware then collects the tags to invalidate and processes them later in a background task. By default that list lives in the database; the performance tweaks docs recommend Redis as storage wherever you can use it.

Extensions that break caching

Plugins can set cookies, add personalized blocks or change the context on every request. Any of these can lead to a separate cache variant per visitor, which means effectively no cache. If your cache hit rate collapsed after installing an extension, test with it disabled on a staging copy.

MySQL search on a large catalog

For larger catalogs, product search and filtered listings are expensive in MySQL. Shopware supports Elasticsearch or OpenSearch for storefront search and listings. Search results are typically not full-page cached, so this directly affects the pages where users type and filter.

PHP and OPcache

Make sure OPcache is enabled and sized for Shopware's codebase. In production, opcache.validate_timestamps=0 avoids file checks on every request (you then need to reset OPcache on deploy). Use a current PHP version supported by your Shopware release.

Heavy images and theme assets

Product images straight from the camera, missing thumbnails or huge hero banners hurt the Largest Contentful Paint. Let Shopware generate thumbnails, upload images at sensible dimensions and consider modern formats. Our guide on optimizing images for the web covers the details.

Where a CDN helps (and where it doesn't)

A CDN sits between your visitors and your Shopware server and serves content from locations closer to them.

What a CDN does not fix: slow uncached requests. If checkout takes several seconds because of a slow payment plugin or an overloaded database, the CDN passes that time straight through. Fix the origin first, then add the edge layer.

A sensible order of work

1. Set APP_ENV=prod, reduce logging, check OPcache.
2. Enable the HTTP cache and confirm it works for guests.
3. Move background jobs to CLI workers, disable the admin worker.
4. Tame imports so they don't flush the cache all the time.
5. Add Redis (and, for large shops, OpenSearch) where the load requires it.
6. Optimize images and theme assets.
7. Put an edge layer in front for static assets, guest pages and protection.

Measure after each step, ideally with the same pages and tools, so you know what actually made a difference. If you run WooCommerce as well, the principles are similar: see speeding up WooCommerce without breaking checkout.

How fast.site helps

fast.site sits in front of your existing Shopware hosting. You keep your host and your Shopware setup, add the domain in the dashboard and point your domain's nameservers to fast.site.

Fast Edge Cache™ stores public responses at the edge. Expiry follows the Cache-Control headers your shop sends or rules you set yourself, and you can check every response via the fs-cache header (HIT, MISS or BYPASS). Cart, checkout, account and other session-based pages bypass the cache, so orders keep working as usual. After larger catalog changes you can purge URLs in the dashboard or via API, and the cache warmer keeps important pages primed.

On top of that, images are converted to WebP on the fly for supporting browsers (AVIF depending on your plan), text assets are compressed with Brotli, and Layer 7 DDoS detection, rate limiting and bot rulesets filter traffic before it reaches your server. The Shopware page and the Shopware integration article show the setup in detail.

The honest test is your own shop: start a free 7-day trial, no credit card needed, and compare TTFB and Core Web Vitals before and after.

FAQ

How do I enable the HTTP cache in Shopware 6?

Set SHOPWARE_HTTP_CACHE_ENABLED=1 in your .env.local and clear the cache afterwards. Make sure the shop runs with APP_ENV=prod. Then open a category page twice as a guest and confirm the second request is noticeably faster.

Why is my Shopware shop slow even with the HTTP cache on?

Common reasons are frequent invalidation by imports, extensions that set cookies or personalize pages, and slow uncached pages such as search, cart and checkout. Check whether guest pages are actually served from cache, then look at what runs on the uncached requests.

Do I need Varnish for Shopware 6?

Not necessarily. The built-in cache is enough for many shops, especially with Redis as storage. Varnish or another reverse proxy pays off when you have several app servers or a lot of traffic, but it adds infrastructure you need to operate.

Can I use a CDN with Shopware 6?

Yes. Static assets and images are easy to serve from a CDN. Guest HTML pages can be cached too, as long as the CDN respects Shopware's cache headers, bypasses cart, checkout and account pages, and you have a way to purge after changes.

How do I clear the Shopware cache?

In self-hosted shops, open Settings > System > Caches & Indexes in the administration and use Clear cache, or run bin/console cache:clear on the command line. If you use a reverse proxy, bin/console cache:clear:http (available since Shopware 6.6.10) clears that cache. Clearing everything often means the next visitors hit a cold cache, so do it outside peak hours.