A good online store load test starts with purchase scenarios. You run it on a copy of the store or in an agreed window, and you leave yourself spare time for fixes and a rerun. Mid-September 2026 is the last sensible moment, because Black Friday falls on 27 November, and configuration and code changes still have to fit between the first run and the campaign. The full list of tasks before the campaign is covered in our article on how to prepare Black Friday in your online store. Here we take just one step: checking performance under traffic.
Table of contents
How much traffic can the store handle and why check it before the season?
The test shows at what traffic level the store starts to slow down or throw errors. It is better for you to find that out than for your customers to find it out on campaign day. An ordinary store performance test, done with a page speed tool, describes the visit of a single user. It says nothing about what happens when many shoppers browse the offer, filter products and place orders at the same time. And at that point the result depends on the server and the database, not on image weight.
The goal is a decision, not a report. After the run you should know what to fix first and whether the current server is enough for the season. If the result does not lead there, the scenario was poorly chosen.
Which types of load tests should you choose?
One script is not enough. Different traffic patterns mean different risks, which is described directly in the k6 documentation on test types. In practice a store needs several variants:
- Smoke - checks whether the script works and whether the store copes with a few users.
- Average-load - reproduces a normal sales day. It gives a baseline for the other measurements.
- Stress - raises the load above normal to show where the slowdown begins.
- Spike - a sudden traffic surge test, it simulates a rapid influx of shoppers right after the campaign starts.
- Soak - holds a constant load for a long time and reveals problems that build up slowly.
Keep the load pattern simple: ramp-up, plateau and ramp-down. The type names are conventional and depend on scale. And the tool? In my view, k6: a load test is written in it as a script that you can keep together with the code and run again without changes.
Which purchase scenarios should the test reproduce?
You test the full purchase path, not just the home page. The script should imitate the successive steps of a real customer:
- Arriving from the campaign on a product or category page.
- Using the search and filters.
- Adding a product to the cart.
- Placing the order.
The cart and checkout matter most here, because they are not served from cache. Every request goes to PHP and the database. That is exactly where the store breaks first, even when the home page still loads fast. Take the proportions between scenarios from your own store’s statistics: what share of visitors only browse and what share reach the order. Guessing those shares gives a result that describes a different store than yours.
Where and when to run the test so it does not hurt sales?
On a copy of the store or in an agreed low-traffic window. Never without the hosting provider knowing. A provider that has not been warned may treat the test traffic as an attack and block it, which invalidates the measurement and, in the worse case, also cuts off real customers. On the copy you need to turn off real payments and emails to buyers. Otherwise test orders will land in inboxes and accounting systems.
The test environment should match production: the same plugins, a similar database size and the same server type. While you are at it, compare your current resources with how to choose hosting parameters for a business. The window and the rules of the test are easiest to agree when the store and the website and email hosting are handled by the same team.
What to measure in a WooCommerce load test and what usually needs fixing?
Three things: response time, error rate and database load. You read each one separately for every scenario. An average from the whole run hides the problem, because fast cached pages mask a slow checkout. A WooCommerce load test most often points to the same sources of trouble:
- a cache configuration that skips too many pages or is turned off for logged-in users,
- heavy database queries generated by plugins,
- cron tasks triggered by user visits instead of the server schedule,
- external scripts that the store waits for on every request.
The cost of a single extension can be measured directly: the performance recommendations for WooCommerce include the advice to test the store with the extension enabled and disabled. Sometimes the cause also lies in the code, not in the settings. Then the fixes are done by a team that builds stores on the WooCommerce platform, and for non-standard integrations custom software development helps.
Retesting after fixes and the schedule up to Black Friday
Every fix is confirmed by a rerun of the same scenario. The rule: one change at a time, the same script, the same environment. After several fixes deployed at once you will not know which one worked and which one made something worse.
The order of work from September:
- Smoke and average-load, to check the scripts and set the baseline.
- Fixes resulting from the first measurements, each with a rerun.
- Stress and spike, that is checking the headroom and the reaction to a sudden influx.
- A change freeze before the campaign, with no new plugins or updates.
The scripts should not end up in a drawer after the season. Maintained together with the rest of the tests, in line with what and when to test automatically, they will come in handy with every major change in the store. Then the online store load test becomes a repeatable part of the preparations, not a one-off action before November.
Frequently asked questions
Can a load test be run on a live store?
Yes, but only in an agreed low-traffic window and after informing the hosting provider. A copy of the store that matches production is safer, because on a live store the test traffic slows down real customers and leaves test orders in the system.
How does a spike test differ from a stress test?
A spike test is a rapid influx of users in a very short time. Stress gradually exceeds the normal load and shows where the store starts to slow down. The first checks the reaction to a sudden change, the second the limit of endurance.
Is it enough to test the home page?
No. The home page is usually served from cache and puts almost no load on the server. The cart and the order bypass the cache, so every request involves PHP and the database. They decide whether the store keeps selling under heavy traffic.
