Sale Launch at Midnight: Warm the Cache Instead of Waiting

A sale launch packs three events into a few seconds. Prices change, banners and promo pages go live, and newsletters, push messages and ads send visitors to exactly those pages at the same time. Roughly half of internet users aged 16 and over in Germany planned to use the Black Friday deals in 2025, 52 percent (Bitkom 2025), most of them online. For Black Friday and Cyber Monday combined, the German Retail Federation expected revenue of EUR 5.8 billion (HDE 2025). If you announce a fixed start time, part of that demand arrives at exactly that time.

In that minute, the cache works against you. An HTTP cache answers a request itself only if it already holds a valid response for exactly that URL and that context. After a price switch, that is no longer true for many pages: Shopware tags every stored response with cache tags and, when a product is saved, discards the entries that carry that product (Shopware documentation). The next visitor has to fetch every discarded page from PHP and the database again. When many visitors hit many different, freshly discarded pages at once, all of those requests land in the same PHP process pool. How many of them run in parallel is capped by the pm.max_children setting (PHP manual); everything else waits. There is a reason the Shopware documentation calls the HTTP cache a must-have for every production system.

You feel this in the server response time. A Time to First Byte of 0.8 seconds or less counts as good, anything above 1.8 seconds as poor (web.dev). From the cache, a Shopware page usually comes in well below that; without the cache, it depends on the database, rule evaluation and template rendering. How much load your system can take overall is what a load test before peak season tells you. This article is about not letting the load hit PHP unchecked at sale launch in the first place.

Since Shopware 6.7.0.0, the shop no longer discards entries immediately. It collects the affected tags and processes them at a fixed interval, and the default interval is 5 minutes (Shopware upgrade notes 6.7). Day to day, this raises the hit rate because duplicate invalidations disappear. On the night of the sale, it shifts the problem: a price import at 11:58 pm may only take effect in the cache after midnight, exactly when visitors arrive. Shopware offers two tools for such cases. The sw-force-cache-invalidate: 1 header on an Admin API request invalidates immediately, and the cache:clear:delayed command runs all collected invalidations at once. With cache:watch:delayed, you can see in advance which tags are still waiting in the queue.

If a reverse proxy sits in front of the shop, a second question comes up: what does it serve after a page has expired or been discarded? The example configuration Shopware provides for Varnish keeps serving expired entries for three days after expiry while fetching a fresh copy in the background (Shopware example configuration). In normal operation, that is intended. For the price switch, it means a page whose lifetime ends at midnight is served once more with the old price on the first request afterwards. Soft purging, which Shopware describes as an option, has a similar effect: it keeps the old page and refreshes it in the background (Shopware documentation).

The same principle sits behind the stale-while-revalidate directive in the Cache-Control header. If you set it together with max-age to 600 seconds each, the RFC says you have to accept that a response may be served from the cache for up to 20 minutes (RFC 5861). Outside the sale night, that is a good trade; at the price switch, it is not. That is why the switch calls for a hard purge, followed by cache warming.

The cache rework in Shopware 6.7.0.0 brings some relief: since then, the storefront loads the header and footer via ESI and stores them separately from the rest of the page (Shopware upgrade notes 6.7). A new promo bar in the header therefore affects one fragment, not every page individually. How to build that bar without a layout shift is covered in Promo banner for Black Week without layout shift.

A crawler that fetches the entire shop takes longer than the night allows for large catalogs, and it loads the server right before the launch. A list sorted by expected demand makes more sense. Three sources feed it:

The sitemap itself should have been generated long before. The documentation describes generating it for large catalogs as resource-intensive and shows how to run it as a separate cron job at a quiet time (Shopware documentation). On the night of the sale, it has no place in the queue.

The most important lever is not a tool but a separation: the moment prices change and the moment visitors arrive do not have to be the same. You trigger the visitor flow yourself, with the newsletter, push message and ad launch. The window for cache warming lies in between.

If the price has to change at exactly 12:00 am, for instance because marketplaces or price comparison sites expect that time, the window gets shorter, but not zero. Everything heavy runs beforehand: sale prices as prepared data, indexing, sitemap, a dry run of the crawler. At midnight, only the switch itself follows, immediately after that the purge and the crawler. The newsletter and ads go out only once stage one is served from the cache, usually a few minutes after midnight.

Since Shopware 6.6.10, there is a dedicated command for clearing: cache:clear:http clears the reverse proxy or, without a proxy, the shop's HTTP cache (Shopware documentation). The general cache:clear is the wrong tool here; it clears and rebuilds the application cache, and in older versions it cleared the HTTP cache along with it. The crawler itself needs no special software. A short script with curl is enough, as long as it limits concurrency and logs what comes back:

The concurrency in the script is deliberately low. The crawler is meant to fill the cache, not to become a load test of its own. The load test is a good reference: once you know how many simultaneous page requests the server can handle without the cache, keep the crawler well below that. Newer curl versions understand the %header{age} field; older ones can write the headers to a file with -D.

A procedure that runs once a year tends to fail on small things: a missing permission for a command, a crawler that bypasses the load balancer, a newsletter tool with its own time zone. That is why a trial run on an ordinary evening in the weeks before pays off, with a small real price change. You measure two things: how long the crawler needs for stage one, and how long the hit rate stays down after clearing without a crawler. The difference is your gain, and it shows whether you need the option with the early price switch.

A fixed log per step helps: time, command, result, measured value. On the night of the sale, it replaces memory and makes the procedure repeatable next year. Where the shop already reaches its limits under normal traffic, look at server optimization and server response time before the trial run. A warm cache only hides bottlenecks for the pages it knows; the first search, the cart and the checkout still run through PHP.

We support this procedure for Shopware shops: a warm-up list from your field data, a crawler along the real path, invalidation that matches your price import, and a trial run with a measurement log. More on our approach is on the pages about caching strategies and Shopware performance; for online shops with seasonal peaks, we bring these topics together under PageSpeed for e-commerce. How to estimate the effort for this kind of work is covered in What does PageSpeed optimization cost?.