Prepare your online store for Black Friday

A slow store loses a share of its orders. A store that falls over loses all of them, usually within minutes of the peak. The two failures have unrelated causes. Slowness is a per-request cost, so each page takes longer, some shoppers leave, and the rest still buy. Falling over is a queueing problem. Your server has a fixed number of PHP workers, and when requests arrive faster than workers free up, the queue grows, response times climb from two seconds to twenty, timeouts start returning errors, and shoppers reload, which doubles the load that caused it. That feedback loop is why stores fail suddenly instead of degrading politely. A good page-speed score therefore tells you almost nothing about whether you survive concurrency, and peak season tests both on the same night.

Most of a storefront can be cached and served to thousands of people from one rendered copy. The parts that make money cannot. Cart, checkout and account pages are personal by definition, so every request runs PHP and touches the database. That is where concurrency concentrates. Session writes, order inserts and meta updates contend for the same tables. On older order storage those tables are also where your content lives. Coupon usage limits and stock decrements add row-level contention: two hundred people redeeming one code are effectively queued against a single counter. Meanwhile admin-ajax.php absorbs whatever plugins have attached to it — cart fragments, tracking calls, live search — and none of it is cached. Find out what actually runs there before the peak. Plugin bloat decides how much of your traffic touches PHP at all, which matters more on this night than anything it does to page speed.

• Cart, checkout and account pages are uncacheable by design
• Cart fragments and plugin calls pile onto admin-ajax.php
• Coupon limits and stock decrements serialize on single rows
• Order writes compete with your slowest database queries

Six weeks is the last point at which you can change something structural and still test it properly. Start with evidence, not instinct. Pull last year's hourly traffic and order data, find the single busiest hour, and multiply it by the growth you genuinely expect. That number is your target, and it belongs in a load test that reproduces a realistic mix — mostly browsing, a meaningful share adding to cart, a smaller share reaching payment — because a test that only hammers the homepage proves the cache works and nothing else. Then decide what changes. Buying server headroom is the fastest lever and is often the right answer for one night. Changing how the storefront is served is the deeper fix and needs the whole six weeks; speed work on WooCommerce sets out what each level involves. Make that call now, not after the first slow Saturday.

From two weeks before the peak, treat production as frozen. No plugin updates, no theme updates, no core upgrade, no new tracking script a marketing tool suggested, no experimental payment method added because someone asked. The argument is not that updates are dangerous in general. It is that the cost of a regression is now asymmetric. A broken variation swatch in March costs an afternoon, and the same break on the busiest evening of the year costs the evening. Security patches are the exception, and even those get staged and tested first. Write the freeze down and tell everyone holding admin credentials, including the agency running ads and the developer who helps occasionally. Most peak-night incidents are self-inflicted and trace back to a change nobody announced.

• No plugin, theme or core updates after the freeze date
• Security patches only, staged and tested before production
• Everyone with admin access is told the date in writing
• Any exception is logged with who approved it and why

The site staying up is half the job. The other half is whether the promotion behaves the way you described it in the email. Discount rules interact in ways nobody predicts on paper: a percentage coupon stacked on an already-reduced item, a tiered discount that recalculates when one line is removed, a free shipping threshold that is met before the discount applies and missed afterwards. Rebuild those combinations on staging with real products, real prices and your live tax and shipping rules, then take each one through to payment. Cover the awkward cases specifically: the mixed cart, the exact threshold, the cart that qualifies then drops below it, the shopper trying two codes. Repeat it on a phone, because a coupon field that breaks the layout is a functional fault, not a cosmetic one. How checkout is handled explains which part of that flow we deliberately leave native.

Peak traffic exposes inventory that was only approximately right. Two problems arrive together. The first is oversell: when a hundred people are looking at the same last five units, decrements race each other, and stock is normally reserved when an order is placed, long after the item entered a cart. The second is quiet drift: a manual adjustment made in a spreadsheet, a supplier feed that stopped updating three weeks ago, a bundle whose components were never linked to their own stock. Count your genuine bestsellers physically instead of trusting the number in admin. Then decide in advance what happens when you do oversell, because at some volume you will: cancel and refund with an apology, part-ship, or backorder with a stated date. A decision made calmly in November beats one made at midnight, and support needs the exact sentence to send.

On the day, nobody should be developing. There are three jobs: knowing, deciding, and being able to go back. Knowing means monitoring what earns money, not whether the server answers. A synthetic check that adds a product to the cart and reaches the payment step every few minutes catches failures an uptime ping never sees. Deciding means an alert that reaches a human by phone, with a named person awake and a second name behind them, because a dashboard nobody is watching is not monitoring. Going back means a rollback you have already practiced: a database and file backup from a known-good point, a way to switch the promotion off without a code deploy, and one written line about who is allowed to make that call. Restore the backup once, on staging, before you need it. An untested backup is a hypothesis.

• A synthetic cart-and-checkout test every few minutes
• Alerts that phone a named person, with a fallback name
• A restore rehearsed on staging, not just a backup taken
• A switch that ends the promotion without a deployment

Then part of the plan above is not for you this year. Two weeks is not enough runway for architecture: a replatform or a caching redesign shipped in the final two weeks adds the risk it was meant to remove. The honest scope is narrow: add headroom, freeze everything, rehearse the promotion, verify the restore, arrange the alert. That is unglamorous and usually sufficient. There is also a case for doing nothing: if last year's busiest hour sat well inside what your hosting handles on an ordinary Tuesday, paying for capacity to absorb a spike you have never had is money spent on a guess. Do the structural work in January, when a mistake costs a quiet week and not the best evening of the year, and what that costs is published so you can plan around the calendar. Whatever happens, write the debrief on the Monday after: what broke, what you touched, which alert fired and which did not. Kept in the same place each year, that note turns a scramble into a checklist.