Benchmark · last run reviewed September 2026 · re-run quarterly
WooCommerce performance benchmark: 236 ms cart, 321 ms checkout, 7,861 orders in under two minutes.
This is the test behind every performance number Urumi quotes. It is a full shopping journey, not a homepage ping; it runs with the edge cache disabled so the origin takes every request; and the script is public so anyone can run it against any host and compare like for like.
Results
| Measure | Result | Condition |
|---|---|---|
| Add-to-cart response, median | 236 ms | edge cache disabled, origin serves every request |
| Checkout response, median | 321 ms | edge cache disabled, origin serves every request |
| Orders completed | 7,861 | in under two minutes at peak arrival rate |
| Production: grüum, peak weeks | 1.2M requests/day · 16× baseline · 0 incidents | live store, not synthetic |
| Production: grüum page loads | 4.0 s → 0.3 s cached · 5.7 s → 0.4 s uncached | before/after migration to Urumi |
| Production: Do Amore | 5.9 s → 0.9 s pages · 8.1 s → 0.67 s order edits | custom store: ring builder, diamond search, partial payments |
Only medians are published from the synthetic run. Percentiles (p95, p99) will be published with the next scheduled run alongside the raw k6 summary; we would rather publish less than publish numbers we cannot hand you the file for.
Method
- Tool: Grafana k6, a single
ramping-arrival-ratescenario. Arrival rate rather than fixed virtual users, because a fixed VU count lets a slow store throttle its own test; arrival rate keeps pressure constant the way real traffic does. - Journey: load a product page → add to cart through the WooCommerce Store API (
/wp-json/wc/store/v1) → place the order at checkout. Each request is tagged so cart and checkout are measured separately. - Load shape: 20 journeys/minute ramping to 200 over three minutes, to 600 over five minutes, then down to zero over two — the shape of a launch or a campaign send, not a flat line.
- Thresholds: cart p95 under 800 ms, checkout p95 under 1,500 ms and p99 under 3,000 ms, failed requests under 1%, checks passing above 99%. The run is only reported if every threshold holds.
- Cache: Cloudflare edge cache disabled for the run. Cached numbers flatter every host equally; the origin under load is what separates them.
Environment
A standard Urumi store on production infrastructure, the same configuration a customer gets: horizontally auto-scaled PHP workers across multi-zone Google Cloud, MySQL 8.4, and the platform's WooCommerce-aware cache layer in front of the origin (bypassed for this run). No test-only tuning. The store carried a real catalogue and a standard payment gateway in test mode.
Limits, stated plainly
- This is our run on our platform. It is published with the method and script precisely because that is not the same as an independent test. Urumi is entering the Review Signal (wphostingbenchmarks.com) WooCommerce and Enterprise tiers for 2027.
- One scenario, one catalogue. A store with a heavy configurator or dozens of checkout plugins will see different absolute numbers; the comparison that holds is same script, same thresholds, different host.
- Medians only, for now. The next run publishes the k6 summary JSON.
Run it yourself
The script is public: scripts/k6-woocommerce/shopping-journey.js. Point it at a staging copy of your store with the edge cache disabled and keep the thresholds:
k6 run -e BASE_URL=https://staging.example.com -e PRODUCT_ID=123 -e PRODUCT_URL=/product/test-item/ shopping-journey.jsHow to read the output, and why the arrival-rate executor matters, is in How to load test WooCommerce with k6. If you re-run it and get different numbers, tell us: [email protected].
Frequently asked questions
What do the 236 ms and 321 ms figures measure?
Median server response for the add-to-cart and checkout requests of a full shopping journey, with the edge cache disabled so the origin serves every request. Medians are published; percentiles will follow with the next scheduled run.
Is this benchmark independent?
No. It is our own run on our own platform, which is why the method and script are published in full and why Urumi is entering the Review Signal WooCommerce and Enterprise tiers for 2027. Treat the numbers as a claim you can check, not a verdict.
Can I run the same test against my current host?
Yes. The k6 script is public. Run it against a staging copy of your store with the edge cache disabled, keep the thresholds, and compare medians like for like.
How does the benchmark relate to the production numbers?
The load test is synthetic and controlled. The production figures — 1.2M requests a day and 16× baseline load with zero incidents through peak weeks for grüum — come from a live store and are the stronger evidence; the benchmark explains why the platform behaves that way.
Built by the people who built WooCommerce core.
We built WooCommerce core at Automattic — the parts that matter in production: performance, payments, reliability. Naman led Payments and WooCommerce releases to 4.5M merchants; Vedanshu led HPOS, Taxes, and Shipping.
See the WooCommerce platform · grüum case study · Talk to sales