500 Concurrent Users on WooCommerce: A Store API vs Classic Checkout Load Test

Why This Test Exists

This started with a client project. A high-traffic store was planning a rebuild, and the team split on whether to go all-in on blocks and the Store API or stay with the classic wc-ajax/shortcode stack.

WooCommerce has been pushing block checkout hard since version 8.3. It's the default for new installs in WC 10.x, and the classic shortcode may eventually be deprecated. Meanwhile, 87% of stores still run classic checkout. The migration pitch is better extensibility and a "modern" architecture, but nobody was publishing real load test numbers comparing the two approaches on the same hardware.

I rented a Hetzner CCX33 (~€48/month), stood up two identical WordPress instances with the same catalog and plugins, and ran the same k6 scripts against both. Every test ran at least 3 times. The numbers below are medians across runs.

WooCommerce 10.5+ ships several performance features disabled by default. I turned them all on: HPOS datastore caching, REST API caching, product instance caching, order attribution off. Without them, Store API was 9% slower across the board. With them, the gap narrowed to single digits.

Cart Operations: Store API Handles the Crowd Better

At one user, both handle add-to-cart in 80ms. At 50 concurrent users, still neck and neck. Past 200 VUs, Store API pulls ahead. Not by much on the median, but the tail tells a different story.

Both approaches load the WordPress stack. The difference is what happens after:

• Classic /?wc-ajax=add_to_cart runs WooCommerce's legacy session handling and returns HTML fragments for the mini-cart widget.
• Store API returns a structured JSON response and avoids the template rendering overhead, though it still bootstraps the full REST API layer.

Place Order: Classic's Server Response Is Faster Under Load

Classic's Place Order endpoint responds faster at every load level I tested. By 22% at one user. By 127% at 500. This is the server-side response time for the final "submit" click only, not the full checkout experience (which favors Store API by ~8% due to faster update waits).

Classic reads POST fields from a form and returns a JSON redirect with the order ID. One function call wrapped in validation. Store API parses typed address objects, validates them against a JSON schema, runs payment through a structured pipeline, serializes the complete order response, and returns the full cart state. More work per request. Better API design. Slower response.

The Fidgety Shopper: Where Store API Earns Its Keep

I wrote a k6 script that does exactly this: ~12 cart operations per session. Adds, removes, quantity changes, coupon swaps. Then 200 of these fidgety shoppers hit the server at once.

Frontend Performance: Lighthouse TTI Is Misleading

I ran Lighthouse CI, then measured Real TTI with performance.now() across three CPU throttle levels. The gap between the two metrics is significant.

Mobile Networks: It Depends on Your Customers' Connections

Store API downloads 2x more data on first visit, but its assets split into ~120 small chunks fetchable in parallel over HTTP/2. On fast connections, parallelism beats payload size. On 3G, the extra bytes win.

The Actual Checkout Experience: Store API Feels Faster

I used Puppeteer to simulate what a customer actually does: navigate to checkout, fill every billing field, wait for the totals to recalculate. End-to-end, from page load to "ready to place order."

Caching: Redis Narrows the Gap from 13% to 3.4%

The checkout gap between Classic and Store API shifts depending on your caching stack. I tested four configurations at 50 concurrent users.

With Real Stripe Payments: The Gap Nearly Disappears

All the checkout data above used Cash on Delivery to isolate WooCommerce's processing from payment gateway latency. But real stores use Stripe. I ran the full checkout flow with Stripe's Payment Element on both instances.

Heavy Data: 500K Orders Change the Math

All previous tests ran against a clean store with 9 products and minimal order history. Real stores have large wp_woocommerce_order_itemmeta, wp_usermeta, and coupon tables that change the performance picture. I loaded 500K orders, 100K users, 2M usermeta rows, 200 products, and up to 10K coupons with 500K _used_by entries.

Why Heavy Data Changes the Picture

• Classic's session table becomes a bottleneck. wp_woocommerce_sessions with 500K orders generates more active sessions and row-level lock contention. Store API is stateless.
• Store API benefits more from object caching. With 100K users and 500K orders, Redis stays warm with frequently-accessed data. Store API makes more wp_cache_get() calls, so it benefits disproportionately.
• The wp_posts table at 500K rows hurts Classic cart. Classic's wc-ajax endpoints query wp_posts for product lookups. Store API uses the smaller, better-indexed wc_product_meta_lookup table.

Coupons: A Non-Issue

Going from 50 to 10,000 coupons with 500K _used_by postmeta entries produced zero measurable performance difference. WooCommerce's coupon validation uses (post_id, meta_key) indexed lookups that are O(1) regardless of total table size.

Multisite: Fine Until 500 VU

I set up two WordPress multisites (subdirectory mode, 8 WooCommerce stores each) on the same server. Same Redis, same OLS, same catalog. Then ran the full k6 suite at 1-500 VU.

The Verdict

Neither approach won outright. Classic is faster where it's simple (placing orders, first-visit page load). Store API is more consistent where it's complex (cart operations under load, returning visitor experience, heavy data stores). The six numbers below capture the trade-off.

So Which One Should You Actually Use?

The right answer depends on your store, not these charts.

Extensibility: The Gap That Still Matters

Performance is one axis. The other is how your team customizes the checkout day to day.

Classic is easier to customize today. Add a field: one PHP filter (woocommerce_checkout_fields). Validate it: one action (woocommerce_checkout_process). Save to the order: one hook. 15 years of plugins and Stack Overflow answers back you up. The cost: filter soup. Hooks conflict, ordering matters, debugging cascading filters is miserable.

Block checkout has better architecture and a steeper learning curve. Adding a field requires PHP (ExtendSchema, register_endpoint_data) and JavaScript (Slots & Fills, setExtensionData). Two languages, two steps. But contracts are typed, namespacing prevents conflicts, and the block editor lets non-developers rearrange sections without code. The main compatibility tracking issue is still open, with the WooCommerce team actively working on closing the gap.

The gap is real and documented. Classic hooks like woocommerce_cart_item_visible have no block equivalent yet. Custom fields in block checkout don't apply until the customer selects a country, and complex visibility rules broke in 10.1.0-rc.1 (since fixed). Developers trying custom validation have hit walls that don't exist on classic.

Payment gateways work on both. Stripe, PayPal, Apple Pay, Google Pay, Klarna, Afterpay. Stripe deprecated the old payment form UI in July 2025; the new form works on shortcode pages too.

What I'd Test Next

A v2 of this test would cover:

• WooCommerce 10.7+. The WooCommerce team shipped batch endpoint support for all Store API endpoints in 9.8, and they're actively optimizing the checkout pipeline. Expect: the Place Order gap to narrow, cart batch operations to reduce round-trips on mobile.
• Geographic distribution. All tests hit the server from the same Hetzner datacenter. With real traffic from multiple regions, latency per request increases. Expect: Classic to fare better on high-latency first visits (fewer round-trips), Store API to benefit more from CDN edge caching on return visits.

If you want to run any of these yourself (or reproduce what's already here), the full test suite is open source: github.com/Jorgu5/woocommerce-performance-benchmarks — scripts, Hetzner setup guide, data generators, and every raw result.

Caveats & Findings