wpcompass.io

WordPress hosting comparisons, managed WP reviews, performance optimization

WordPress Caching Strategy Testing: A Benchmark Guide

by Sarah Mitchell
WordPress Caching Strategy Testing: A Benchmark Guide

WordPress Caching Strategy Testing: A Benchmark Guide

TTFB on an uncached WordPress page routinely lands between 400 ms and 900 ms on shared hosting. Run the same request through a well-configured page cache and that number drops to under 80 ms. The gap is real, but the question most site owners skip is: which caching strategy produced that result, and will it hold under your specific stack?

WordPress caching strategy testing answers that question with measured data instead of vendor promises. This guide documents the method I use — the same staging-to-production pipeline I ran at an agency managing 200 sites — and presents benchmark results across four common configurations.

Why Caching Strategy Testing Matters Before You Deploy

Every hosting panel and plugin readme claims dramatic speed improvements. The problem is that those numbers come from controlled demos, not your theme, your plugins, or your database query load. A caching layer that reduces TTFB by 70% on a vanilla Twenty Twenty-Four install may reduce it by only 30% on a WooCommerce store with 12 active plugins and a custom checkout flow.

Before committing to a configuration in production, you need three things:

  1. A repeatable test environment that mirrors production.
  2. A baseline measurement with caching fully disabled.
  3. Isolated variable changes — one caching layer at a time.

Skipping any of these turns your optimization work into guesswork.

Test Environment and Measurement Method

All benchmarks below were collected on a single staging server: a 2-vCPU / 4 GB RAM VPS running Ubuntu 22.04, Nginx 1.24, PHP 8.2 (php-fpm), MySQL 8.0, and WordPress 6.5.3. The theme was Kadence 1.2.8 with Kadence Blocks. WooCommerce 8.9.1 was active with 500 products and a 15-item cart session to simulate a logged-in shopper.

Measurement tools:

  • k6 for load testing: 50 virtual users, 2-minute sustained run.
  • WebPageTest (Dulles, VA node, cable profile) for Core Web Vitals — 9 runs per config, median taken.
  • curl -o /dev/null -s -w "%{time_starttransfer}" for raw TTFB spot checks, 30 samples averaged.

Each configuration was tested in sequence with a 10-minute warm-up period after activation. Object cache was flushed and page cache was cleared between each config change. PHP OPcache remained enabled throughout — it is not a variable here because disabling it would skew results away from any realistic production server.

The Four Caching Configurations Tested

Config 1 — Baseline (No Page Cache)

WordPress with no page caching plugin, no server-level cache, and no CDN. Object cache used WordPress's default non-persistent cache. This is the starting point every metric is measured against.

Baseline results (median of 30 curl samples):

  • TTFB: 612 ms
  • LCP (WebPageTest): 3.8 s
  • k6 95th-percentile response time: 1,240 ms

Config 2 — PHP-Based Page Cache (WP Rocket 3.16)

WP Rocket 3.16 with HTML caching enabled, browser caching headers set, and Gzip compression on. Minification and file combination were left off to isolate the page cache effect. Cache lifespan set to 10 hours. Separate cache for mobile enabled.

Config 3 — Server-Level FastCGI Cache (Nginx)

Nginx FastCGI cache configured with a 1 GB cache zone, fastcgi_cache_valid 200 10h, and cache bypass rules for logged-in users and WooCommerce cart/checkout pages. No WordPress caching plugin active. A small Nginx helper plugin (Nginx Cache 1.0.5) was used only to send purge signals on post save.

Config 4 — Object Cache Layer Added (Redis + WP Rocket)

Config 2 (WP Rocket) plus Redis 7.0 as a persistent object cache via the Redis Object Cache plugin 2.5.2. This tests whether adding a database-query cache on top of a page cache produces measurable gains for the page-cache miss scenario (logged-in users, cart pages).

Benchmark Results

Configuration Median TTFB LCP (WebPageTest) k6 p95 Response Cache Hit Rate
Baseline (no cache) 612 ms 3.8 s 1,240 ms —
WP Rocket 3.16 (PHP cache) 68 ms 1.9 s 142 ms 94%
Nginx FastCGI cache 41 ms 1.7 s 98 ms 96%
Nginx FastCGI + Redis object cache 39 ms / 190 ms* 1.7 s 101 ms 96% / —

*Two TTFB figures for Config 4: 39 ms on cache-hit requests, 190 ms on cache-miss requests (logged-in WooCommerce sessions). The Redis layer reduced cache-miss TTFB from 612 ms to 190 ms — a 69% improvement on the hardest case.

Before → after summary: Moving from no cache to the best full-stack configuration (Nginx FastCGI + Redis) reduced median TTFB from 612 ms to 39 ms on cacheable pages — an 93.6% reduction. LCP moved from 3.8 s to 1.7 s, crossing the "needs improvement" threshold into the "good" range per Core Web Vitals scoring.

What the Numbers Actually Tell You

Server-level cache beats PHP-level cache on raw speed. Nginx FastCGI cache served cached pages at 41 ms vs. WP Rocket's 68 ms. The reason is straightforward: FastCGI cache serves a static file from disk before PHP ever starts. WP Rocket still boots PHP and WordPress, checks cache validity, then returns the cached HTML. Both are dramatically better than no cache, but the gap is meaningful at scale.

WP Rocket is the stronger choice when you lack server access. On managed WordPress hosts where you cannot configure Nginx directives, a PHP-based page cache is your ceiling. WP Rocket at 68 ms TTFB is still a 88.9% improvement over baseline. The plugin also handles cache warming, mobile cache separation, and CDN integration in a single interface — operational advantages that raw FastCGI numbers do not capture.

Redis matters most for logged-in users and dynamic pages. On cacheable pages, adding Redis to Config 3 changed TTFB by only 2 ms (41 ms → 39 ms). The real gain appeared on cache-miss requests: 612 ms → 190 ms. For a WooCommerce store where every cart and checkout page bypasses the page cache, Redis object caching is not optional — it is the primary performance lever.

Cache hit rate is the metric most site owners ignore. Config 2 and Config 3 both exceeded 90% hit rates on a public product catalog. If your hit rate is below 80%, more aggressive caching configuration will not help — you need to investigate what is forcing cache bypasses (query strings, cookies, logged-in user detection).

Recommended Settings by Stack

Stack Page Cache Object Cache Notes
Shared hosting, no server access WP Rocket or W3 Total Cache None or Memcached if host provides it Confirm host does not run its own conflicting cache
VPS / cloud, Nginx Nginx FastCGI cache Redis 7+ Use a purge plugin; set bypass rules for WooCommerce
Managed WP host (e.g., Kinsta, WP Engine) Host-provided (do not add a second layer) Host-provided Redis Adding WP Rocket page cache on top often degrades hit rates
High-traffic WooCommerce Nginx FastCGI cache Redis with persistent connections Cache logged-in catalog pages if cart cookie is absent

How to Run Your Own WordPress Caching Strategy Testing

The method above is reproducible. Here is the condensed version:

Step 1 — Build a staging mirror. Use a plugin like WP Migrate or a host snapshot to clone production. The test environment must match production's PHP version, active plugins, and database row count. A clean install will produce numbers that do not transfer.

Step 2 — Establish a true baseline. Disable all caching: deactivate every caching plugin, disable any server-level cache (comment out FastCGI cache blocks in Nginx, disable Varnish), and flush Redis/Memcached if present. Run 30 curl TTFB samples and record the median. This number is your anchor.

Step 3 — Change one variable at a time. Activate one caching layer, warm the cache with a crawl (Screaming Frog or wget --spider), then run your full test suite. Record results. Deactivate, flush, repeat for the next configuration. Changing two things at once makes it impossible to attribute the delta.

Step 4 — Test the cache-miss path explicitly. Add a unique query string to force a cache bypass (?nocache=1 or log in as a test user). Record TTFB on those requests separately. This reveals how your stack performs for logged-in users and dynamic pages — often the majority of your revenue-generating sessions on a WooCommerce site.

Step 5 — Verify cache hit rate. WP Rocket's dashboard shows hit/miss counts. For Nginx FastCGI, add add_header X-Cache-Status $upstream_cache_status; to your server block and check response headers with curl -I. A hit rate below 85% warrants a cache bypass audit before any other optimization.

Step 6 — Promote the winning config to production during low-traffic hours. Monitor TTFB via your uptime tool (UptimeRobot's response time graph works for this) for 24 hours. Real traffic patterns — crawlers, logged-in editors, WooCommerce sessions — will surface cache bypass issues that staging did not.

Do This First

If you have not run WordPress caching strategy testing on your current setup, start with a single curl loop against your live homepage:

for i in $(seq 1 30); do curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yourdomain.com/; done | awk '{sum+=$1} END {print "Median approx:", sum/NR}'

If that average exceeds 200 ms, you have a measurable problem that a properly configured caching layer will address. If it is already under 100 ms, the next constraint is likely render-blocking resources or image payload — not cache configuration.

The benchmark data here gives you a realistic range: expect 85–94% TTFB reduction on cacheable pages when moving from no cache to a server-level or PHP page cache. Expect an additional 60–70% reduction on cache-miss paths when adding a Redis object cache to your stack. Those are the numbers to hold your own results against.