A WooCommerce store is not a content site with a shopping cart bolted on. It is a stateful application with write-heavy endpoints, session storage, coupon validation, shipping calculation, and an order pipeline. The pages that matter most cannot be served from a static cache, and the traffic pattern is bursty in a way that a blog's is not.
That is why we test checkout separately. This report covers four hosts from the 2026 load-test series: a 30-minute plateau at 500 concurrent virtual users, a fixed 12,000-product catalogue, a warm Redis object cache, and a mocked payment gateway. The goal was not to crown a winner by a few milliseconds. It was to find where each platform breaks first.
- Rocket.net led checkout at 342 ms p95 and 566 ms p99, with a 0.02% error rate.
- Kinsta followed at 371 ms p95; Cloudways at 388 ms; WP Engine at 412 ms.
- PHP worker queues were the first bottleneck on every host, not CPU.
- Cache purges produced the widest transient tail: a 14-second recovery window on Cloudways versus 8 seconds on Kinsta.
- Headroom matters more than peak benchmark: a host that holds 700 ms at p99 under 500 VUs will feel worse than one that holds 600 ms with capacity to spare.
The workload, precisely
We used k6 to drive the journey, with a custom WooCommerce fixture and a staging clone of a production-shaped store. Each virtual user selected a product, added it to the cart, applied a valid coupon, proceeded to checkout, filled a test address, and submitted an order against Stripe test mode. Think time was randomized between 2 and 7 seconds to avoid a synchronized thundering herd.
We ran the test three times per host on separate days and reported the median run. The variance between runs was larger than the gap between Kinsta and Cloudways, which is why we treat a 10–20 ms difference as noise rather than a decisive win. The gap to WP Engine was consistent across runs.
Checkout results
The table reports checkout request latency only. Browse and add-to-cart were faster because they hit cacheable paths and read-mostly queries. Checkout is where the platform writes sessions and orders, and it is the number a merchant should care about.
| Host | p50 | p95 | p99 | Error rate | Peak RPS |
|---|---|---|---|---|---|
| Rocket.net | 184 | 342 | 566 | 0.02% | 240 |
| Kinsta | 196 | 371 | 612 | 0.04% | 238 |
| Cloudways | 208 | 388 | 704 | 0.11% | 231 |
| WP Engine | 219 | 412 | 738 | 0.09% | 228 |
Load-test data: median of three runs per host in the October 2026 series. Absolute production results will differ with theme, plugins, and payment provider.
Checkout p95 at 500 VUs
Lower is better. Median of three runs.
What breaks first
1. PHP worker queues. Every host showed the same pattern: p95 began to climb while CPU was still around 60–70%. The web server had run out of workers, and requests were waiting in a queue that does not appear in a CPU graph. On Cloudways, the queue grew fastest during the cache-purge test because Redis was cold and every request became a dynamic request.
2. Database write latency. Order creation writes to several tables and fires Action Scheduler jobs. When the write queue deepened, p99 separated from p95. This is the part a page-cache benchmark cannot see. If your store has a heavy order pipeline, test it with realistic order volume, not just product views.
3. Cache stampede. A full-page purge under load sends every worker at the origin at once. The hosts with an integrated edge and a request-collapsing layer recovered faster. The hosts behind a user-managed CDN depended on the cache rules we configured. That is an operational choice, not a platform accident.
4. Third-party callbacks. We mocked the gateway to isolate hosting. In production, the gateway, tax service, and fraud check add latency outside the host's control. Budget for that in your end-to-end checkout target: a 400 ms host response plus a 300 ms authorization is a 700 ms checkout before the browser renders anything.
The cache-purge test
At minute 18 of the plateau we purged the full-page cache and the object cache, then measured how long the store took to return to its pre-purge p95. This simulates a product import, a price update, or a plugin deployment during a traffic spike — all of which happen in real stores.
| Host | Recovery | Peak p95 during purge | Errors during purge |
|---|---|---|---|
| Rocket.net | 6 s | 512 ms | 0.01% |
| Kinsta | 8 s | 548 ms | 0.03% |
| Cloudways | 14 s | 688 ms | 0.21% |
| WP Engine | 11 s | 602 ms | 0.12% |
A purge during peak traffic is an avoidable risk. Schedule imports and deployments outside campaign windows, warm the cache before the doors open, and keep a rollback path.
Sizing your own store
The useful output of a load test is not a rank. It is the point where latency stops being linear. If 500 users produce 388 ms p95 and 750 users produce 1,100 ms, the knee is somewhere between them. Buy capacity to stay below the knee at your expected peak plus a buffer.
A rough worker estimate: multiply peak concurrent shoppers by the share hitting uncached requests, then multiply by the average request duration, and divide by your target utilization. For example, 500 concurrent shoppers × 20% uncached = 100 simultaneous dynamic requests. At 300 ms each and 70% target utilization, you need about 43 workers. That is higher than most entry plans provide.
The practical target: keep checkout p95 under 500 ms at your campaign peak and error rate under 0.1%. Above that, abandon the hunt for the perfect host and add worker headroom, fix the slowest plugin, or move the store to a platform with a higher worker ceiling.
Reproduce it safely
- Clone production to staging. Do not load-test a live store. Use a separate database and a mocked payment gateway.
- Model the journey, not the homepage. Include search, product view, add-to-cart, coupon, cart update, checkout, and order confirmation.
- Ramp slowly. Start at 10% of expected peak and increase in steps. Watch p95 and error rate, not just throughput.
- Warm the cache first. Then run a second pass with a mid-test purge to see recovery behavior.
- Test the rollback. A restore or rollback under load is part of the capacity plan, not an afterthought.
Limitations
This report covers the October 2026 test window. It is a synthetic test with a mocked gateway and a fixed theme. Real stores carry more plugins, more third-party scripts, and more irregular traffic. The test measures host capacity and configuration behavior, not your store's readiness. It also uses a single origin region per host; a globally distributed audience would see different regional tails.
Use the method and the measured results as a baseline, then run the same test against your own staging environment before making a purchasing decision.