Load Testing Your Website Before Peak Season
Speed and Capacity Are Different Questions
Run PageSpeed Insights and you learn how quickly your site loads for one visitor on a reasonable connection. That is a useful number and it is not the number that matters on Black Friday.
Peak season asks something else: what happens when two hundred people are on the site at once, forty of them are in checkout, your marketing email has just landed, and a bot is crawling your product catalogue? Sites that score well on speed tests routinely fall over under that, because the bottleneck is not page weight — it is the database, the hosting plan, the payment integration or a single slow query nobody has ever noticed.
Testing this in October is straightforward. Discovering it in November is not.
Where Sites Actually Break
In rough order of how often we see it:
Shared hosting limits. Most small business sites sit on shared plans with concurrency caps. Exceed them and you get 503 errors, not slowness. The site does not degrade — it stops.
Database contention. WordPress and WooCommerce in particular become database-bound under load. Cart operations, stock checks and session handling all hit the database, and they cannot be cached the way a product page can.
Uncacheable pages. Your homepage can be served from cache. Basket, checkout and account pages cannot. So the pages under the most pressure during peak are precisely the ones getting no help from your caching layer.
Third-party scripts. Chat widgets, review platforms, analytics, ad pixels. When one of them slows down, your pages wait for it. A third-party outage on Black Friday takes your site with it unless scripts are loaded defensively.
Payment gateway rate limits. Rare, but catastrophic. Worth knowing your provider's limits and status page.
Admin activity. Someone bulk-editing products or running a stock import during peak traffic competes for exactly the same resources as your customers.
Testing Without a Lab
You do not need enterprise tooling. Four levels of testing, in increasing order of effort.
Level 1: Know your limits (30 minutes)
Before testing anything, ask your host directly:
- What is my concurrent visitor or PHP worker limit?
- What happens when I exceed it — queueing, or errors?
- Can I upgrade temporarily, and how quickly?
- Is there a CDN in front of my site, and what does it cache?
- What is my database plan, and is it shared?
Get the answers in writing. Half of all peak-season incidents we see are resolved by an upgrade that could have been arranged in October for a modest sum.
Level 2: Field data (free, and most representative)
The Chrome User Experience Report contains real measurements from real visitors on real devices, aggregated over 28 days. It is available in PageSpeed Insights and Search Console's Core Web Vitals report.
This is more honest than any synthetic test because it reflects your actual audience — including the ones on older Android handsets on patchy signal in a car park, who are a meaningful share of Northern Ireland mobile traffic.
Look at the 75th percentile, not the average. If your 75th percentile LCP is already marginal in October, it will be poor in November. Our website speed benchmarks sets the targets, and our Core Web Vitals guide covers remediation.
Level 3: A basic concurrency test (an hour)
Free and low-cost tools — k6, Loader.io, Artillery and similar — will send a defined number of concurrent users at your site and report response times and error rates.
A sensible first test:
- Establish your expected peak. Take last year's busiest hour and multiply by two.
- Test the journey, not the homepage. Homepage → category → product → add to basket → checkout. Testing only the homepage tests only your cache.
- Ramp up gradually — 10, 25, 50, 100 concurrent users — and watch for the point where response times climb or errors appear.
- Run it at a genuinely quiet time, and tell your host first. Some providers treat load tests as attacks and will block you.
What you are looking for is the knee in the curve: the concurrency level where response time stops being flat and starts climbing steeply. That number is your real capacity.
Level 4: A dress rehearsal
The most useful test available to most small retailers, and the least technical.
Send a real email to a real segment of your list at a real time, with a real offer, in late October. A few hundred people arriving in ten minutes is a genuine load spike, and it tells you what happens under conditions you cannot simulate — real devices, real payment attempts, real support questions.
Do this once in October and you will find whatever is going to break, with a month to fix it.
What to Measure
During any test, watch four things:
Response time under load. Specifically, how it changes as concurrency rises. Flat is good. A gentle slope is acceptable. A cliff is your limit.
Error rate. Any 5xx errors are a hard failure. Any at all, at any concurrency level you expect to reach, need fixing.
Checkout completion. The metric that matters commercially. A site that stays up but drops checkout completion from 60% to 35% under load is failing, even though nothing errored.
Server resources, if you can see them. CPU, memory and database connections. This tells you which limit you hit, which tells you what to fix.
Fixing What You Find
If you hit concurrency limits — upgrade the plan, or move to a host built for the traffic. This is usually the cheapest fix available and the one people delay longest.
If page generation is slow — implement or improve full-page caching for everything cacheable, and put a CDN in front. Our caching guide covers the setup.
If the database is the bottleneck — reduce plugin count, clean up post revisions and transients, add object caching, and move any heavy scheduled jobs out of trading hours.
If third-party scripts are the problem — audit them ruthlessly. Load what remains asynchronously, and make sure a slow third party cannot block rendering. Most sites are carrying at least two scripts nobody remembers adding.
If images are the weight — this is the most common and most fixable issue. Modern formats, correct dimensions, lazy loading below the fold. Our image optimisation guide covers it.
Preparing for the Day Itself
Testing tells you your capacity. Preparation tells you what to do when you approach it.
- Know how to upgrade hosting quickly, and have the login to hand
- Have a status page or holding message ready — a clear, branded "we're busier than expected, back shortly" page is far better than a raw error
- Set up basic uptime monitoring with an alert to a phone, not an email
- Freeze deployments from around 10 November. Most peak incidents are caused by changes, not traffic
- Turn off non-essential scheduled tasks during peak hours — imports, backups, bulk emails
- Know your rollback plan. If something does go wrong, how quickly can you get back to yesterday's working version?
When It Is Not Worth It
If you are a service business with modest, steady traffic and no transactional pages, formal load testing is overkill. Do level 1 and level 2 — know your hosting limits, watch your field data — and spend the rest of the effort on the things that actually constrain you.
Load testing earns its keep when you have a transactional site, a marketing plan that creates spikes, or a history of the site struggling. If you have had one outage during a busy period before, you will have another one unless something changed.
The Point
Peak season traffic is not a reward for good marketing if the site cannot serve it. An hour of testing in October is the cheapest insurance available on the busiest day of your year.
Our golden quarter readiness guide covers the wider preparation, and our Black Friday countdown sets out the timeline.
If you want your site tested and hardened before the traffic arrives, get in touch with Amigo Studios. We build and maintain fast, resilient websites and e-commerce platforms across Northern Ireland.
Senior Developer