Shopware 6 Cache: HTTP Cache Optimization & Performance

Caching is one of the most important performance factors in Shopware 6. By caching content that has already been calculated, database queries, PHP processes, and server load are significantly reduced. As part of holistic Shopware 6 performance optimization this improves load times, Core Web Vitals and the scalability of the shop considerably.

Introduction to Shopware Cache Optimization

Why Is Caching Important for Shopware?

Caching is one of the most important performance mechanisms in Shopware 6. Frequently requested content is cached so that database queries and PHP processes do not have to be executed again with every page view. This makes pages respond much faster and noticeably reduces server load.

Especially with high traffic, a properly configured caching system prevents unnecessary load spikes and stabilizes the entire shop infrastructure. At the same time, visitors benefit from shorter load times and an overall smoother user experience.

Overview of Cache Strategies in Shopware

Shopware 6 uses several caching layers that perform different tasks. These include the PHP OPcache, the Symfony-based HTTP cache, and external solutions such as Redis or Varnish.

While OPcache keeps compiled PHP files in memory, Redis accelerates database-related processes and sessions. Varnish, in turn, can deliver complete HTTP responses directly without putting additional load on PHP or MySQL.

Only the interaction of these layers enables a scalable and high-performance Shopware architecture.

Impact on Performance

A well-designed cache strategy often reduces the response times of a Shopware shop considerably. Content can be delivered faster, while CPU load, database access, and memory operations decrease at the same time.

In particular, the full-page cache significantly improves Time to First Byte (TTFB), because precomputed content can be delivered directly. This not only has a positive effect on the user experience, but also supports better Core Web Vitals and more stable conversion rates. 
See also our guide to Shopware TTFB optimization.

Shopware HTTP Cache

How the HTTP Cache Works

The Shopware HTTP cache, based on the Symfony Reverse Proxy, acts as an intelligent cache that stores complete HTTP responses for certain routes before they are sent to the client’s browser. The cache evaluates HTTP headers such as “Cache-Control” and “ETag” to decide whether a resource needs to be requested again from the backend or can be served from its own storage. In addition, the Symfony-based Reverse Proxy uses Edge Side Includes (ESI) to embed individual dynamic fragments—such as the shopping cart notice—within an otherwise fully cached page. It relieves the PHP backend enormously for recurring requests because the entire Shopware 6 stack does not have to be initialized again.

HTTP Cache Configuration

The HTTP cache in a Shopware 6 shop is configured primarily via the `shopware.yaml` or `config/packages/framework.yaml` file, where developers can precisely define the validity period (TTL – Time to Live) and the routes to be cached. A correct cache strategy includes setting relevant cache tags for products, categories, and Product Streams in order to enable granular invalidation. Shopware’s documentation provides detailed instructions on how to configure this feature optimally for the entire system.

Cache Invalidation and Clearing

Cache invalidation is a central component of the Shopware HTTP cache because it ensures that customers do not see outdated product data, prices, or stock levels. Instead of clearing the entire cache, Shopware 6 works with cache tags to invalidate affected content specifically.

In newer Shopware versions, invalidation is also delayed via Scheduled Tasks and the Message Queue. When products or categories are updated, Shopware does not immediately delete the affected pages from the cache. Instead, they are first marked as “invalid” and then regenerated in the background.

This approach significantly reduces load spikes and, especially in larger shops, ensures more stable cache hit rates as well as consistently lower server loads.

Completely clearing the cache should only be done in exceptional cases, for example after deployments, plugin updates, or major template changes. The classic CLI command is:

bash
php bin/console cache:clear

The cache can then be warmed up again:

bash
php bin/console cache:warmup

However, automatically clearing the entire cache every day via cronjob is usually not sensible for larger Shopware projects. Especially with extensive product catalogs, rebuilding the full-page cache can take a very long time and temporarily lead to significantly higher server loads.

Optimal Invalidation Intervals

For medium-sized shops with around 10,000 to 50,000 products and regular order volumes, an invalidation interval between 3,600 seconds (1 hour) and 14,400 seconds (4 hours) has proven effective in many projects.

Intervals that are too short create unnecessary database load, while intervals that are too long can cause price changes or stock levels to appear in the frontend with a delay.

The adjustment is made directly via the database:

SQL
UPDATE scheduled_task 
SET run_interval = 3600 
WHERE name = 'shopware.invalidate_cache';

Move Cache Invalidation Out of the Request Cycle

The actual cache invalidation should generally not be processed within the normal HTTP request cycle. If the calculation is performed directly during a user request, noticeable load spikes and increased response times can occur, especially with larger product catalogs.

Instead, execution via dedicated CLI workers and Scheduled Tasks in the background is recommended. This keeps the storefront stable even under high concurrency, while cache recalculation is processed asynchronously.

Scheduled Tasks should therefore be executed via a system cronjob rather than through the browser admin:

bash
bin/console scheduled-task:run --time-limit=240 --memory-limit=512M

In addition, enabling delayed cache invalidation is recommended (from Shopware 6.7 onward):

env
SHOPWARE_HTTP_CACHE_DELAYED_INVALIDATION=1

This means cache recalculations are processed asynchronously, which significantly stabilizes response times under high concurrency.

HTTP Cache Lifetime (TTL)

The default TTL of the Shopware HTTP cache is 7,200 seconds (2 hours). Once this period has expired, the page must be completely regenerated the next time it is accessed.

Because Shopware already has an intelligent tagging and invalidation system, it is often advisable in production environments to set the TTL significantly higher.

Up to and including Shopware 6.7, the configuration was handled globally via the .env:

env
Bis Shopware 6.7
# HTTP-Cache aktivieren
SHOPWARE_HTTP_CACHE_ENABLED=1
# Lebensdauer auf 24 Stunden erhöhen (86400 Sekunden)
SHOPWARE_HTTP_DEFAULT_TTL=86400

New Cache System from Shopware 6.8

From Shopware 6.8 onward, HTTP caching is fundamentally expanded. Cache lifetime is no longer controlled globally via the .env, but is defined granularly through policies at route and area level.

In addition, Shopware introduces a new opt-out principle. Through the sw-cache-hash cookie, the cache now remains active by default even for logged-in users or filled shopping carts.

Important new Cache-Control directives are:

• s_maxage: Defines the maximum lifetime in the HTTP cache or reverse proxy.
• stale_while_revalidate: Allows stale content to be served while the cache is rebuilt in the background.
• must_revalidate: Forces revalidation in the browser cache.

The configuration is made via shopware.yaml:

yaml
# config/packages/shopware.yaml
shopware:
  http_cache:
    # 1. Richtlinien definieren
    policies:
      # Beispiel für eine lange Lebensdauer (z.B. 24 Stunden)
      mein_shop_policy:
        headers:
          cache_control:
            public: true
            max_age: 0
            must_revalidate: true
            s_maxage: 86400           # Cache-Lebensdauer in Sekunden (hier 24 Std)
            stale_while_revalidate: 86400
            stale_if_error: 7200
    # 2. Die Richtlinie standardmäßig zuweisen
    default_policies:
      storefront:
        cacheable: mein_shop_policy

Varnish Cache and Its Role

What does Varnish do for Shopware? Varnish acts as an HTTP reverse proxy in front of the web server. It serves static content and HTML pages directly from RAM without putting load on PHP or MySQL. This drastically lowers TTFB and protects the system from load spikes.

Setting Up Varnish for Shopware

Setting up Varnish as a reverse proxy in front of Shopware 6 requires precise configuration of the VCL (Varnish Configuration Language). Varnish processes incoming HTTP requests before the actual Shopware backend and decides whether content can be served directly from the cache or must be forwarded to PHP and the web server.

Typically, static assets and complete HTML pages are cached, while dynamic areas such as checkout, customer account, or shopping cart must be excluded from caching. In addition, cache tags, purge requests, and ESI blocks play an important role in clean cache invalidation.

A correctly configured VCL significantly reduces backend load, and therefore memory access and CPU usage, while improving the scalability and load time of the shop.

Example of a Simple Varnish VCL

The specific Varnish configuration always depends heavily on the infrastructure, plugins in use, individual session logic, and the shop’s traffic profile. Nevertheless, the following example shows a typical basic configuration for Shopware 6:

VCL
sub vcl_recv {
    # Kein Cache für Checkout und Kundenkonto
    if (req.url ~ "^/checkout" ||
        req.url ~ "^/account" ||
        req.url ~ "^/widgets") {
        return (pass);
    }
    # Nur GET und HEAD cachen
    if (req.method != "GET" &&
        req.method != "HEAD") {
        return (pass);
    }
    return (hash);
}
sub vcl_backend_response {
    # Standard TTL
    set beresp.ttl = 24h;
}

In production Shopware environments, individual rules are also often implemented for the following areas:

• Cache tags
• PURGE requests
• ESI blocks
• Cookies
• Shopping cart handling
• GeoIP logic
• Personalized content
• Bot traffic
• CDN integration

Especially in larger Shopware projects, the VCL should therefore always be tailored individually to the infrastructure, hosting setup, and plugin landscape.

Reverse Proxy Cache: Advantages and Challenges

Especially for shops with high traffic, the internal Shopware HTTP cache sooner or later reaches its limits. In such scenarios, Varnish becomes particularly relevant because requests are processed before PHP processes or database queries are even generated.

This significantly reduces both server load and response times. Particularly on heavily visited category or product pages, Varnish can achieve considerably better cache hit rates.

The biggest challenge, however, lies in cache invalidation. Changes to products, prices, or CMS content must be communicated specifically to Varnish via purge requests or cache tags so that no outdated content is served.

To handle these cache invalidation challenges in live operation, a perfectly coordinated web server setup is essential. Dedicated Shopware Hosting Optimization ensures that Varnish purges are processed without delay. Particularly on heavily visited category or product pages, Varnish can achieve considerably better cache hit rates. However, correctly implementing the complex invalidation logic requires deep system expertise. As a certified Shopware agency our developers handle error-free VCL customization. If you are unsure where your system is currently losing loading speed, we identify all hidden caching bottlenecks as part of a strategic analysis and consulting .

Cache Statistics and Monitoring

Effective monitoring of Varnish cache statistics is essential for evaluating caching efficiency and identifying potential bottlenecks. Tools such as `varnishstat` or integrations with monitoring solutions such as Prometheus provide detailed insights into cache hits, misses, and evictions, revealing the actual level of optimization. This data enables shop operators and developers to continuously optimize the VCL configuration and adapt the cache strategy to the specific requirements of the Shopware shop.

Important Note on Shopware 6 Versions in Connection with Varnish

• Shopware 6.5 (The Legacy Architecture): In this version, Varnish primarily acts as an add-on layer. Cache invalidations are resource-intensive and performed via BAN requests using regular expressions (RegEx) through Redis or the database. With large product updates, this leads to measurable CPU load spikes on the Varnish server.
• Shopware 6.7 (The Performance Quantum Leap): With version 6.7, the architecture was completely redesigned. The Varnish xkey module is now mandatory and resolves item tags within microseconds. Together with natively enforced Edge Side Includes (ESI), static content and dynamic fragments (such as the shopping cart) are cleanly separated.
  – The result: Official benchmarks show up to 108% more processed orders per second in simulated flash sales and a reduction in server latency (p99) of up to 58%.
• Shopware 6.8 (The Enterprise Stabilization): While 6.7 introduced the new system, 6.8 adds the final refinements. The system introduced behind the CACHE_REWORK feature flag in 6.7 becomes the standard here. Version 6.8 minimizes the dreaded “over-invalidation” (the unintended clearing of the entire cache during simple backend configuration changes) and sustainably stabilizes the cache hit rate in live operation.

These improvements also change the required Shopware Varnish configurations. The VCL must therefore be adjusted accordingly beforehand.

Redis as Object Cache

As an in-memory database, Redis moves volatile cache data and PHP sessions out of the slow file system into RAM. This prevents I/O bottlenecks and massively accelerates Shopware systems with 10,000 products or more

Configuring Redis in Shopware 6

In many large Shopware projects, Redis is used to significantly reduce database queries and session locks. Especially under high concurrency, file-system-based session handling quickly reaches its limits. Configuration is performed via `config/packages/shopware.yaml`, where the Redis adapter for caching and sessions is defined, typically with a DSN such as `redis://localhost:6379`. A properly implemented Redis setup significantly increases the speed of the Shopware shop.

Example of a Redis Configuration for Shopware 6

For Shopware 6, Redis is often used both as an object cache and for sessions. A typical Redis integration in shopware.yaml can, for example, look like this:

yaml
shopware:
  cache:
    invalidation:
      delay: 3600
framework:
  cache:
    app: cache.adapter.redis
    default_redis_provider: 'redis://127.0.0.1:6379'
  session:
    handler_id: Redis
    save_path: "tcp://127.0.0.1:6379"

It is important to never run Redis in production environments without a memory limit. Without a defined maxmemory setting, Redis can consume all available server memory under high load or faulty cache invalidations.

A typical basic configuration in redis.conf can, for example, look like this:

INI
maxmemory 2gb
maxmemory-policy allkeys-lru

The allkeys-lru strategy ensures that older cache entries are automatically removed as soon as the defined memory limit is reached.

The optimal memory size depends heavily on the size of the shop as well as the following factors:

• Number of products
• Concurrent users
• Session volume
• Plugins in use
• HTTP cache hit rate
• Number of Sales Channels

Especially in larger Shopware projects, the Redis configuration should therefore be monitored regularly and adjusted to the actual load.

Redis Sessions and Their Optimization

Moving PHP sessions to Redis relieves the server’s file system and accelerates the processing of user requests, especially under high traffic, which massively improves system scalability. By default, PHP stores sessions on disk, which leads to I/O bottlenecks with many concurrent users; Redis provides fast access times here. This optimization is crucial for shops with 10,000 or more simultaneous visitors.

Comparison Between Redis and Varnish

While Redis acts as an object cache and for sessions at the application level and accelerates database-related queries, Varnish functions as a reverse proxy HTTP cache at network level that serves complete pages. Redis accelerates Shopware’s backend processing, while Varnish minimizes the number of requests to the backend. Both technologies complement each other; Varnish serves the “fast” cache for static content and Redis the “dynamic” cache for cached data.

Full Page Cache and Cache Warmup

Implementing the Full Page Cache

The full page cache in Shopware 6, often implemented in combination with Varnish or the Symfony HTTP cache, stores fully rendered HTML pages for specific routes in order to enable extremely fast delivery for recurring requests without renewed PHP processing. This intensive caching strategy is particularly effective for non-personalized content such as product listings or category pages. Configuration is handled via HTTP headers as well as the ESI and cache tags integrated into Shopware.

Effects on Core Web Vitals

An effective full page cache implementation and precise cache warmup strategies have a direct and significant impact on Core Web Vitals by drastically improving Largest Contentful Paint (LCP) and First Input Delay (FID) values.

By providing pre-generated content, server response times are minimized and rendering speed is increased, resulting in a better user experience and a positive assessment by search engines.

Scaling Large Shops

Reducing Database Load Through Caching

Caching significantly relieves the database in large Shopware shops by eliminating the need for repeated, resource-intensive database queries, because frequently requested data is served from the faster cache. Object caches such as Redis keep product, category, and configuration data in memory, reducing the number of SQL queries. This is crucial for shops with large volumes of data and complex relationships because it ensures speed and stability.

Optimizing Server Load

Through comprehensive use of HTTP caches, reverse proxies such as Varnish, and object caches such as Redis, PHP utilization and overall server load in Shopware 6 environments are significantly reduced. Cached content minimizes the number of requests reaching the PHP backend, which means fewer CPU cycles and less memory need to be allocated. This optimization allows the shop to withstand high traffic while guaranteeing fast load times.

Example Architecture of a Shopware Cluster for High Availability and Maximum Performance

• 2 load balancers
• 2 Varnish servers
• 2 Elasticsearch/Redis servers
• 2 web servers
• 2 MySQL servers (e.g. Galera Cluster or primary/primary replication)
• Separate backup system
• Optional: File server/NAS for the shared media folder
• Optional: Backend/administration server

It is important that all production systems—with the exception of the backup server—communicate via internal network connections. Ideally, this is done via a separate internal network or a second network card. Alternatively, all systems should at least be located in the same local network segment so that communication takes place without additional router hops. This reduces latency and improves overall performance .

Backup Strategy

The optimal backup strategy depends heavily on order volume and the frequency of changes to product data.

For medium-sized Shopware shops, the following intervals have proven effective:

• Database backups: every 2 hours during the day, every 6 hours at night (retention: 7 days)
• Files/Webroot/Media: 2× daily (retention: 30 days)
• Infrastructure configurations (e.g. load balancer/Varnish): after changes, plus a monthly backup.

In practice, a consistent backup of the database and web/media data is usually fully sufficient. Services such as Redis, Varnish, or Elasticsearch normally do not need to be backed up separately because their data is automatically rebuilt or synchronized after a restart.

Hosting Options: Shopware Cloud vs. Own Server

The choice between Shopware Cloud and your own server has a major influence on the scalability and cache optimization of a Shopware shop. The cloud provides preconfigured, often automatically scaling caching solutions, while your own server offers full control over every cache layer and the infrastructure. Shopware Cloud manages the infrastructure and caching automatically, reducing administrative effort. Your own server, however, offers the flexibility to tailor Redis, Varnish, and OPcache precisely to specific requirements, which is essential for maximum optimization.

Best Practices for Cache Optimization

For effective cache optimization in Shopware 6, it is advisable to implement a multi-layer cache strategy combining Redis as an object cache, Varnish as a full page cache, and the Shopware HTTP cache. Setting precise cache tags for granular invalidation, automating cache warmup processes via cronjobs, and regularly monitoring cache statistics ensure consistently high speed. Reduce PHP processing and database queries through consistent caching.

Monitoring and Analysis

Tools for Monitoring Cache Performance

Continuous monitoring of cache performance is essential in order to identify bottlenecks early and ensure the long-term stability of a Shopware system. Especially in larger shops with high concurrency, proper monitoring often determines whether a shop remains stable and performant under load.

Different tools are used depending on the infrastructure in place.

Varnish Monitoring with varnishstat

The most important analysis tool for Varnish is varnishstat. It provides real-time information on cache hits, misses, backend requests, memory consumption, and queue utilization.

Particularly relevant metrics are:

A typical command:

bash
varnishstat -1

For production Shopware systems, persistently low cache hit rates are usually considered a warning signal. If the hit rate remains below 50% (up to Shopware 6.6.x) / 70% (from Shopware 6.7 onward), this often indicates the following problems:

• Incorrectly configured cookies
• Unnecessary return(pass)rules
• Overly aggressive cache invalidations
• Missing xkey soft purges
• Plugins with personalized content

Especially on heavily visited category pages, cache hit rates well above 90% should be achievable.

Analysis of HTTP Headers

Many cache problems can already be analyzed directly in the browser. Using the developer tools (F12) HTTP headers can be checked.

Important headers in Shopware/Varnish environments:

A typical example:

html
x-cache: HIT
cache-control: public, s-maxage=86400
age: 5321

This means:

• Page was successfully served from Varnish
• TTL is 24 hours
• Object has already been in the cache for 5321 seconds
• With a small adjustment in the Varnish default.vcl the number of hits can also be displayed

vcl
sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
        set resp.http.X-Cache-Hits = obj.hits;
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

If, on the other hand, MISS appears constantly even though the page should be cacheable, there is usually a cookie, session, or proxy problem.

Redis Monitoring and Memory Analysis

Redis should be monitored regularly for memory consumption, evictions, and response times.

Important commands:

bash
redis-cli info memory

shows, among other things:

• current RAM consumption
• maxmemory limits
• fragmentation
• evicted keys

Equally important:

bash
redis-cli info stats

The following critical values, among others, can be identified here:

Rising evicted_keys are usually a clear sign that:

• the maxmemory setting was chosen too small
• sessions and cache are operated together
• the wrong eviction policy is active

Especially with Shopware, Redis should never be allowed to grow without limits.

Monitoring PHP OPcache

PHP OPcache is also one of the most important performance factors in Shopware 6.

The current status can, for example, be read via:

bash
php -i | grep opcache

or via small status scripts.

Critical metrics:

Especially in large Shopware installations with many plugins, it often happens that:

• opcache.max_accelerated_files is set too low
• scripts are constantly reloaded
• the hit rate drops sharply

In production environments, the OPcache hit rate should remain close to 100% over the long term.

Long-Term Monitoring with Prometheus & Grafana

For larger Shopware clusters, centralized monitoring via the following is also recommended:

• Prometheus
• Grafana
• Netdata
• Zabbix
• Datadog
• New Relic
• check_mk

This allows the following values, among others, to be visualized continuously:

• Cache hit rates
• Redis RAM utilization
• MySQL query times
• PHP-FPM utilization
• Queue runtimes
• TTFB
• Varnish backend fetches
• Web server CPU load

Historical comparisons after the following are particularly helpful:

• Deployments
• Plugin updates
• Shopware updates
• Marketing campaigns
• Black Friday load spikes

This often makes it possible to identify performance problems before customers notice them.

Typical Practical Monitoring Problems

Recurring patterns often emerge in real Shopware projects:

Suddenly Falling Cache Hit Rate

Often caused by:

• new plugins
• tracking scripts
• incorrectly set cookies
• session starts on every page

High Redis Evictions

Frequently caused by:

• missing maxmemory
• shared use for sessions and cache
• the wrong eviction policy

Varnish Backend Fetch Spikes

Typical causes:

• missing cache warming
• hard purges instead of soft purges
• TTLs that are too short
• faulty invalidation

High TTFB Despite Varnish

Usually caused by:

• uncached AJAX requests
• slow Elasticsearch queries
• blocking plugins
• overloaded MySQL servers

Professional monitoring makes it possible to identify such problems early and take targeted countermeasures before the shop’s performance or stability suffers.

FAQ: Typical Cache Problems and Cache Optimization

The most common questions about cache strategies in Shopware 6 include aspects such as “Which caches are relevant for my shop?”, “How do I prevent outdated content?”, and “How do I scale caching under high traffic?”. Shop operators and developers often look for best practices for configuring Redis, Varnish, and the HTTP cache, as well as methods for effective invalidation and cache warmup. These questions focus on optimizing load times and reducing server load.