Shopware Performance: Faster Loading Times

General tips like compressing images or trimming scripts help any frontend but fall short for a shop. A shop system renders most pages server-side from many data sources, and personalized elements like the mini cart or customer-specific prices complicate any naive full-page caching. Shopware CE ships its own tools for exactly these problems, tools that reach deeper than a cache header in the web server. Whoever knows and configures them correctly cuts the response time at the root instead of merely masking it in the browser. The commercial lever is considerable: in the same Deloitte analysis, average order value in retail rose by 9.2 percent (Deloitte) per 0.1 seconds.

This article deliberately sets itself apart from the generic topics. How a reverse proxy and an in-memory store fundamentally work at the infrastructure level is covered by our article on caching strategies with Varnish and Redis; how to speed up slow queries with indexes and by resolving N+1 patterns is shown by the piece on database query optimization in the shop. Here, by contrast, the focus is on the Shopware tools themselves: which configuration activates these layers, how invalidation interlocks cleanly and which routes must stay excluded. The link to the Core Web Vitals runs throughout, because a low TTFB directly improves Largest Contentful Paint.

An empty cache after a deployment is treacherous: the first visitor to each page pays the full rendering time, and with many concurrent hits the still-cold application can be overloaded. Cache warmup therefore fills the store in advance by automatically requesting the most important pages such as the homepage, categories and product details. This way the first real visitor already hits a warm cache and a low TTFB instead of paying for the buildup. The warmup ideally belongs in the deployment process, right after clearing the cache.

Just as important as filling is targeted clearing. A cache is only as good as its invalidation: when a price or stock level changes, exactly the affected page must be refreshed, not the whole cache. Shopware solves this via cache tags. The reverse proxy cache shares the same invalidation mechanism and the same tags with the object cache, so a product change invalidates both the object cache and the HTTP cache of the affected pages (Shopware Developer Documentation). This tight coupling saves custom invalidation logic and prevents customers from seeing stale prices.

For small shops, the relational database handles product lists, filters and search effortlessly. But once the catalog grows to tens of thousands of articles with many properties, filter and search queries become a brake because they run over large tables and evaluate complex joins. This is exactly where connecting Elasticsearch or OpenSearch comes in: it takes over search, navigation and listing aggregations and thereby noticeably offloads the database. The storefront reads the result lists from the search index instead of from MySQL, which significantly lowers the response time of large category and search pages.

The effort does not pay off for every shop. A catalog with a few hundred products often runs faster without a search index, because the additional service costs operation and memory. From several tens of thousands of articles or with many concurrent filter accesses, the ratio reverses. In addition, classic optimization of the remaining queries stays important, as described in the piece on database query optimization in the shop; the search index does not replace clean indexes but takes the most expensive load off the database. A sound performance analysis therefore measures in advance which page type really dominates the database time.

An often underestimated lever is the update itself. The current 6.x generation of Shopware CE brings performance improvements that take effect without any development work of your own. From Shopware 6.6 onward, the cart can be stored compressed with zstd, saving memory and transfer (Shopware Developer Documentation). Newer versions optionally load reduced product data in lists, so only the short text is loaded instead of the full description, and they allow taking the product stream indexer and the scheduled sitemap generation out of the request path (Shopware Developer Documentation). Each of these adjustments relieves the hot path on which the user waits.

On top of that comes the jump to current PHP versions that an update pulls along. Newer PHP generations with preloading and JIT process the same code faster, and the current 6.x generation experimentally supports the Speculation Rules API for prefetching the likely next page. These advances add up to a noticeably lower response time without changing anything in your own code. A version several generations back forfeits exactly these gains.