Caching & CDN
A well-configured caching stack makes your shop faster and significantly reduces server load — static pages don't hit the database on every request, assets are served from the nearest edge server, and users worldwide experience the same fast result.
Faster Shops with Caching & CDN
We implement multi-layer caching with Varnish or Shopware HTTP Cache, object caching with Redis, and CDN integration — coordinated and production-ready configured.
The essentials of Caching & CDN
- We implement multi-layer caching: HTTP caching with Shopware HTTP Cache or Varnish, object caching with Redis, and a CDN for static assets.
- Each layer solves a different problem at a different level of the stack — only the coordinated combination delivers genuinely low load times.
- We serve product images, CSS, and JavaScript from CDN edge servers, which relieves the origin server and noticeably speeds up international users.
- We handle cache invalidation selectively via Shopware events, so customers see current data immediately after price or stock changes instead of phantom stock.
- We configure production-ready with correct exceptions for basket and login — a cache that serves the wrong thing is worse than none at all.
HTTP Caching
The Shopware HTTP Cache or Varnish as a reverse proxy caches fully rendered pages and serves them from cache without touching the Shopware application. Correct cache-control headers, cache invalidation strategies for product changes, and ESI for dynamic content like shopping baskets are the building blocks of a production-ready HTTP caching configuration.
Redis for Object Caching
Sessions, product data, category structures, and expensive database queries can be cached in Redis and are available in milliseconds on the next request. We configure Redis as the central cache store for Shopware, calibrate TTL values for different data types, and implement cache tags for granular invalidation.
CDN Integration
Product images, CSS, JavaScript, and other static assets don't need to be served from the origin server. A CDN serves them from edge servers worldwide, reducing latency for international users and relieving your origin server. We configure CDN setups with correct cache headers, automatic image optimisation, and geographic routing.
Cache Invalidation
Caching only works when changes are reliably propagated. We implement cache invalidation logic that selectively invalidates affected cache entries when products, prices, or inventory change — without flushing the entire cache and losing the performance benefit. Shopware events are used to trigger invalidations automatically.
The caching stack: three layers, one goal
Fast load times don't come from a single lever — they require three coordinated caching layers. Each solves a different problem; only the combination delivers consistently low latency worldwide.
CDN delivery
Static assets & cached pages served from the nearest edge server — no request ever reaches the origin.
Object caching with Redis
Database queries, sessions, and computed data are held in memory — the app server does far less work.
HTTP caching (Varnish / Shopware Cache)
Fully rendered pages are stored — the application stack is bypassed entirely for known pages.
Apex = goal (global delivery), base = broadest layer (HTTP caching).
Where does the real effort in caching lie?
Switching caching on is easy. The effort is in the details: correct invalidation, well-designed cache keys, and safely handling personalised content.
- Cache invalidationPrice & stock changes visible immediately, without stale data being served
- Cache keys & exclusionsCorrectly excluding cart, login, and personalised content
- CDN configurationEdge rules, origin shield, cache headers, and purge workflows
- Redis object cachingConnection, serialisation, and TTL strategy setup
- Enabling HTTP cacheBase configuration of Varnish or Shopware HTTP Cache
Relative weighting
Relative weight of implementation effort — not runtime or performance figures.
What matters for Caching & CDN
Caching is the most effective performance measure, but only as a layered model. HTTP caching, object caching with Redis and a CDN for static assets each solve a different problem on a different level of the stack. Only the coordinated combination delivers genuinely low load times, while a single layer quickly hits its limits in a complex shop.
The genuinely hard problem is not caching but invalidation. Setting up a cache is easy, but ensuring customers see current data immediately after a price or stock change is the demanding discipline. Wrong invalidation shows up as phantom stock or stale prices and costs exactly the trust that fast pages are meant to build.
A CDN takes measurable load off the origin server while improving global load time. When static assets are served from edge servers, a large share of requests never reaches the origin, which lowers bandwidth costs and noticeably speeds up users far from the server location. This is exactly where the difference shows for an international audience.
Good caching work is configured production-ready, not just switched on. Sensible cache keys, correct exceptions for basket and login, and a considered approach to personalised content decide whether the caching truly works or creates subtle errors. A cache that serves the wrong thing is worse than no cache at all.
Multi-layer caching is necessary
HTTP caching, object caching, and CDN solve different performance problems at different levels of the stack. Only the combination delivers truly low load times — a single caching layer is not sufficient for complex e-commerce shops.
Cache invalidation is the hard problem
Setting up caching is easy. Ensuring customers always see current data after a price or inventory change is the actual challenge. Incorrect cache invalidation manifests as phantom inventory or stale prices — and costs trust.
CDN measurably relieves the origin server
When static assets are served via CDN, the majority of asset requests never reach the origin server. This reduces bandwidth costs, relieves the server infrastructure, and improves load times for users far from the server location.
Fast from anywhere
With us you're always at the cutting edge of technology and benefit directly from our developer expertise. Together we analyze your shop, identify key areas and develop tailor-made solutions. Your goals and expectations are at the center of our work.
Developers, not resellers
Your shop is built by developers who really understand the code. We pass nothing to subcontractors.
Shopware down to the detail
Architecture, API integration and performance from hundreds of project hours.
One team, every discipline
Development, design and marketing come from one team that works without friction at the handoffs.
Built for growth
We build measurably for conversion, load time and revenue.
Partner, not vendor
We stay on after launch and keep developing your shop continuously.
Ready for your successful online shop?
Related articles from our blog
Angular vs React vs Vue: Which frontend framework suits your shop?
Angular, React or Vue for your shop? A practical comparison for e-commerce and headless shopware with a clear recommendation based on team, SEO and setup.
BFSG-Checkliste für Shopware 6: So wird dein Online-Shop barrierefrei
Since June 2025, all B2C online shops must fulfil WCAG 2.1 Level AA - but many Shopware retailers are not yet compliant. The first waves of warnings are already underway and fines of up to €100,000 are imminent. This guide shows you step by step how to make your Shopware 6 shop BFSG-compliant.
MedusaJS: What the headless commerce framework 2026 can really do
MedusaJS crops up in almost every composable commerce discussion. But what is the framework really suitable for - and what is it not? A neutral overview of the architecture, workflow engine, TCO and realistic entry paths for decision-makers in the e-commerce SME sector.
Frequently asked questions