Shopware hosting and performance that survives peak days
Black Friday falls on Friday 27 November 2026. From mid-November your traffic climbs and your ad spend climbs with it. Whether you win that day is decided in the weeks before it.
Shopware hosting is not the same thing as hosting a website. You are running an application with a database, a search index, several cache layers and background jobs that all come under pressure at once.
.png)
Why a webshop demands more from hosting than a brochure site
A brochure site serves more or less the same response to everyone. A webshop does the opposite. The basket, the customer price, the stock status and the delivery options differ per visitor and per moment, so part of every request genuinely has to be calculated.
That calculation is exactly what eats your capacity once it gets busy. On an average day you notice nothing. On the day that pays for the year, it decides whether your checkout holds up.
At Memo we therefore deliberately run on-premise Shopware on an environment you can inspect and tune. You see what is happening and you can intervene, instead of waiting for a sealed stack to start cooperating again.
What we find when that environment is sized for an average day:
- Too few PHP workers: requests end up in the queue.
- No search index: filtering puts extra load on the database.
- Heavy product images: the easiest win is left on the table.
- Background jobs without headroom: exports compete with your visitors.
What your Shopware store asks of its hosting
Seven components together decide how many concurrent visitors you can handle. If one of them is undersized, the rest topples after it. This is what we look at before we scale anything up.
PHP workers
Every request that is not served from cache occupies a worker. That number is your hard ceiling.
Database
Prices, rules, orders and customer data all come from here. Slow queries only show up once it gets busy.
Search index
Without Elasticsearch or OpenSearch, searching and filtering fall back on the database exactly when it is already struggling.
Cache layers
HTTP cache, Redis for sessions and application cache, and optionally a reverse proxy that absorbs anonymous traffic.
Media and CDN
Product images are usually the heaviest part of your page and at the same time the easiest win available.
Monitoring and alerting
You want to see queues and response times per page type, not just whether the site is still reachable.
Backups and staging
An environment where you safely test a release, plus a backup whose restore procedure you actually know.
What breaks during a peak, and in what order
A peak almost always follows the same pattern. First the PHP workers fill up, because there are more concurrent visitors than processes. Requests queue and response times rise.
Next the database becomes the bottleneck: more waiting requests means more open connections and slower queries. Then search gives way, because searching and filtering are the most expensive operations you run.
Only after that do you see what everyone else sees: a checkout that hangs and a customer who leaves. The problem started three steps earlier. That is why monitoring that only answers whether the site is reachable structurally arrives too late.
Caching is the cheapest performance you will ever buy. A page served entirely from HTTP cache never touches PHP or the database. Redis keeps sessions and application data instantly available, and a reverse proxy absorbs the bulk of your anonymous traffic.
That is precisely where the risk sits in B2B. You work with customer-specific prices, tiered pricing, customer groups and restricted assortments. A cache that does not know a page differs per customer group will serve the wrong price to the wrong customer. That stops being a performance problem and becomes a trust problem, and an expensive one in quoted deals.
The answer is not to cache less but to cache more precisely. Decide which parts of a page are identical for everyone and which vary by customer group or logged-in account, and handle that second set separately. How you model prices and customer groups is covered on the Shopware B2B page, because it directly determines how much you can cache.
.png)
Core Web Vitals: what gets measured and what your customer feels
Google assesses the loading experience on three points: Largest Contentful Paint (how quickly the largest visible element appears), Interaction to Next Paint (how quickly the page responds to a tap or click) and Cumulative Layout Shift (how much the page still jumps around while loading). Google publishes the thresholds for a good score on web.dev.
Two things matter here. Google measures field data from real visitors, not your test score on a fast laptop. And the most visible gains rarely come from server configuration: oversized product images, too many third-party scripts and a layout that shifts because dimensions are missing weigh far heavier.
What you can do yourself is more concrete than it sounds. Compress your product images and give them fixed dimensions, cut back third-party scripts and defer anything that is not immediately visible. That usually covers most of LCP and CLS. Server work and frontend work then belong in the same project, because together they determine the same score.
How to prepare for the 27th of November
A peak day is won or lost in the weeks before it. We start by measuring the baseline: response times per page type, Core Web Vitals field data and the number of concurrent visitors on a normal day.
After that we load test a realistic scenario. Not just the homepage, but the actual path: category, filter, product, basket, checkout. If you sell B2B you test with logged-in accounts, because that traffic barely comes from cache. Workers, database and search index are then adjusted at the point where the test actually fell over, not on instinct.
Around that you put the agreements in writing: alerting on queues and response times with a threshold at which somebody gets called, a rollback plan setting out which release you revert and who decides, a deployment freeze in the days around the peak, and a degraded fallback with heavy features that may be switched off temporarily.
When you start on this we decide together. It depends on your release calendar, on how heavy your peak is, and on what is still being built. The one hard rule: load testing has to be finished before the deployment freeze starts, otherwise you end up with a test result you can no longer act on.
Hosting, monitoring and performance work are recurring items alongside build costs. How they compare is set out on the costs page.
That it can be done without changing platform is what Kempers shows. Together with Hypernode, the hosting platform for e-commerce applications we partner with, that store became three times faster in load time, without a full migration. How we approached it is described in the case study Memo and Hypernode published together. Measure where the time goes first, then intervene where it counts.
Frequently asked questions
What counts as good Shopware hosting?
Hosting where PHP workers, database, search index and cache layers are tuned to each other and to your traffic, with visibility into what is happening. You should be able to see how many concurrent requests you can handle and where the time goes. A shared environment without that visibility is almost always too tight for e-commerce when it matters.
How much traffic can my Shopware store handle?
That depends on the number of PHP workers, the response time per request and the share of traffic served from cache. Without a load test, any number is a guess. A test on a realistic customer path tells you where the first bottleneck sits and what scaling up would actually buy you.
Can caching show the wrong B2B prices?
Yes, if the cache does not distinguish between customer groups. Customer-specific prices, tiers and restricted assortments have to stay out of the shared cache or be separated per customer group. That is a design decision you take up front, not something you patch afterwards.
Do I need to migrate to make my store faster?
Usually not. At Kempers, performance gains were achieved together with Hypernode without a full migration. Start by measuring: if the bottleneck sits in images, scripts or cache configuration, changing platform is an expensive detour.
What can I do about Core Web Vitals myself?
Compress your product images and give them fixed dimensions, cut back third-party scripts and defer anything that is not immediately visible. That usually covers most of LCP and CLS. The rest, such as server response time and cache behaviour, belongs in the hosting and development work.