Independent Performance Test · WordPress 7.0 · PHP 8.2 · vs WP REST API Cache

Benchmark: 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.

FrostyCache 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 8.2 (Visual C++ 2019)
  • 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)
FrostyCache — drop-in (~15ms)
FrostyCache — 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 FrostyCache’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 · InstaWP · Apache + nginx
Real server. Real network.

30 requests per endpoint against a live WordPress 7.0 / PHP 8.4.12 / Apache server. MISS baseline uses a per-request cache buster to bypass all server-side caching. HIT uses the advanced-cache.php drop-in — WP_CACHE is enabled and FrostyCache owns the drop-in on this host. WordPress never loads on a cache hit. Network RTT from EU to the US server adds ~530ms of overhead per request, which dominates the total time regardless of cache state.

TTFB (Time to First Byte) — Production, 30 requests per endpoint (ms, lower is better)
FrostyCache HIT (drop-in, ~725ms median TTFB)
No Cache / MISS (~1040ms median)

📡 Network conditions

  • EU client → US server (InstaWP)
  • ~490ms overhead per request (DNS + TCP + TLS + 1 RTT)
  • TTFB includes full network round-trip
  • A CDN or geographically close client would show larger relative gains

⚡ Server-side saving

  • MISS server processing: ~510ms (WordPress + database + REST dispatch)
  • HIT server processing: ~195ms (PHP-FPM startup + file read only — no WordPress, no DB)
  • ~315ms eliminated on every cached request
  • WordPress never loads on a drop-in HIT
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 →

Ready to see these numbers
on your site?

Drop-in installation. Works on any WordPress host.

See Pricing Read the Docs