# Ecommerce Load Testing: How to Prepare for Black Friday > How to load test an ecommerce site before Black Friday or Cyber Monday: estimate peak traffic, script cart and checkout, and follow a practical timeline. Source: https://loadster.com/guides/ecommerce-load-testing/ ## 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](https://loadster.com/guides/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](https://loadster.com/guides/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. Concurrent users = visits per hour × 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): 7,500 = 50,000 × 0.15 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](https://loadster.com/guides/how-many-concurrent-users/) 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](https://loadster.com/manual/dynamic-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](https://loadster.com/manual/protocol-scripts/)** 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](https://loadster.com/manual/browser-scripts/)** 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](https://loadster.com/playwright-load-testing/)** 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](https://loadster.com/manual/load-test-scenarios/) 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](https://loadster.com/guides/spike-testing/) 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](https://loadster.com/guides/endurance-testing/) 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](https://loadster.com/manual/analyzing-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](https://loadster.com/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. ## Frequently Asked Questions ### How far ahead of Black Friday should I load test my ecommerce site? Earlier is better, because the first test usually finds a bottleneck and fixing it takes time. Running your first serious load test four to six weeks before the event leaves room for a few rounds of fix and retest. If you only have a week or two, it's still worth doing; just focus on the checkout flow and the single biggest bottleneck you find. ### How many concurrent users should I load test an online store with? Estimate it from your busiest hour, not your daily average. Multiply the visits you expect in the peak hour by the average session length in hours. For example, 50,000 visits in an hour with a 9-minute (0.15 hour) average session works out to about 7,500 concurrent users. Then add headroom, because traffic within that hour is rarely smooth, especially right when a sale starts or an email goes out. ### Can I load test checkout without placing real orders? Usually, yes. Most teams run checkout load tests against a staging environment, or against production with the payment provider in test or sandbox mode, using test products, test accounts, and test card numbers. Check your payment provider's documentation first, since sandbox environments often have their own rate limits and terms about load testing. ### Should I load test production or staging before Black Friday? Staging is safer and is a good place to find obvious bottlenecks, but it's only useful if it resembles production in size and configuration. Many teams also run at least one carefully scheduled test against production during a quiet period, because that's the only environment with the real CDN, database size, and third-party integrations. If you test production, coordinate with your hosting provider and keep test orders clearly separated. ### Is load testing a hosted platform like Shopify useful? It depends on how much of the stack you control. On a fully hosted platform, the platform operator generally handles core capacity and may restrict load testing in its terms, so check the terms first. Your own apps, custom storefronts, APIs, and third-party integrations are still yours to test. If you host the store yourself, as many WooCommerce and Magento stores do, capacity is your responsibility end to end, and those stores benefit the most from load testing. --- **Next Steps:** Getting ready for Black Friday or a big sale? Try [Load Testing with Loadster](https://loadster.com/load-testing/) 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](https://loadster.com/faqs/maximum-concurrent-bots-or-virtual-users/), 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](https://loadster.com/guides/why-websites-crash-under-traffic/) — the common causes of crashes during high traffic and how to prevent them. * [Spike Testing](https://loadster.com/guides/spike-testing/) — rehearsing a sudden burst of traffic and checking that your site recovers. * [Concurrent Users](https://loadster.com/guides/concurrent-users/) — what concurrent users are and how to calculate them. * [How to Load Test a Website](https://loadster.com/guides/website-load-testing/) — a step-by-step guide to planning and running your first load test.