Will Your Store Survive Black Friday? What Pre-Sale Load Testing Reveals

Most stores do not fail where their owners expect them to. In our pre-sale load tests, the bottleneck sat in one specific layer, and extra server capacity only helps once you know which layer that is.

Black Friday leaves very little room for a slow store. In 2025, US shoppers spent $11.8 billion online on the day. At the busiest point, they were spending $12.5 million every minute, according to Adobe Analytics. When a store slows down in that window, it loses orders at the exact moment demand is highest.

The usual response to that risk is to buy more server capacity and hope for the best. Two recent load tests we ran show why that is a gamble. In the first store, the database gave out while the server still had plenty of room. In the second, the server ran out of processing power while the database barely noticed the traffic.

Both projects were delivered under client confidentiality, so we share rounded figures and no store names.

What Breaks First When We Load-Test Stores?

In these two stores, the first thing to break was the layer doing the most repeated work for every request. That was the database in one store and the PHP application tier in the other.

When I review a load test, the headline response time is only the starting point. What I want to know is which layer reached its limit first, because that decides the fix. These two stores reached their limits in opposite places.

One term comes up throughout. The p95 response time is the time that 95% of requests meet or beat. It shows what your slower shoppers experience, which an average tends to hide.

The WooCommerce Store Where the Database Choked First

This was a multilingual WooCommerce store using a translation plugin. The client had recently moved to a new server, so we load-tested the site in four stages to see how it performed.

With a single user, a page took about 3 seconds to load. Not fast, but manageable.

At just 10 concurrent users, performance dropped sharply:

• Average server response time exceeded 20 seconds.
• The p95 was more than four times the 5-second threshold.
• More than 10% of requests failed.
• Nearly 25% of automated checks failed.

These checks validate things like HTTP status codes and expected page content. A page might load successfully but still fail a check.

What was causing the problem?

Our first suspect was the new server, but monitoring showed that CPU and RAM still had enough capacity.

This pointed us towards the application and database.

Query profiling confirmed the problem:

• The shop page ran nearly 500 database queries per load.
• These queries took more than 8 seconds in total.
• Around half were duplicate queries.

One query alone took almost 5 seconds. It came from a third-party product-sorting plugin that joined the product metadata table four times.

Every visitor opening the shop page triggered that expensive query again.

What did we change?

We made five improvements:

1. Removed the product-sorting plugin.
2. Added database indexes. One index reduced the slow query’s execution time by about 75%.
3. Added Redis object caching to serve repeated queries from memory.
4. Adjusted the translation plugin’s configuration.
5. Tuned the server settings.

What happened after the fixes?

The retest showed significant improvements:

• Average response time dropped by more than 80%.
• The p95 improved by around 70%.
• Failed checks dropped to zero.
• Database queries per page fell by almost 90%.

Despite these improvements, the store was not fully ready for a major sale.

The p95 still exceeded the 5-second target. More importantly, the test stopped at add-to-cart, meaning checkout was never tested under load.

Checkout involves payment processing, stock reservations and order creation. Testing that journey would be the next priority before a sale.

The PrestaShop Store Where the Server Ran Out Before the Database

The second store was an apparel website running PrestaShop on a single 8-core server.

This time, the goal was to check whether the store could handle Black Friday traffic.

We gradually increased the load to the client’s target, pushed it to nearly double that level, and then reduced it to half the target to observe recovery.

The entire test lasted over 90 minutes.

What happened during the test?

At the target load, the store slowed down but remained functional.

• Order placement took up to 40% longer than the target time.
• Server CPU usage exceeded 80%.

When we nearly doubled the target load, the store started failing:

• Around one-third of requests returned HTTP 500 errors.
• The p95 response time exceeded 20 seconds.

What was causing the problem?

Unlike the WooCommerce store, the database was not the bottleneck.

Database monitoring showed low running thread counts and no row-lock waits. Queries were not piling up.

Instead, the problem was in the PHP processing layer.

CPU usage was close to its limit, and pages were not cached.

The server was effectively rebuilding every page for every shopper. As traffic increased, it ran out of processing power.

Checkout, the most demanding process, was the first to miss its performance target.

What did we recommend?

We suggested three improvements:

1. Increase CPU capacity for PHP processing.
2. Enable caching for pages that display the same content to every visitor.
3. Tune the MySQL buffer pool.

These were recommendations only. No retest was performed, so we cannot claim any performance improvement from them.

What happened when traffic dropped?

This was one of the most useful findings.

When traffic returned to half the target:

• Errors stopped within seconds.
• Response times returned to normal within a few minutes.
• No manual server restart was required.

This matters during a major sale.

A store that recovers automatically may lose only a few minutes of sales. A store requiring manual intervention can remain unavailable until someone identifies and fixes the problem.

What These Two Tests Tell Us

Both stores experienced serious performance problems, but for completely different reasons.

The WooCommerce store struggled with database queries, even though its server had spare capacity.

The PrestaShop store ran out of processing power, while its database continued working normally.

Adding more server resources would not have solved the WooCommerce issue. Similarly, database optimisation alone would not have fixed the PrestaShop store.

The lesson is simple: find the actual bottleneck before deciding what to fix.

Why Do Ecommerce Sites Crash Under Black Friday Traffic?

Ecommerce sites crash when more requests arrive at once than one part of the system can handle. That part is usually the database, the application server or a third-party service the checkout depends on.

The specific causes tend to repeat across platforms:

• Sudden surges: A sale email or ad push can bring thousands of shoppers within minutes. Connection pools and server workers have fixed limits. Once they fill up, new requests wait or fail.
• Pages built from scratch on every visit: Without page caching, every product and category view repeats the full work of the application and database.
• Heavy plugin and extension queries: One badly written query slows every page that runs it, as the WooCommerce store showed.
• Third-party services inside checkout: Payment, tax, shipping and fraud checks each add their own response time. Any of them can slow down under load.

Large retailers with big engineering teams are not immune either. Best Buy’s website went down for thousands of shoppers on Black Friday 2025, with more than 1,000 user reports on Downdetector.

Why a Slowdown Can Hurt More Than a Crash

A slowdown is often harder to spot than a crash, especially when monitoring only checks whether the site is up. Orders keep coming in, so the dashboards look healthy. Meanwhile, checkout times creep up and shoppers quietly abandon their carts.

The PrestaShop store showed exactly this at its target load. Orders still went through, but each one took longer than it should have. A full outage sets off alerts within minutes. A slowdown can run for hours before anyone reacts, which is why we track response times alongside uptime.

Which Load Tests Catch These Failures?

Each type of performance test answers a different question, so a pre-sale plan needs more than one. Here is what each test tells you, and where our two stores fit.

Neither of our tests covered sudden spikes or hours of sustained traffic, and Black Friday brings both. Traffic arrives in bursts when emails and ads go out, then stays high for most of the day. A complete pre-sale plan tests for both.

How We Run a Pre-Sale Load Test

We run pre-sale load tests in eight steps, starting from real traffic data and finishing with a run under sale-day conditions. The aim is to find the breaking point before your shoppers do.

1. Agree on pass and fail criteria first. Before any test runs, we set target response times, an acceptable error limit and what counts as a successful order. Without that, results are open to interpretation.
2. Pull last year’s peak traffic. We look at the busiest periods in analytics, not daily averages, because averages hide the spikes that cause failures.
3. Model the load properly. We turn that traffic into arrival rates and session lengths, which the next section explains.
4. Script real shopper journeys. That means browsing, searching, adding to cart and completing checkout, with a mix of products, cart sizes and payment methods.
5. Include third-party services where possible. We use sandbox modes for payment and shipping providers when they are available. We note any service the test can’t reach.
6. Raise the load in stages. A staircase shows where response times start to bend before errors appear.
7. Find the first layer to fail. We record whether the database, the application server or an outside service hit its limit first.
8. Fix one thing at a time, then retest with the same workload. One change per round shows what each fix actually did. The same workload keeps the results comparable.

How Do You Set the Target Load?

Base the target on how many shoppers arrive per minute and how long they stay, not just on last year’s visitor count. This is where many load tests go wrong.

The number of visitors in your busiest minute is not the same as the number of concurrent users. What matters is how many sessions start each minute and how long each session lasts. As a simple example, 600 shoppers arriving per minute who each stay for 5 minutes means about 3,000 shoppers on the site at once.

Most load testing tools can model this directly by setting an arrival rate instead of a fixed number of virtual users. That matters because real shoppers don’t wait for each other. When the store slows down, new shoppers keep arriving anyway. A fixed user count hides that pressure.

Once you have a realistic target, add your expected growth and a safety margin, then test beyond it. For the PrestaShop store, we pushed to nearly double the target to find where it would fail. Testing at the target tells you whether the store passes. Testing above it tells you how much room you have left.

Should You Load-Test in Production?

Sometimes, but only with approval and a controlled plan. Staging environments rarely match production exactly. Caching rules, CDN settings and database size often differ, and those differences change the results.

A production test needs several things in place first:

• Sign-off from the business.
• Agreement from your hosting and service providers.
• A low-traffic window.
• Live monitoring.
• Clear stop conditions, so the test ends the moment real shoppers are affected.

We run most test cycles in a production-like environment, and we only move to production when those conditions are met.

Payment sandboxes deserve a special mention. They let you test your own checkout under load, but they can’t tell you how the live payment provider will perform on Black Friday. For that, talk to the provider about their own capacity and limits.

When to Start, and What “Ready” Looks Like

We suggest starting about eight weeks before the sale. That gives you time for at least two rounds of fixing and retesting before code changes stop.

The WooCommerce store needed five separate changes before its response times came down, and it still needed another round of testing after that. Work like that takes weeks, not days. Here is the schedule we recommend:

• Eight weeks out: Run a baseline load test to find today’s breaking point.
• Six weeks out: Run a stress test above your expected peak to identify the failing layer.
• Four weeks out: Fix, retest with the same workload and confirm your targets at peak load.
• Two weeks out: Start a code freeze, which we recommend for all pre-sale work, and run a final test with your sale-day controls in place.
• Sale week: Monitor live, with a rollback plan ready and the team on standby.

A store is ready when it meets the criteria agreed before testing. In practice, that usually means five things:

• p95 response times meet the agreed target at peak load, for every journey including checkout.
• Errors stay below the agreed limit all the way up to peak load.
• Checkout stays correct under load. Payments succeed, orders are valid and stock levels update accurately.
• No single layer is saturated at peak. For the PrestaShop store, CPU above 80% combined with slow order placement showed the server had no room left for a surge.
• The store recovers on its own once load drops.

How to Avoid an Ecommerce Website Crash on Sale Day

To avoid a crash on sale day, reduce the work each visit creates, limit risky changes and prepare ways to shed load before you need them. Testing tells you where the store breaks. On the day itself, your job is to keep it well away from that point.

• Cache pages that look the same for every visitor, such as product and category pages. Keep cart, checkout and account pages uncached.
• Serve images and static files through a CDN.
• Book any extra server capacity for the sale window in advance.
• Limit code changes in the final two weeks.
• Audit plugins and extensions for heavy database queries.
• Set up a waiting room for traffic beyond your tested capacity.
• Prepare controls that temporarily turn off non-essential features, such as product recommendations or live stock counters on product pages. Keep stock checks at checkout running so orders stay accurate.
• Monitor response times, error rates and server load in real time, not just uptime.
• Have a tested rollback plan for recent deployments.

What If Your Site Still Slows Down on Black Friday?

Reduce the load first, then find the cause. Switch off non-essential features, turn on the waiting room and keep checkout running.

Once the pressure eases, look at the same numbers you watched during testing: CPU, database activity and error rates. They will point you to the layer that is struggling.

When the trouble started right after a recent change, rolling that change back is often the fastest fix. When there was no recent change, a rollback won’t help, and you are better off scaling up or shedding more load.

The PrestaShop test is encouraging here. Once load came down, the store recovered within minutes on its own. Controls that switch off non-essential features let you create that drop deliberately.

Pre-Sale Load Testing With Testscenario

Testscenario runs pre-sale load tests that find the failing layer before your shoppers do.

We hold a 4.9 rating on Clutch from 17 reviews and have completed 81 client engagements. Projects can start within 48 hours.

For the edtech platform EdPrime, our team helped the platform handle 5,000 concurrent users and cut response times by 65%. Our performance testing services cover load, stress and endurance testing, and our ecommerce testing team covers checkout, payments and promotions.

FAQs

What tools are used for Black Friday load testing?

Common choices include Apache JMeter, k6, Gatling and BlazeMeter. The right one depends on your team’s scripting skills, how much load you need to generate and the reporting you want. For realistic Black Friday tests, pick a tool that supports arrival-rate models.

What is the difference between load testing and stress testing?

Load testing checks how the store performs at the traffic you expect. Stress testing pushes past that point to find where and how it breaks. A pre-sale plan needs both.

How do you test checkout without placing real orders?

Use your payment provider’s sandbox or test mode, along with test products and test customer accounts. This lets you run thousands of checkouts and confirm that orders are created correctly and stock updates accurately. Agree the plan with your provider beforehand. Remember that a sandbox shows how your store behaves, not how the live payment network will perform.

What should you do when a load test fails?

Find the layer that failed first before changing anything. Check CPU, memory, database activity and third-party response times at the point where errors began. Fix that bottleneck, then rerun the same test so you can compare the results directly.