WooCommerce Store API · FSE Blocks · WordPress 7.0 · PHP 7.4

WooCommerce Blocks. Instant.

Every WooCommerce block on a page — Product Grid, Product Categories, Filter by Attribute — fires a separate Store API request. Without caching, that cost is paid by every visitor, on every page load, every time.

~38ms
Cache Hit Response
Store API · drop-in
~23×
Faster Than Uncached
drop-in vs full WC round-trip
~860ms
No Cache
median · WordPress + WooCommerce
Store API Results
Every product endpoint. Same story.

Median response time across four WooCommerce Store API endpoints — product listings with different sort orders, product categories, and a single product page. Results are consistent across all catalog routes.

Median response time per endpoint (ms, lower is better)
Frosty Cache HIT — drop-in
No cache (MISS)
Coverage
Catalog cached. Cart protected.

Frosty Cache caches public catalog endpoints and bypasses session-sensitive ones. Anonymous shoppers browsing products get pre-database responses. Cart and checkout routes are always served fresh — they carry per-user session data via Cart-Token that must never be shared across visitors.

Route Used by Cache
/wc/store/v1/products Product Grid block, Product Collection block HIT
/wc/store/v1/products/{id} Single Product block HIT
/wc/store/v1/products/categories Product Categories block, Filter by Category block HIT
/wc/store/v1/cart Cart block, Mini Cart block BYPASS
/wc/store/v1/checkout Checkout block BYPASS
/wc/store/v1/order/{id} Order Confirmation block BYPASS

WP REST Cache does not cache wc/store/v1 endpoints by default — its allowlist only covers wp/v2, confirmed live: requests to wc/store/v1/products against a WP REST Cache install ran ~1.6s on every single request, with no speedup at all. WooCommerce does not register itself with the plugin. Manual configuration through the WP REST Cache admin screen is required before any Store API response is cached, and even then responses are stored as WordPress transients — WordPress still boots on every cache hit. Live-tested on its wp/v2 routes (the same underlying transient mechanism), that’s ~832ms median in production, vs Frosty Cache’s drop-in at ~751ms — see the full live comparison.

Methodology
How these numbers were measured.

🖥 Environment

  • Local by Flywheel
  • WordPress 7.0
  • PHP 7.4
  • WooCommerce 9.x
  • nginx · MySQL 8.4

⚗️ Test method

  • 50 requests per endpoint per mode
  • curl --time-total end-to-end
  • Cache warmed before HIT run
  • MISS uses per-request cache buster

📐 Cache path

  • advanced-cache.php drop-in active
  • HIT exits before WordPress loads
  • No WooCommerce bootstrap on HIT
  • MISS pays full WP + WC boot cost
Production · live demo site · shared hosting
Same story, on a real store.

20 requests per endpoint against a live WooCommerce install on shared hosting. MISS baseline uses skip_cache=1 to bypass the drop-in. HIT is a normal request served by advanced-cache.php. These numbers include full network round-trip time — a shared host under real internet latency, not a local loopback — which is why the gap looks smaller in percentage terms than the local results above even though the drop-in is doing the same job.

Median response time per endpoint — production (ms, lower is better)
Frosty Cache HIT — drop-in
No cache (MISS)
Endpoint Mode min avg median p95
/wc/store/v1/products?per_page=10 MISS 1548 1667 1659 1991
HIT 815 981 990 1034
/wc/store/v1/products?per_page=5&orderby=popularity MISS 1261 1383 1393 1534
HIT 827 930 878 1882
/wc/store/v1/products/categories MISS 1093 1245 1195 2213
HIT 607 716 715 765
/wc/store/v1/products/{id} MISS 1046 1207 1214 1266
HIT 595 883 733 3886

Median saving across the four endpoints: ~39% off TTFB. The p95 outliers above (e.g. 3886ms) are real shared-hosting queuing noise, not cache misses — included here rather than trimmed, because that’s what production actually looks like.

Stack Comparison
WooCommerce Store API vs CoCart v2.

Same four product endpoints, same drop-in, same machine and same live host — the only variable is which API served the response. CoCart’s richer payload (related products, add-to-cart metadata, per-currency formatting) costs a few extra milliseconds on every mode, but the cache path itself is identical.

Endpoint Stack Local HIT Local MISS Live HIT Live MISS
products?per_page=10 WC Store API 38 903 990 1659
CoCart v2 38 997 996 1844
products?per_page=5&orderby=popularity WC Store API 38 897 878 1393
CoCart v2 38 919 874 1583
products/categories WC Store API 37 832 715 1195
CoCart v2 38 847 725 1431
products/{id} WC Store API 37 831 733 1214
CoCart v2 38 864 726 1357

All times in milliseconds, median. Local = Local by Flywheel loopback (no network overhead). Live = production run against a shared-hosting demo site (full network round-trip included).

Also See
More benchmarks

Results for standard WordPress REST API endpoints — posts, pages, and categories. The drop-in reaches ~15ms median there, compared to ~38ms here. The difference is payload size — WooCommerce product responses carry richer data.

WordPress Core Benchmark → CoCart API v2 Benchmark → Frosty Cache vs WP REST Cache →

Ready to cache your
WooCommerce storefront?

Drop-in installation. Works on any WordPress host. Cart always stays fresh.

See Pricing Read the Docs