Magento speed optimisation. What to measure in peak and fix in January
Magento speed optimisation work started in late October has about four weeks before Black Friday on 27 November, and less once a code freeze begins. That’s rarely enough time to regression test a theme change, an extension swap or a version upgrade, and a release that breaks checkout will break it in the busiest trading week of the year.
Black Friday traffic will also show you which pages slow down under real load. A load test finds the ceiling, but only real traffic shows you the mix. So our advice to clients is to freeze code ahead of peak, record performance through it, keep pre-peak work to low-risk checks, and plan the fixes for January from what the peak data shows.
This is the platform side of part one of The Calm Advantage, Jamie Huskisson’s weekly series on running peak calmly.
Where Adobe Commerce stores slow down under load
On a well-configured store, most category and product pages come from the full page cache, usually Varnish on a self-hosted store and Fastly on Adobe Commerce Cloud. The basket and checkout can’t be cached. So every shopper there is a fresh request to PHP and the database, often to a payment gateway and an address lookup, and sometimes to an ERP stock check too.
Cached pages still send uncached requests as well: add to basket, and the calls that fill in the mini-basket and the customer’s name. Search and filtered category pages rarely get much help from the cache either. That’s where the queue forms when traffic triples. And because the homepage is cached, checking homepage speed won’t show it.
The second pattern catches more teams out than the first. Adobe’s documentation says a single uncacheable block makes the whole page uncacheable. A block added by a new extension can take every product page out of cache, and nothing on the page looks broken. The pages simply slow down as traffic climbs.
Campaign links can do something similar. Magento’s default cache ignores the common tracking tags, but not every email or ad platform’s, and a cache config exported years ago won’t know the newer ones.
When a store is fine in September but slows down in November, we start with what changed: a new extension, a campaign tag, a block added to the product page. Then we look at what the cache hit rate did afterwards.
How to measure Magento performance during peak
Don’t judge peak by lab tests. A lab test is one simulated device, one run and often a cold cache. Lab tests are great for debugging, and you’ll use them to check January’s fixes, but they say very little about how 9pm on Black Friday felt to a shopper. For that, you need server data and real shopper data, captured hour by hour and compared with an ordinary week.
At JH, we watch five numbers:
- Server response time on basket and checkout
- Checkout error rate, including server errors and payment failures
- Cache hit rate
- Largest contentful paint on mobile product pages (from real user monitoring)
- Checkout completion by device
Response time can look fine while checkout is quietly failing, which is why error rate sits next to it.
If real user monitoring isn’t in place yet, don’t add it this month. On Adobe Commerce Cloud, the other four are already there. On a self-hosted store, server response times may only exist if your access logs record them.
Magento speed optimisation you can safely do before Black Friday
Before Black Friday, limit the work to checks.
These are the ones we run ahead of peak. Each one protects our clients against a failure that would only show up under peak load.
How the store handles change
If product edits and catalogue imports trigger reindexing straight away, a routine price update can slow an entire site in the middle of trading. We make sure indexing runs on a schedule and that large imports move overnight until December.
Cache clears need the same discipline. Nobody flushes the whole cache during trading hours. Promotions and price rules that switch on at midnight also clear large parts of the cache just as traffic arrives, so we warm the cache straight afterwards.
“A full cache flush during trading hours. That’s the one change I’d never make in November.” – Jason Ujma-Alvis, JH
We also check that cron is healthy. It runs indexing and order exports, often the message queues, and transactional emails where they’re sent asynchronously. A stalled job in October turns into late order confirmations and a backlog in the warehouse during Black Friday week.
Capacity
Sessions and cache both need room to grow. If sessions and cache share one Redis instance, a busy cache can push sessions out, and shoppers lose their baskets mid-checkout. When the page cache is too small, it starts discarding pages, and the store slows down just as traffic peaks.
Your last big campaign is the quickest evidence. If your cache was evicting pages then, it will again on Black Friday.
Search needs headroom too. It’s mostly uncached, so OpenSearch takes the load directly, and price scrapers hammer search and filter pages on Black Friday. We check search capacity and put limits on bot traffic before peak. For clients on Adobe Commerce Cloud, we also request temporary extra capacity from Adobe ahead of the event.
Everything added since summer
The third is everything that has been added to a page since summer. The median mobile page already makes 79 requests to third parties. Black Friday campaigns add more:
- Affiliate pixels
- Live chat
- Countdown timers
- A/B tests
We list every tag on product, basket and checkout pages with its owner and purpose. Anything no one can explain gets paused and tested before peak.
What to leave until January
Anything that changes code or data belongs after peak. A new theme, extension swap, version upgrade, catalogue restructure that forces heavy reindexing. They’re often the right fixes, but they need proper regression testing. Late October doesn’t leave room for it.
Larger Magento speed optimisation work needs time to plan and test. When we moved Woodie’s, Ireland’s largest DIY retailer, from Magento 1 to Magento 2, a headless front end and custom builds in place of off-the-shelf plugins cut average load time by 47%, alongside a 79% rise in conversions. That was planned work, built on evidence about where the old site slowed down. Your peak data is the start of the same kind of case.
So keep a ranked list instead of running a sprint. For each slow page, write down the measurement, the likely cause, the effort, the risk and what it did to checkout completion.
Built from real peak traffic, that list is where January’s Magento speed optimisation should start. It’s also the evidence a CMO or CFO will ask for before signing off a rebuild.
Slow pages are easier to fund when you can show what they cost you last Black Friday. In Deloitte and 55’s research for Google, a 0.1-second improvement in mobile site speed lifted retail conversion by 8.4%.
Load test before peak so January has a target
We load test with k6 on a production-like environment, using a realistic mix of:
- Browsing
- Search
- Basket
- Checkout
Push past your forecast. A record sales day is usually a record traffic day too. Find the point where checkout response times start to climb, log what you find for January and keep the number, because next year’s test needs something to beat.
Our Black Friday technical checklist covers the tooling.
Your Black Friday numbers are the baseline January’s fixes will be measured against.
If you’d like a developer to read that night’s data with you, book a Performance Review now to run after Cyber Monday. You’ll get a ranked fix list built from your own peak traffic, with the effort and expected impact of each fix.
Jamie’s free Calm Advantage Playbook 2026 brings all six peak worksheets together, including the baseline where these numbers belong. Pre-register for your copy.
If you’d like to discuss your post-peak Magento optimisation plans, get in touch with JH today.