Local and online benchmarks including vs WP REST API Cache

Benchmarks: Before and After

50 curl requests per endpoint, per mode. The median cache hit response for the advanced-cache.php drop-in was 15ms. The uncached baseline was 833ms.

~15ms
Cache Hit Response
pre-database · drop-in
~47×
Faster Than Uncached
drop-in vs full DB round-trip
~200ms
MU Plugin Fallback
post-DB · pre-REST router
~833ms
No Cache
median · full DB round-trip
Response Time
The numbers speak for themselves.

Average response time across all 7 tested endpoints — posts, pages, and categories, both list and single-item requests. Results are consistent regardless of endpoint type.

Average Response Time by Cache Mode (ms, lower is better)
Drop-in HIT (~15ms)
MU Plugin HIT (~200ms)
No Cache / MISS (~843ms)
Consistency
Every endpoint. Same result.

Median response time across all 7 individual endpoints tested. The pattern is identical whether the request is for a list of posts or a single category — the cache layer doesn’t care about the endpoint, only about whether the file exists on disk.

Median Response Time per Endpoint (ms, lower is better)
Drop-in HIT
MU Plugin HIT
No Cache / MISS
Architecture
Why the gap is so large.

Frosty Cache has two cache paths. The drop-in intercepts requests before WordPress even connects to the database. The MU plugin is a fallback for when the drop-in is unavailable — it still exits before the REST router runs, but after the DB connects. The ~185ms difference between the two paths is the cost of the database connection itself.

Drop-in ~15ms
nginx receives request
PHP loads advanced-cache.php
cache file read from disk
↳ Response sent. Exit.
WordPress loads
Database connection
Plugin bootstrap
REST router dispatch
Controller executes
MU Plugin ~200ms
nginx receives request
WordPress loads
Database connection
MU plugin intercepts
cache file read from disk
↳ Response sent. Exit.
Plugin bootstrap
REST router dispatch
Controller executes
Methodology
How these numbers were measured.

All benchmarks were run locally to eliminate network jitter. Production results will vary by server hardware, but the ratios hold — the drop-in is always faster by the cost of the database connection.

🖥 Environment

  • Local by Flywheel (local dev)
  • WordPress 7.0
  • PHP 7.4
  • nginx 1.26
  • MySQL 8.4 via Laragon

⚗️ Test method

  • 50 requests per endpoint per mode
  • curl --time-total measured end-to-end
  • Endpoints warmed before measurement
  • Results reported as min/avg/median/p95/max
  • Charts use median values

📐 Three modes

  • MISS — ?skip_cache=1 forces fresh DB hit every time
  • Drop-in HIT — advanced-cache.php serving pre-DB
  • MU Plugin HIT — fallback path, post-DB, pre-REST
Benchmark command
# MISS baseline (bypasses cache) curl -s -o /dev/null -w “%{time_total}” \ “http://site.local/wp-json/wp/v2/posts?per_page=10&skip_cache=1” # HIT (served by drop-in or MU plugin) curl -s -o /dev/null -w “%{time_total}” \ “http://site.local/wp-json/wp/v2/posts?per_page=10”
Head-to-Head
vs. WP REST API Cache plugin.

WP REST API Cache is the most popular transient-based REST caching plugin. It stores responses in the WordPress database and serves them without executing the REST controller — a real speedup, but WordPress still boots and connects to the database on every request. The drop-in can’t be matched by any plugin that requires WordPress to load first.

Median response time — same endpoints, same machine, same WordPress install (ms, lower is better)
Frosty Cache — drop-in (~15ms)
Frosty Cache — MU plugin fallback (~200ms)
WP REST API Cache (~233ms)
No cache (~851ms)

🔍 Why they’re equal

  • WP REST API Cache stores responses as database transients
  • On a HIT it still boots WordPress, connects to the database, then reads the transient
  • This is the same work Frosty Cache’s MU plugin fallback does — hence ~233ms vs ~200ms
  • No transient-based plugin can beat a pre-database file read

⚡ Why the drop-in wins

  • advanced-cache.php loads before WordPress starts
  • No database connection, no plugin bootstrap, no REST router
  • Pure PHP file I/O — read JSON file, send headers, exit
  • ~15× faster than WP REST API Cache on a HIT
Production · live demo site · shared hosting
Real server. Real network. 47.5% saved.

20 requests per endpoint against a live WordPress 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. This run also confirms the cache-control fix: Frosty Cache now passes through the origin’s own Cache-Control header (public, max-age=86400) instead of overriding it, and X-FrostyCache: HIT/MISS/BYPASS reports the correct state on every response.

47.5%
Saved on TTFB
live · 6 endpoints · 20 req each
751ms
HIT (median)
average across endpoints
1430ms
MISS (median)
average across endpoints
TTFB (Time to First Byte) — Production, 20 requests per endpoint (ms, lower is better)
Frosty Cache HIT (drop-in, ~751ms median TTFB)
No Cache / MISS (~1430ms median)

📡 Network conditions

  • Remote client → shared-hosting origin (InstaWP)
  • Connection + TLS handshake: ~390ms, fixed cost, identical on HIT and MISS
  • TTFB includes the full network round-trip
  • A CDN or geographically closer client would show larger relative gains

⚡ Server-side saving

  • MISS server processing: ~1039ms median (WordPress + database + REST dispatch, on shared hosting)
  • HIT server processing: ~321ms median (drop-in file read, minus connection/TLS overhead)
  • ~718ms eliminated server-side on every cached request (69% reduction)
  • Measured via curl‘s TLS-connect and TTFB timers, isolating server time from network time
Also See
More benchmarks

Same drop-in, same machine — tested against WooCommerce FSE block endpoints (~38ms / ~23×) and CoCart v2 headless catalog endpoints (~38ms / ~24×).

WooCommerce Store API → CoCart API v2 → Frosty Cache vs WP REST Cache →

Ready to see these numbers
on your site?

Drop-in installation. Works on any WordPress host.

See Pricing Read the Docs