A realistic e-commerce load test reproduces your shop’s peak traffic as it actually arrives: mostly browsing and search, a smaller share adding to cart, and a few percent reaching checkout, each shopper with their own session, cart and products. Build the journey mix from your analytics funnel, give every virtual user distinct data, keep real payments and orders out of the test, and run the load profile your next sale or campaign will produce.
Key Takeaways
- Model the funnel: browsing, search, cart and checkout have very different costs, and only some of them can be cached.
- Most e-commerce failures show up in search, cart, checkout and inventory, which hit the database on every request.
- Give each virtual user distinct products, accounts and carts, or you are testing a warm cache.
- Stub or sandbox payment, tax and shipping providers, and make sure test orders never reach fulfilment or customers.
This page covers what is specific to online shops. For the general method (goals, workload model, think time, load profiles), see how to design load testing scenarios.
What makes e-commerce load testing different?
E-commerce load testing differs from testing a content site or a single API in four ways. Traffic follows a funnel, so most requests are cheap page views and a small share are expensive writes. Shoppers carry state: a session, a cart, often a login and a CSRF token. Checkout depends on third parties such as payment, tax, shipping and fraud services. And peaks come from events you schedule, such as a sale or an email campaign, so they arrive as a step rather than a slow climb.
| Shop area | Cacheable at the CDN? | What it loads | Typical failure under peak |
|---|---|---|---|
| Home, category, product pages | Mostly, for guests | Web servers, CDN, image delivery | Origin overload when the cache is cold or bypassed |
| Search and filters | Rarely | Search engine or database queries | Slow queries, CPU saturation on the search tier |
| Cart (add, update, remove) | No | Sessions, database writes, pricing rules | Session store or database lock contention |
| Checkout and payment | No | Inventory, tax, shipping, payment calls | Third-party timeouts, connection pool exhaustion |
| Account and order history | No | Authenticated database reads | Slow queries on large customer histories |
The practical consequence: a test that sends everyone to the homepage measures your CDN. A test that sends everyone to checkout measures a day that never happens. The mix matters more than the headline user count.
Step 1: Build the journey mix from your funnel
Start from analytics for your busiest recent period, ideally the peak hour of your last sale. A funnel report (in GA4, a funnel exploration) gives the share of sessions that view a product, search, add to cart, begin checkout and purchase. Server or CDN logs give the request rate per URL pattern. Turn those into a small set of journeys with weights.
A worked example with illustrative numbers. Say the peak hour had 36,000 sessions averaging 6 minutes:
- Arrival rate: 36,000 / 3,600 s = 10 new sessions per second.
- Concurrent shoppers (Little’s Law): 10 per second x 360 s = 3,600.
If the funnel shows 55% of sessions only browse, 25% search, 15% add to cart and leave, and 5% buy, the test runs 1,980 browsing users, 900 searching, 540 cart abandoners and 180 buyers at the same time. The concurrent users calculator guide walks through the same arithmetic for other inputs.
Your shares will differ by shop and by event, so measure them rather than borrowing a benchmark. A product drop sends a much larger share straight to checkout than a normal Tuesday does.
Mobile apps belong in the same mix. If 40% of your orders come from an app, that traffic hits your API rather than your pages, so add the app’s API calls as their own journeys at their own share.
Step 2: Script each journey with real shop data
Each journey needs the details that make a shop slow in production:
- Product IDs across the whole catalogue. Draw them from a data file of real SKUs, weighted toward bestsellers but including the long tail. Long-tail products are the ones not in any cache.
- Search terms from your search logs. Include misspellings, zero-result queries and the filter combinations people use. Faceted navigation is often the most expensive request in the shop.
- One account and one cart per virtual user. Shared accounts collapse many carts into one row and hide session store and lock contention. Mix guests and logged-in customers in the proportion analytics shows.
- Dynamic values extracted, not hard-coded. Session cookies, CSRF tokens or form keys, cart IDs and checkout step tokens change per session. Extract them from each response and send them back on the next request, or the script fails at the first form. Parameterization in JMeter covers the data-file side of this.
- Promo codes and price rules. If your sale applies a coupon or automatic discount, exercise that code path. Discount and pricing rules run on every cart change.
- Think time from real pages. Use time-on-page from analytics with some random spread, for example 5 to 20 seconds on a product page. Zero think time turns 3,600 shoppers into far more requests per second than 3,600 people generate.
Step 3: Keep payments, stock and orders safe
Checkout is the journey you most need to test and the easiest one to get wrong.
Payments. Never send load to a payment provider’s live API. Point checkout at the provider’s sandbox if its rate limits allow your test volume (check its documentation first), or replace the payment call with a stub that returns a success after a realistic delay. Do the same for tax, shipping-rate and fraud services you do not run yourself.
Inventory. Test SKUs need stock deep enough that they do not sell out halfway through the run and turn every later checkout into an “out of stock” page. Then run one deliberate variant where many buyers hit the same small set of SKUs at once. That is what a limited drop looks like, and row-level locking on a hot inventory record is a classic checkout failure.
Orders. Make sure test orders never reach fulfilment, your ERP, marketing automation or a customer’s inbox. Flag them (a test customer group or email domain) and clean them up after each run.
Step 4: Choose the load profiles your events will produce
One steady test answers one question. Map each upcoming event to the profile it will produce:
| Event | Load profile | What to look for |
|---|---|---|
| Normal daily peak | Ramp to the peak mix, hold 30 to 60 minutes | Stable percentiles and error rate |
| Email or push campaign | Step from baseline to peak in a minute or two | Autoscaling lag, cold caches, connection pool limits |
| Flash sale or product drop | Sharp spike, checkout-heavy mix, hot SKUs | Inventory locks, queueing, payment timeouts |
| Holiday weekend such as Black Friday | Elevated load held for several hours | Memory growth, connection leaks, log and disk growth |
| Capacity check | Keep raising the rate past the expected peak | The breaking point and how the shop fails |
The campaign and drop rows are spike tests; the holiday weekend row is an endurance (soak) test. Test above your forecast as well as at it, for example at 1.5x to 2x, so you know how much headroom you have when a campaign does better than planned.
Step 5: Prepare the environment, CDN and bot protection
Use a pre-production environment that matches production in the things that limit throughput: instance counts and sizes, database size and indexes, search cluster, cache and session store configuration. A staging catalogue with 200 products will not reproduce the queries of one with 200,000. Anonymize any copy of customer data.
Decide what the CDN does in the test. Running through it reproduces your real cache hit ratio, which is what shoppers experience. Running a second test against the origin directly tells you what happens when the cache is cold or bypassed, which is what happens right after a deploy or a price change. Check your CDN provider’s policy on load tests before you start.
Bot protection is the e-commerce trap that ends many first runs. Rate limits on login, captchas on checkout and WAF bot rules exist to stop exactly the traffic a load test generates. Allowlist the load generators’ IP addresses for the test window, or the report will show your firewall working.
Step 6: Measure each step of the journey
Report results per step, not one number for the whole site: product page, search, add to cart, each checkout step and order confirmation. For each, track p95 and p99 response times and the error rate. Add one business metric: the share of started checkouts that end in a created order. A checkout that returns quickly with a friendly error page looks healthy in latency charts.
On the server side, watch database locks and slow queries, connection pool usage, session store latency, search tier CPU, queue depth for order processing, and cache hit ratio. Record when each degrades relative to the load, because the first resource to saturate is the one to fix.
Watch the front end too. Shoppers judge a page by when it renders, and Core Web Vitals such as LCP can degrade under load even when the HTML response looks fine, because images, scripts and API calls compete for the same servers.
Common e-commerce load testing mistakes
- Every virtual user buys the same product, so the test measures one cached page and one inventory row.
- Every journey starts at the homepage, while real shoppers land on product and category pages from search and ads.
- Only checkout is tested, at a volume no real day produces, while search, the usual first bottleneck, is skipped.
- Live payment or email services are called, or test orders are left in the system.
- The CDN serves everything, so the origin’s limits are never reached.
- The test runs once, a week before the sale, with no time left to fix what it finds. Run the first full test early enough to fix, retest and still have a margin before the code freeze.
Running e-commerce load tests with LoadFocus
LoadFocus load testing runs browser-built tests or your uploaded JMeter and k6 scripts from 25 cloud regions, and splits the load between regions by percentage so you can match where your shoppers are. Paid plans run up to 20,000 concurrent virtual users per test. With Core Web Vitals under load turned on, LoadFocus samples LCP, CLS, FCP and TTFB on your page while virtual users ramp up. The e-commerce checkout under peak traffic template is a starting point, the load generator IP list is on the whitelist IPs page, and if you would rather have the scripts written and the test run for you, LoadFocus load testing services covers that.
Frequently Asked Questions
What is e-commerce load testing?
E-commerce load testing simulates many shoppers using an online store at once (browsing, searching, adding to cart and checking out) to measure response times, errors and capacity before a real traffic peak. It is usually done before sales, campaigns, launches and seasonal peaks such as Black Friday.
How many virtual users do I need to load test an online store?
Calculate it from your own peak: sessions in the peak hour divided by 3,600 gives sessions per second, and multiplying by the average session length in seconds gives concurrent shoppers. Then split that number across journeys by your funnel shares and test above it for headroom.
How do you load test checkout without placing real orders?
Point payment, tax and shipping calls at sandboxes or stubs, use test customer accounts, keep enough stock on test SKUs, and flag test orders so they never reach fulfilment or customer emails. Delete the test orders after each run.
What is the difference between an e-commerce load test and a stress test?
A load test runs your expected peak mix to confirm the shop meets its targets. A stress test keeps increasing the load past that peak to find where and how the shop breaks, for example whether checkout fails cleanly or hangs.
When should you load test before Black Friday?
Early enough to fix what the test finds and test again before your code freeze. Many teams run the first full-scale test several weeks ahead, then repeat it after each significant fix or infrastructure change.
Should you load test the production site?
Prefer a production-like environment. If you must test production, do it at low-traffic hours, with stubbed payments, flagged test orders, generator IPs allowlisted, and someone watching who can stop the test.
Sources
- Google Analytics Help, GA4 funnel exploration: https://support.google.com/analytics/answer/9327974 (October 2026)
- Grafana k6 documentation, load test types (smoke, load, stress, spike, soak, breakpoint): https://grafana.com/docs/k6/latest/testing-guides/test-types/ (October 2026)
- Little, J. D. C. (1961), “A Proof for the Queuing Formula: L = λW”, Operations Research 9(3): https://doi.org/10.1287/opre.9.3.383
