Shopware performance
Shopware cache optimisation: more pages served straight from the cache
We configure the Shopware 6 cache so that as many pages as possible come straight from the cache: HTTP cache, reverse proxy, Redis and an invalidation that only clears what has really changed.
- since 2012
- 200+ online shops
- 800+ websites
- Shopware Partner since 2014
Online shops
200+
delivered since 2012
Projects delivered
1000+
since 2012
Shopware Partner
since 2014
own plugins in the Shopware Store
-
Shopware Partner since 2014
-
Mollie Partner since 2021
-
Trusted Shops Partner
-
eRecht24 Partner
-
magnalister Partner since 2022
-
Base Partner since 2026
-
sync4 Partner since 2022
-
Pickware Partner since 2019
-
ADCELL Partner
Why the Shopware cache barely gets any hits in many shops
Many shops have a cache that hardly ever hits. A plugin sets a cookie on every page, a nightly import clears the entire cache, or logged-in customers bypass it completely. Shopware then renders every page from scratch, even though nothing has changed.
What cache optimisation for Shopware 6 does for you
- More page views are served straight from the cache.
- A product import no longer clears the whole shop.
- The server has headroom for peaks such as newsletters or promotions.
- You can see how often the cache hits and why it sometimes misses.
Scope of services
What our Shopware cache optimisation covers
- HTTP cache
Pages are rendered once and then delivered instantly.
- Reverse proxy
Varnish or a comparable proxy takes load off the shop.
- Redis
Cache data sits in memory and is the same for every server.
- Targeted invalidation
Only changed products and categories are rebuilt.
- Cache warm-up
Key pages are warm again right after a deployment.
- Finding cache blockers
Defuse cookies, sessions and plugins that bypass the cache.
With cache optimisation, we make sure that as many pages of your Shopware 6 shop as possible are served straight from the cache. We review the HTTP cache, set up a reverse proxy such as Varnish and Redis where needed, and configure invalidation so that only changed content is rebuilt. This lowers the load and keeps the shop fast even at peak times.
public static function getSubscribedEvents(): array
{
return [
ProductPageLoadedEvent::class => 'onProductPage',
];
}
public function onProductPage(ProductPageLoadedEvent $event): void
{ /* add data without touching the core */ } Why a cache often hits less than expected
A cache only helps if pages are the same for many visitors. A single cookie from a plugin or a tracking script can be enough to prevent that. Imports that clear the entire cache on every price change are also costly. We look at when and why the cache misses and fix the causes instead of simply upgrading the server.
Search result
Examplewww.web-labels.de › en › shopware › cache-optimisation
Shopware 6 cache optimisation | Web Labels
Cache optimisation for Shopware 6: HTTP cache, reverse proxies such as Varnish, Redis, targeted invalidation and warm-up, so more pages come from the cache.
Working together with Redis and the database
Cache, Redis and database belong together. Where pages cannot be cached, for example in the basket or with customer-specific prices, the speed of the database decides how fast the shop is. That is why we look at all three layers together.
- ERP
- PIM
- Marketplaces
- CRM
How we work
How Shopware cache optimisation runs with us
- Understand
We look at your business, your systems and your figures before we suggest anything.
- Plan
You receive a concept and a quote with individual items and a realistic schedule.
- Build
We develop in stages. You see interim results on a test environment and approve them.
- Run
After go-live we take care of hosting, updates and monitoring if you want us to.
Your contacts
Your contacts for Shopware performance
Tell us where your project stands. Janis and Tim will listen, ask questions and tell you honestly what we recommend and roughly what it will cost.
Our team for your questions
-
René Grosche Managing Director
-
Marco Kreutzfeldt Deputy Managing Director · Back office
-
Tim Schröder Key Account Manager · Consulting and quotes
-
Janis Rittmeier Key Account Manager · Consulting and quotes
-
Lennart Albrecht Head of Development
-
Tom Baustian Web design · Performance marketing · Audio
-
Tajara-Tabea Leonard Web design · Content · SEO
-
Ken Raupach Web design · Performance marketing
-
Muhammed Tay Web development
-
Alexander Folz Web development
-
Aaron Griem Web development
-
Leon Fischer Web development
-
Patrick Heidl Web development
-
Tobias Schäfer Web development · Complex development
-
Laura Schop Web development
- Aleksej Werestschagin Web development
-
Julina Sievert Apprentice
-
Rosa-Lee Biesterfeldt Apprentice
Frequently asked questions about Shopware cache optimisation
All questions and answersWhy is our shop slow despite the cache?
Often the cache hits less often than expected. Typical causes are cookies or session data that make every page unique, or imports that regularly clear the whole cache. We find these with measurements and logs.
Do we need Varnish?
Not always. The built-in Shopware HTTP cache is enough for many shops. With high traffic or several servers, a reverse proxy such as Varnish takes off additional load. We decide based on your traffic.
What about logged-in customers?
Different rules apply to logged-in customers with their own prices, because pages are not the same for everyone. We check which parts can still be cached and speed up the rest via Redis and the database.
- Performance
Faster Shopware 6 shops: we measure with ShopSignal and Tideways, find the bottlenecks in database, cache, search, theme and server, and fix what makes the biggest difference first.
- Redis
We set up Redis for Shopware 6: for cache, sessions, locks and counters, cleanly separated and configured to stay stable under load.
- Elasticsearch
We connect Elasticsearch or OpenSearch to Shopware 6 so that search, filters and listings come from a dedicated index and the database is relieved.
- Database queries
We find the queries that slow down your Shopware shop, understand them with EXPLAIN and profiling, and fix them with indexes, better DAL queries or adjusted plugin code.
A few sentences are enough to start. We will get back to you with questions or a suggested date.