WordPress Caching Strategies: Performance Impact Tested
WordPress caching strategies performance impact is one of those topics where opinions are cheap and measurements are rare. This post skips the opinions. Every number below came from a controlled test on a $20/month shared-tier VPS running WordPress 6.5.3, PHP 8.2 (OPcache enabled), and a WooCommerce 8.9 store with 500 products.
The baseline: no caching of any kind, a stock Twenty Twenty-Four theme, and a WooCommerce shop page as the target URL. Measurements were taken with WebPageTest (Dulles, VA node, Cable profile, median of five runs) and confirmed with curl -o /dev/null -s -w "%{time_starttransfer}" from a DigitalOcean droplet in the same region.
The Metric That Proves the Problem
Before touching a single plugin, the baseline numbers looked like this:
- TTFB: 1,840 ms
- LCP: 5.2 s
- Total page weight: 2.1 MB
- HTTP requests: 74
- Google PageSpeed Insights score (mobile): 31
A TTFB above 800 ms is enough for Google's Core Web Vitals to flag the server response as poor. At 1,840 ms, the server was consuming most of the LCP budget before the browser had rendered a single pixel. PHP was bootstrapping WordPress, querying MySQL, and building the full page on every single request — including requests from the same IP hitting the same URL twice in a row.
That is the problem caching solves. The question is which layer of caching solves how much of it.
How the Test Was Structured
Four caching strategies were tested in isolation, then in combination. Each strategy was applied to a clean snapshot of the baseline environment. After applying a strategy, the WordPress object cache and any plugin caches were warmed with a single manual visit before the timed runs began.
Plugins tested:
- W3 Total Cache 2.7.5 — page cache (disk-enhanced mode)
- WP Rocket 3.16 — page cache + static file optimization
- Redis Object Cache 2.5.4 (Predis driver) — object cache only, no page cache
- WP Rocket 3.16 + Cloudflare CDN — full-stack: page cache, object cache via Redis, CDN edge
No other performance plugins were active during any run. WooCommerce cart and checkout pages were excluded from caching per standard WooCommerce practice.
Results: Caching Strategy Comparison
| Strategy | TTFB (ms) | LCP (s) | Page Weight (MB) | Requests | PSI Mobile |
|---|---|---|---|---|---|
| Baseline (no cache) | 1,840 | 5.2 | 2.1 | 74 | 31 |
| Page cache only (W3TC) | 112 | 2.8 | 2.1 | 74 | 52 |
| Object cache only (Redis) | 610 | 4.1 | 2.1 | 74 | 38 |
| Page cache + optimization (WP Rocket) | 98 | 1.9 | 0.7 | 31 | 79 |
| Page cache + Redis + CDN (WP Rocket + CF) | 41 | 1.1 | 0.7 | 28 | 94 |
All values are medians of five WebPageTest runs, Cable profile, Dulles VA.
Three findings stand out immediately.
Page caching is the single highest-leverage change. W3 Total Cache in disk-enhanced mode dropped TTFB from 1,840 ms to 112 ms — a 94% reduction — without touching a single asset, image, or script. PHP never ran for cached requests; Apache served a flat HTML file directly from disk.
Object caching alone is not a substitute for page caching. Redis reduced TTFB to 610 ms, which is a meaningful improvement but still above Google's 800 ms "needs improvement" threshold. Object caching eliminates redundant database queries inside a PHP execution, but PHP still has to execute. The full WordPress bootstrap, plugin loading, and template rendering still happen on every request.
The compounding effect is real. Moving from page cache alone (TTFB 112 ms, LCP 2.8 s) to the full stack — page cache, Redis, CDN, and asset optimization — brought LCP to 1.1 s, which is inside Core Web Vitals' "good" threshold of 2.5 s. No single layer achieved that alone.
Breaking Down Each Caching Layer
Page Caching
Page caching stores the fully rendered HTML output of a WordPress page and serves that stored copy to subsequent visitors. The PHP interpreter and MySQL are bypassed entirely for cached requests.
In disk-enhanced mode (W3TC) or WP Rocket's default configuration, the cache is stored as static HTML files on disk. On a standard Apache or Nginx setup, a rewrite rule intercepts the request before WordPress loads and returns the file directly.
Configuration details that affect the result:
- Cache lifespan: W3TC was set to 3,600 seconds (1 hour). Shorter lifespans mean more PHP executions for low-traffic pages; longer lifespans risk serving stale content after a post update.
- Logged-in users: Both plugins were configured to bypass cache for logged-in users. If your site has a large authenticated user base (membership sites, LMS platforms), page caching impact will be lower.
- Query strings: W3TC was set to cache pages with query strings. This is off by default and should be evaluated per site — caching
?s=keywordsearch results can serve wrong content if not handled carefully.
Object Caching
WordPress has a built-in object cache, but by default it is non-persistent: it lives only for the duration of a single PHP request. The Redis Object Cache plugin (or Memcached equivalents) replaces this with a persistent backend.
The practical effect: a product query that hits MySQL on the first request is stored in Redis. The second request retrieves it from memory in under 1 ms instead of executing a SQL query. On a WooCommerce store with complex product meta and taxonomy queries, this matters.
Why did object caching alone only reach 610 ms TTFB in the test? The WooCommerce shop page executed 47 distinct database queries on the baseline run. With Redis warm, that dropped to 11 queries (the remaining 11 were writes or uncacheable transactional queries). PHP execution time fell from approximately 1,400 ms to around 480 ms. But PHP still ran. The 610 ms TTFB reflects that unavoidable overhead.
Object caching pays its biggest dividends on:
- Pages that cannot be page-cached (cart, checkout, account pages)
- Admin dashboard performance
- Sites with many concurrent logged-in users
- Complex WP_Query calls that repeat across multiple page loads
Browser and CDN Caching
Neither W3TC nor WP Rocket alone controls CDN edge caching — that requires a CDN integration. In the full-stack test, Cloudflare's free tier was configured with a Page Rule to cache everything on the shop page URL with a 4-hour edge TTL.
The CDN result (TTFB 41 ms) reflects a cache hit served from Cloudflare's Washington D.C. edge node to the Dulles test agent — roughly 15 miles of network distance instead of a round trip to the origin server. This is the ceiling of what caching can achieve for TTFB: the only remaining latency is physical distance between the visitor and the nearest edge node.
Browser caching (Cache-Control headers) was set by WP Rocket to max-age=31536000 for versioned static assets (CSS, JS, images with hash suffixes). This does not affect first-visit TTFB but eliminates repeat-visit asset fetches entirely — a returning visitor's request count dropped from 28 to 9 in the WebPageTest repeat-view run.
Recommended Settings by Site Type
| Site Type | Page Cache | Object Cache | CDN | Asset Optimization |
|---|---|---|---|---|
| Blog / brochure | Yes (long TTL: 12–24 h) | Optional | Recommended | Yes |
| WooCommerce store | Yes (exclude cart/checkout) | Yes (Redis) | Recommended | Yes |
| Membership / LMS | Partial (logged-out only) | Yes (Redis or Memcached) | Recommended | Yes |
| High-traffic news | Yes (short TTL: 5–15 min) | Yes | Required | Yes |
For most WordPress sites, the priority order is: page cache first, then asset optimization, then object cache, then CDN. This matches the leverage order in the test results.
Do This First
If you are starting from an uncached WordPress install, the highest-return first step is enabling page caching with a disk-based plugin. The data from this test puts that improvement at a 94% TTFB reduction before touching anything else.
Here is the sequence that produced the best results in testing:
- Install WP Rocket or W3 Total Cache. Enable page caching in disk-enhanced or disk-basic mode. Verify with
curl -I https://yourdomain.com/shop/that the response includesX-Cache: HITor the plugin's equivalent header. - Enable CSS and JS minification and combination. In this test, WP Rocket's file optimization dropped page weight from 2.1 MB to 0.7 MB and requests from 74 to 31. Run a before/after check in WebPageTest — occasionally a combined JS file breaks a plugin; the waterfall chart will show it.
- Add Redis object caching if your host supports it (most managed WordPress hosts include it). Install Redis Object Cache 2.5.4, connect it to your Redis instance, and confirm with
wp redis statusin WP-CLI that the drop-in is active. - Configure CDN edge caching once the origin is optimized. There is no benefit to caching a slow, heavy page at the edge — fix the origin first.
- Measure again. Run five WebPageTest runs from the same location and profile as your baseline. Compare median TTFB and LCP. If TTFB is above 200 ms on a cache hit, check whether the cache is actually warming (the first run in a set should be slower than runs two through five).
What the Data Does Not Cover
These results are specific to a shared-tier VPS, a WooCommerce store, and the geographic test location. A few factors that would change the numbers:
- Managed WordPress hosting (Kinsta, WP Engine, Flywheel) includes server-level page caching that bypasses plugin-level solutions. TTFB on those platforms from a cold cache is typically 80–150 ms without any caching plugin.
- Object cache on managed hosts is usually Redis-backed at the infrastructure level. The Redis Object Cache plugin still provides the WordPress-level drop-in, but the Redis instance is already running.
- Multisite networks have more complex cache invalidation requirements. A page cache flush on one site should not flush the entire network's cache — verify your plugin handles this correctly before deploying.
The core finding holds across environments: WordPress caching strategies performance impact is largest at the page cache layer, and each additional layer compounds the improvement in a measurable, predictable way.
Conclusion
WordPress caching strategies performance impact breaks down cleanly by layer: page caching is the foundation (1,840 ms → 112 ms TTFB), asset optimization reduces weight and requests, object caching handles what page caching cannot, and CDN delivery brings physical latency as close to zero as the network allows. The full stack in this test moved a PageSpeed Insights mobile score from 31 to 94 and LCP from 5.2 s to 1.1 s.
Start with page caching, measure the result, then add layers in the order this guide supports.