Ecommerce Load Testing: How to Prepare for Black Friday

Introduction

Ecommerce sites usually don’t fall over on a quiet afternoon. When they struggle, it’s often at the worst possible times: Black Friday, Cyber Monday, the flash sale you spent a month promoting, or the moment a big email campaign lands.

That’s not bad luck. Peak sales events often bring more traffic than any other day of the year, and that same traffic is the reason a slowdown hurts so much. Every minute the site is slow or unavailable during a sale is a minute of your most motivated customers trying to buy something and not being able to.

The good news is that peak shopping days are scheduled in advance. You know roughly when the traffic is coming, which means you can rehearse it. This guide walks through how to load test an ecommerce site ahead of a peak event, what to test, what tends to break, and how to fit it all into the weeks you have left.

Why Ecommerce Sites Are Harder to Load Test

A lot of load testing advice assumes a fairly simple website: some pages, maybe a login. An online store is a full-fledged web application with a lot of moving parts that only show up under real shopping behavior.

• Most of the important pages can’t be fully cached. A CDN can serve your homepage and product images to a lot of anonymous visitors. It usually can’t serve carts, logged-in pages, search results, inventory checks, or checkout, because those are different for every shopper.
• Shopping writes to the database. Adding to the cart, applying a discount code, reserving inventory, and placing an order all write data. Writes are generally harder to scale than reads, and they compete with each other for the same rows and tables.
• Checkout depends on other people’s systems. Payment providers, tax and shipping calculators, fraud checks, address validation, and email services all sit in the critical path. Their speed under your peak traffic tends to become your speed.
• Sale traffic arrives in bursts. A sale that starts at a set time, or an email or push notification that goes out all at once, can bring a large share of the day’s visitors within a few minutes.

This is why a test that throws identical requests at the homepage can pass easily while the real site still falls over on the day. If you want a deeper look at the common failure points themselves, our guide to why websites crash under traffic covers them in detail.

Step 1: Estimate Your Peak Concurrent Users

Before you can test for peak traffic, you need a number to aim for. The most useful number for a load test is concurrent users: how many shoppers are actively using the site at the same moment.

Start with your busiest hour, not your daily total. A day with 200,000 visits sounds big, but what matters is how many of those visits land in the busiest hour, and how long each one lasts.

The calculation is a simple version of Little’s Law: multiply the visits in your peak hour by the average session length in hours.

So if you expect 50,000 visits in your busiest hour and the average session lasts 9 minutes (0.15 hours):

That’s roughly 7,500 concurrent shoppers on average during that hour. Real traffic inside the hour isn’t smooth, so plan for more than the average, especially for the first few minutes after a sale goes live.

A few ways to get a realistic peak-hour estimate:

• Look at last year’s peak event in your analytics. Find the busiest hour of last Black Friday or Cyber Monday, not the daily total.
• Adjust for growth and marketing plans. If overall traffic has grown since last year, or you’re planning a bigger campaign, scale last year’s peak up to match. Ask your marketing team what’s scheduled and when.
• Find out when the emails and pushes go out. Campaign send times tend to create the sharpest spikes of the day.
• Add headroom. Testing at a meaningful margin above your estimate gives you room for the forecast being wrong, which forecasts often are.

If you want to understand how your current setup compares, our guide on how many concurrent users your website can handle walks through finding your actual limit.

Step 2: Script the Shopping Flows That Matter

The traffic you simulate should look like real shoppers, which means scripting the journeys people actually take, in roughly the proportions they take them.

Map out your key user journeys

For most stores, a reasonable starting set looks something like this:

• Browsers: land on the homepage or a sale page, view a category, view a few products, and leave. This is usually the largest group by far.
• Searchers: run a few searches, filter results, and view products. Search is often backed by a separate service that deserves its own attention.
• Cart builders: browse, add a few items to the cart, maybe apply a discount code, and abandon the cart.
• Buyers: go all the way through checkout, including shipping, payment, and order confirmation. This group is usually the smallest, but it does the hardest work for your servers and it’s where your revenue comes from.
• Logged-in customers: sign in, check order history or saved addresses, and shop from there.

Your analytics can tell you the rough split. A common pattern is many browsers, fewer cart builders, and a smaller share of buyers, but use your own numbers rather than a rule of thumb.

Use realistic test data

Shoppers don’t all buy the same product with the same account. If every bot adds the same item to the cart, you’ll end up testing your cache and one database row instead of your store. Use datasets to give each bot its own account, search terms, products, shipping addresses, and discount codes.

Pay special attention to the products in your sale. If one doorbuster item is going to get a big share of the traffic, include it, because popular items can cause contention on a single inventory record that spread-out traffic never would.

Choose protocol-level or browser-based traffic

Loadster supports a few different ways to generate load, and they’re useful for different things:

• Protocol Bots send HTTP requests directly. They’re efficient, so they’re a good fit for simulating large numbers of shoppers and putting real pressure on your servers, APIs, and database.
• Browser Bots drive real Chrome browsers through your site, clicking and typing like a shopper. They run your JavaScript, third-party scripts, and front-end checkout logic, which protocol-level traffic skips.
• Playwright Test scripts let you reuse tests you may already have for your storefront, with each one running in its own real browser.

A practical approach for many stores is to generate most of the volume with Protocol Bots and run a smaller group of browser-based bots through checkout at the same time, so you can see what a real shopper experiences at scale.

Step 3: Handle Inventory, Payments, and Third Parties

Checkout is where ecommerce load testing gets tricky, because it touches real systems with real consequences.

Test payments without charging real cards

You don’t want a load test charging real cards or creating real orders that get shipped. Common approaches include:

• Running checkout tests against a staging environment that uses your payment provider’s test or sandbox mode.
• Using test card numbers and clearly marked test accounts and products.
• Stopping the script just before the final payment step, if you can’t test payments safely at all. This still exercises cart, shipping, and tax, which are often the slow parts.

Check your payment provider’s documentation before you start. Sandbox environments often have their own rate limits, and some providers ask you not to load test their APIs directly. Respecting those limits matters, and it also means you may need to stub or simulate the payment call to test your own side at full volume.

Keep test orders out of fulfillment

If your tests place orders, they’ll decrement inventory and create order records. Decide ahead of time how you’ll handle that: dedicated test products with large stock counts, a way to identify and clean up test orders, and a plan to keep test orders out of fulfillment, accounting, and marketing emails.

Tax, shipping, and other third parties

Tax calculation, shipping rates, address validation, fraud screening, search, reviews, recommendations, and analytics are often provided by other companies. Under your peak load, any of them might slow down or rate limit you.

You generally shouldn’t load test another company’s API without their permission. But you can and should find out what happens to your site when one of them gets slow. Make sure your calls to third parties have sensible timeouts and a fallback where possible, so a slow tax or recommendations service doesn’t hold every checkout hostage.

Bot protection during a load test

Many stores have a web application firewall, CDN bot protection, or rate limiting in front of the site, and those may block or challenge load test traffic. That’s often a good sign, since they’re doing their job. Talk to whoever manages them before the test, and agree on how test traffic will be allowed through without permanently weakening your protections.

Step 4: Run Load Tests That Look Like the Real Event

With scripts and data in place, build a load test scenario that mirrors the event you expect.

Start with a gradual ramp

Begin with a load test that ramps up gradually to your expected peak and holds there for a while, perhaps 20 to 30 minutes or longer. This tells you whether the site can handle the peak at all, once caches are warm and any autoscaling has had time to react.

Then add a spike

Real sales often start with a burst. Add a spike test on top of your baseline traffic, using an aggressive ramp so that a large group of bots arrives within a short window, like shoppers piling in when a sale goes live or an email lands. Keep the test running after the spike so you can see whether the site recovers on its own.

Run long enough to catch slow failures

Black Friday and Cyber Monday are long days, and many sales now run for a week or more. A longer endurance test at a steady, elevated level can reveal memory leaks, filling disks, growing queues, and other problems that a 20-minute test won’t show.

Watch checkout times and errors

In the test results, focus on:

• Response times at the 95th percentile, not just the average, for each step of the journey. The average can look fine while a meaningful share of shoppers wait much longer.
• Error rates, especially on add to cart and checkout.
• Which step slows down first. If browsing stays fast but checkout slows down, that points to the database, inventory, or third-party calls rather than raw web server capacity.

Have your own server, database, and application monitoring open during the test. Loadster shows you what shoppers experience; your own metrics tell you why.

Step 5: Fix What Breaks, Then Test Again

The first serious load test of a store usually finds something. That’s the point. Look at what ran out first, fix it, and run the same test again.

Common fixes for ecommerce sites include:

• Caching more of the catalog. Category pages, product pages, and search results for anonymous shoppers can often be cached for short periods, even if carts and checkout can’t.
• Tuning the database. Missing indexes on order, cart, and inventory tables tend to show up under load, along with connection pools sized for an ordinary day.
• Moving work out of the checkout request. Confirmation emails, analytics events, and some fraud checks can often happen in the background instead of while the shopper waits.
• Adding capacity before the event. If you know when the sale starts, scale up ahead of time rather than counting on autoscaling to catch up during the first rush.
• Planning for graceful degradation. Decide in advance what you’d turn off under extreme load, such as recommendations or some personalization, so checkout keeps working.

It’s fairly common to go through several rounds of fix and retest before a store handles its target traffic comfortably, which is exactly why it helps to start early.

A Practical Timeline for Black Friday Readiness

Here’s a rough plan, working backwards from the event. Adjust it to fit your team and how much time you have.

• Six or more weeks out: Estimate your peak concurrent users. Map the key shopping journeys. Get access to a realistic test environment and sort out payment sandboxes and test data.
• Four to six weeks out: Script the journeys and run your first load test at a fraction of peak, then at peak. Expect to find bottlenecks.
• Two to four weeks out: Fix, retest, and repeat. Add spike and longer endurance tests once the steady-state test passes.
• One to two weeks out: Run a final full rehearsal with the code, configuration, and capacity you plan to use on the day. Many teams freeze risky changes after this point.
• On the day: Watch your monitoring closely, have people on hand who can act, and keep a short list of things you can turn off if the site starts to struggle.

If you’re reading this with only a week or two to go, it’s still worth testing. Focus on the checkout journey, test at your expected peak, and fix the biggest problem you find.

Monitoring During the Peak Event

Even a well-tested store can surprise you on the day. Real shoppers do things your scripts didn’t, and third-party services have their own busy days too.

Synthetic monitoring runs scripted checks against your site every few minutes from outside your own network. For a store, the most valuable checks go beyond “is the homepage up” and walk through the shopping flow: search, view a product, add it to the cart, and reach checkout. If any step slows down or fails, you hear about it quickly, ideally before customers start telling you.

The same scripts you built for load testing can often be reused as monitors, so the effort you put into scripting checkout pays off twice.

Conclusion

Peak shopping events often bring an online store’s biggest traffic exactly when downtime costs the most. The upside is that they’re on the calendar, so you can rehearse them.

Estimate your peak concurrent users from your busiest hour, script the journeys real shoppers take (especially cart and checkout), handle payments and third parties carefully, and run load, spike, and endurance tests that look like the real event. Fix what breaks first, test again, and watch the critical flows closely on the day.

Next Steps: Getting ready for Black Friday or a big sale? Try Load Testing with Loadster to script your shopping and checkout flows with Protocol Bots, real browsers, or Playwright Test, and ramp up to your expected peak from cloud regions around the world. Loadster customers have run load tests with more than 170,000 concurrent Chrome browsers, and well into the millions of Protocol Bots. You can start with 50 units of free fuel, no credit card required.

Related Guides

• Why Websites Crash Under Traffic — the common causes of crashes during high traffic and how to prevent them.
• Spike Testing — rehearsing a sudden burst of traffic and checking that your site recovers.
• Concurrent Users — what concurrent users are and how to calculate them.
• How to Load Test a Website — a step-by-step guide to planning and running your first load test.