Measuring the Performance Win

June 5, 2026

How to quantify what you gain by caching catalogue pages with Super Speedy AJAX Prices instead of excluding them from cache. The headline metric is time to first byte (TTFB) on shop/product/category pages, because that’s what changes when a page goes from “PHP renders it every time” to “served as cached HTML.”

What actually changes

  • Without caching (pages excluded): every catalogue request runs WordPress + WooCommerce in PHP — database queries, template rendering — before the browser gets a single byte. TTFB is high and scales badly under load.
  • With caching + this plugin: the catalogue HTML is served straight from cache (fast, flat TTFB), and the only per-visitor work is one lightweight AJAX call for prices after the page has already started rendering.

So you’re measuring two things: the HTML TTFB drop, and confirming the AJAX call is cheap and doesn’t claw the win back.

Quick measurement with curl

Measure TTFB of a category page before and after enabling caching. Run each a few times and take the best (warm-cache) number:

# TTFB of the page HTML
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s  Total: %{time_total}s\n' \
  'https://your-store.test/product-category/example/'
  • Before (pages excluded from cache): note the TTFB.
  • After (cached): re-run. On a cache HIT, TTFB should drop dramatically (often from hundreds of ms / seconds to tens of ms).

Confirm you’re actually hitting cache by checking the response headers (curl -I) for your cache’s HIT marker (x-cache: HIT, a WP Super Cache footer comment, etc.).

Measuring the AJAX call

The price request should be small and fast. In Chrome DevTools → Network:

  1. Load a cached category page.
  2. Find the admin-ajax.php request with action=get_wc_prices.
  3. Note its Time and Size. It’s one request covering every product on the page; it should be well under the time the full uncached page used to take.

If that request is slow, check: is stock refresh on (a little more work — see Live Stock Refresh)? Are there an unusually large number of products on the page (the batch is capped at 200 by default — see Developer Reference)?

A fair before/after test

To compare like for like:

  1. Baseline: with catalogue pages excluded from cache, measure TTFB on a representative category page (warm).
  2. Switch: follow Migrating from “Exclude Pages” to “Cache Everything”.
  3. After: measure TTFB on the same page (cache HIT), and record the get_wc_prices time/size.
  4. Compare. The meaningful win is HTML TTFB before vs HTML TTFB after — the AJAX call happens after the page is already painting, so it doesn’t delay first render.

Tools beyond curl

  • Browser DevTools (Lighthouse / Performance): check TTFB, and that Largest Contentful Paint isn’t waiting on the price swap (it shouldn’t be — the cached price renders immediately).
  • WebPageTest / GTmetrix: good for repeated, location-specific TTFB and waterfall views showing the cached HTML arriving fast and the AJAX call landing afterwards.
  • Load testing (k6, ab, siege): the biggest real-world win is under concurrency — cached HTML serves flat while uncached PHP rendering degrades. Test requests/sec on a category URL before vs after.

What “good” looks like

  • Catalogue HTML TTFB is a small, flat number on cache HITs, regardless of catalogue size or traffic.
  • The get_wc_prices request is a single, small JSON response that resolves shortly after the page paints.
  • Prices on screen still match checkout (correctness preserved — see Troubleshooting if not).

Note: this plugin doesn’t ship its own benchmarking tool. The measurements above use standard web-performance tooling so your numbers are comparable to any other before/after test.

×
▲
▼
1/1