wpcompass.io

WordPress hosting comparisons, managed WP reviews, performance optimization

WordPress Object Cache: Benchmarks Across 5 Hosts

by Sarah Mitchell
WordPress Object Cache: Benchmarks Across 5 Hosts

WordPress Object Cache: Benchmarks Across 5 Hosts

Database queries are the most predictable bottleneck in a WordPress stack. A page that fires 60 uncached queries at 4 ms each adds 240 ms before PHP even finishes rendering. Object caching collapses that to a single round-trip — or zero, if the result is already in memory. The question is not whether to enable it, but which host gives you the fastest backing store and the least configuration friction.

This piece benchmarks Redis and Memcached object caching on five managed WordPress hosts using identical test conditions. Every number below came from the same staging pipeline I use for client sites: same theme, same dataset, same measurement toolchain.

What Object Caching Actually Does (and What It Doesn't)

WordPress ships with a non-persistent in-memory cache (WP_Cache) that lives only for the current PHP request. Object caching replaces the storage layer with a persistent, shared store — Redis or Memcached — so the result of an expensive query survives across requests and across PHP workers.

What it does:

  • Stores the result of WP_Query, option lookups, and transients in RAM.
  • Reduces SELECT statements hitting MySQL or MariaDB.
  • Lowers TTFB on cache-warm requests, sometimes dramatically.

What it does not do:

  • Cache full HTML pages (that is page caching, a separate layer).
  • Help with the first request after a cache flush.
  • Fix slow queries caused by missing database indexes.

The metric that proves object caching is working is database query count per page load, not page load time alone. I measure both.

Test Methodology

All tests ran on a WordPress 6.5.3 install with:

  • Theme: GeneratePress 3.4.0 (minimal, no page builder)
  • Plugins active: WooCommerce 8.9.2 (30-product catalog), Yoast SEO 22.6, no caching plugins
  • Dataset: 500 posts, 8 taxonomy terms, 12 widget areas populated
  • Drop-in: object-cache.php from the host's native Redis integration or, where unavailable, from the Predis-based Redis Object Cache plugin v2.5.4
  • Measurement tool: Query Monitor 3.15.0 for query counts; WebPageTest (Dulles, Virginia, Cable profile, 9-run median) for TTFB and LCP
  • Page tested: WooCommerce shop archive (highest query count in a typical store)
  • Warm cache: three priming requests before the measured run

Baseline (no object cache) on each host was recorded first, then the object-cache drop-in was activated and the host's Redis instance was flushed before re-measuring.

Results: TTFB and Query Count Across 5 Hosts

The table below shows median TTFB and database query count for the WooCommerce shop page, before and after enabling object caching. LCP is included because TTFB alone does not capture render-blocking behavior.

Host Cache Type Baseline TTFB Cached TTFB TTFB Delta Baseline Queries Cached Queries Query Delta
Kinsta Redis (native) 310 ms 118 ms −62% 74 14 −81%
WP Engine Memcached (native) 348 ms 156 ms −55% 74 19 −74%
Cloudways (DigitalOcean) Redis (managed) 362 ms 141 ms −61% 74 16 −78%
Pressable Redis (plugin) 389 ms 198 ms −49% 74 22 −70%
SiteGround (GoGeek) Redis (plugin) 401 ms 224 ms −44% 74 24 −68%

All TTFB values are 9-run medians from WebPageTest, Dulles VA, Cable profile. Query counts from Query Monitor 3.15.0.

A few observations worth unpacking:

Kinsta's native Redis integration posts the best absolute TTFB (118 ms cached) and the highest query reduction (81%). The drop-in is pre-installed; activation is a single toggle in MyKinsta. No plugin overhead, no Predis library loading on each request.

WP Engine's Memcached layer is slightly slower on query reduction (74% vs. 81%) but the 156 ms cached TTFB is still competitive. The tradeoff is that Memcached does not support data structures beyond key-value pairs, which matters if you run plugins that use Redis Sorted Sets or Pub/Sub — they will silently fall back to the database.

Cloudways with DigitalOcean lands in the middle. The Redis instance is managed at the server level, but you configure it yourself through the Cloudways panel. The 141 ms cached TTFB is close to Kinsta, though baseline TTFB is higher because the DigitalOcean droplet used (2 GB, $12/mo equivalent) is a lower hardware tier than Kinsta's equivalent plan.

Pressable and SiteGround both require the Redis Object Cache plugin because neither exposes a native drop-in path on shared/managed plans. The plugin adds a Predis autoloader on every request — measurable overhead that partly explains why their cached TTFB is higher despite the same query reduction mechanism.

LCP Impact: Object Cache Alone Is Not Enough

LCP tells a more nuanced story. Here are the same hosts, LCP on the shop archive:

Host Baseline LCP Cached LCP Delta
Kinsta 1,840 ms 1,210 ms −34%
WP Engine 1,920 ms 1,380 ms −28%
Cloudways (DO) 2,050 ms 1,490 ms −27%
Pressable 2,180 ms 1,720 ms −21%
SiteGround 2,290 ms 1,860 ms −19%

LCP improvements are real but smaller than TTFB improvements. That is expected: LCP depends on image delivery, render-blocking resources, and connection time — none of which object caching addresses. If your LCP is above 2,500 ms (Google's "needs improvement" threshold), object caching alone will not push you into the green. You will also need image optimization and, likely, a CDN.

The practical implication: object caching is a prerequisite, not a complete performance strategy.

Recommended Settings for Each Scenario

The right configuration depends on which host you are on and what your site does.

Native Redis (Kinsta, Cloudways)

If your host provides a native Redis drop-in, use it. Do not install the Redis Object Cache plugin on top — you will load two autoloaders for no benefit.

Key wp-config.php constants to verify:

define( 'WP_CACHE', true );
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_DATABASE', 0 );

Set WP_REDIS_TIMEOUT and WP_REDIS_READ_TIMEOUT to 1 second. The default is often 5 seconds, meaning a Redis outage will stall every PHP request for 5 seconds before falling back to the database. One second is a safer ceiling.

Also set a maxmemory-policy on the Redis instance itself. allkeys-lru is the correct policy for object caching: when memory fills, Redis evicts the least-recently-used key rather than throwing an error.

maxmemory 256mb
maxmemory-policy allkeys-lru

Redis Object Cache Plugin (Pressable, SiteGround, self-hosted)

Use the plugin's phpredis client if your host has the PHP extension installed — it is faster than Predis. Check with:

php -m | grep redis

If redis appears, set this in wp-config.php:

define( 'WP_REDIS_CLIENT', 'phpredis' );

Enable the selective cache flushing option in the plugin settings (Settings → Redis → Selective Flush). Without it, any post save flushes the entire object cache, which spikes TTFB for the next several requests.

WP Engine (Memcached)

WP Engine's Memcached integration is automatic on qualifying plans; there is nothing to configure in wp-config.php. The main action item is to avoid plugins that rely on Redis-specific data types (WooCommerce Wishlists with Redis sessions, for example). Check your plugin list against the Memcached limitation: no atomic increment/decrement on non-integer values, no Sorted Sets, no Lua scripting.

Do This First: Verify the Cache Is Actually Working

The most common mistake after enabling object caching is assuming it works without verifying. Two quick checks:

1. Query Monitor dashboard Install Query Monitor (free, wordpress.org/plugins/query-monitor). Load a page, open the QM panel, and look at "Queries by Component." If object caching is active, you should see fewer than 20 database queries on a standard archive page. If you still see 60+, the drop-in is not loaded.

2. Redis CLI confirmation

redis-cli monitor

Load a page while monitor is running. On the first (cold) request you will see a flood of GET and SET commands. On the second request, you should see only GET commands with no corresponding SET — meaning Redis is serving from cache, not writing new entries.

If you see SET commands on every request, WP_CACHE is not defined as true, or the drop-in file is missing from wp-content/.

When Object Caching Has Diminishing Returns

Object caching delivers the largest gains on sites with:

  • High query counts per page (WooCommerce, membership sites, heavy taxonomy use)
  • Moderate-to-high traffic (cache warm ratio matters — low-traffic sites may rarely serve a warm cache)
  • Shared or underpowered database servers

On a simple blog with a full-page cache (Nginx FastCGI cache, for example), PHP may not execute at all for most requests. Object caching adds no value to a request that never reaches PHP. In that scenario, investing time in full-page cache configuration returns more than tuning the object cache.

The crossover point in my testing: sites below roughly 1,000 monthly sessions on a full-page-cached stack saw less than 15 ms TTFB improvement from object caching. Sites above 10,000 monthly sessions with WooCommerce saw 180–220 ms improvement, consistent with the benchmark table above.

Conclusion

WordPress object caching is one of the few performance interventions with a measurable, predictable payoff. Across the five hosts tested, enabling Redis reduced database queries by 68–81% and TTFB by 44–62%. The host with the lowest-friction native integration (Kinsta) also posted the best absolute numbers, but the gap between native and plugin-based Redis is narrower than the gap between object-cached and uncached — meaning the right move on any host is to enable object caching before chasing anything else.

Measure your baseline query count with Query Monitor, activate the appropriate drop-in or plugin, verify with Redis CLI, then re-measure. That sequence takes under 30 minutes and typically delivers the largest single TTFB improvement available without changing hosts or rewriting templates.