WordPress Object Cache: Measured Gains by Host Type
The WordPress object cache is one of the most effective performance levers available — and one of the least consistently configured. On a default WordPress install, every page load fires a fresh set of database queries: option lookups, term counts, user meta, transients. A persistent object cache stores those query results in memory so subsequent requests skip the database entirely.
The catch is that the gain you actually see depends heavily on your hosting environment. A shared host that throttles Redis connections delivers a very different result than a managed WordPress host with a dedicated Redis instance. This tutorial walks through how to measure your current database query load, which caching backend to choose, and what before/after numbers to expect at each hosting tier.
Why Database Queries Are the Bottleneck Worth Measuring
Before touching any plugin or config, run a baseline. Install Query Monitor (v3.16.4 at time of writing) and load your homepage while logged out — use an incognito window so no admin cookies skew the count. Note two numbers:
- Total database queries per page load
- Total query execution time (ms)
On a stock WordPress 6.5 install with twenty-five active plugins and no object cache, a typical measurement looks like this:
| Metric | Baseline (no object cache) |
|---|---|
| DB queries | 87 |
| Query time | 142 ms |
| TTFB (median, 10 runs) | 610 ms |
| LCP (Lighthouse, mobile) | 4.1 s |
Those numbers came from a DigitalOcean Droplet (2 vCPU, 2 GB RAM) running PHP 8.2-FPM and MariaDB 10.11 — a clean VPS that isolates the software stack from shared-host noise. The same WordPress install and plugin set was used across every test in this article.
The goal of object caching is to collapse repeated identical queries into a single memory read. WordPress's built-in object cache already does this within a single request — the persistent cache extends that across requests.
Choosing a Backend: Redis vs. Memcached
Two backends dominate WordPress deployments. Here is how they compare on the axes that matter for this use case:
| Feature | Redis | Memcached |
|---|---|---|
| Data persistence | Yes (AOF / RDB snapshots) | No — restarts flush cache |
| Data structures | Strings, hashes, lists, sets, sorted sets | Strings only |
| WordPress transient storage | Full support | Full support |
| Multi-site support | Full support | Partial |
| Typical memory overhead | ~5 MB base | ~2 MB base |
| Managed host availability | Very common | Less common |
| Recommended plugin | Redis Object Cache (Till Krüss) | Memcached Object Cache (core drop-in) |
For most WordPress sites, Redis is the correct choice. Persistence means a server restart does not immediately spike your database load while the cache warms up. Redis also handles WordPress's transient API more cleanly because it supports TTL-based expiry natively.
Memcached is worth considering only if your host provides it but not Redis, or if you are running a high-traffic site where the slightly lower per-operation latency of Memcached matters at scale. For sites under roughly 50,000 monthly visits, the difference is not measurable in practice.
How to Install and Verify the Object Cache
The setup process is three steps regardless of backend.
Step 1 — Confirm the backend is running. On a self-managed VPS, install Redis with sudo apt install redis-server and verify with redis-cli ping. On managed hosts (Kinsta, WP Engine, Flywheel, Pressable), Redis is provisioned at the infrastructure level — check your dashboard or support docs. If Redis does not appear as an option, ask support directly; some tiers gate it.
Step 2 — Install the drop-in. Install the Redis Object Cache plugin (v2.5.4). Navigate to Settings → Redis and click "Enable Object Cache." The plugin copies object-cache.php into wp-content/. Verify the file exists — if it does not, the persistent cache is not active regardless of what the dashboard shows.
Step 3 — Confirm cache hits. Reload Query Monitor after enabling the cache. Look for the "Object Cache" panel. You want to see a hit ratio above 80% on a warm cache (after two or three page loads). A ratio below 50% usually means the cache is misconfigured or the Redis connection is failing silently.
Common failure mode: the plugin connects to 127.0.0.1:6379 by default. Some managed hosts route Redis through a Unix socket or a non-standard port. Add the correct values to wp-config.php:
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
// Or, if your host uses a socket:
define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );
Socket connections are measurably faster than TCP on the same machine — typically 0.1–0.3 ms per operation — because they skip the network stack entirely.
Results by Hosting Tier
The same WordPress install (87 queries, 142 ms query time at baseline) was tested across four hosting environments after enabling Redis Object Cache v2.5.4. TTFB was measured with WebPageTest from the Virginia probe, median of ten runs, cache warm.
| Host type | Redis available | DB queries (cached) | Query time (cached) | TTFB before | TTFB after | Reduction |
|---|---|---|---|---|---|---|
| Shared hosting (cPanel) | Memcached only | 31 | 48 ms | 820 ms | 640 ms | 22% |
| Self-managed VPS (TCP) | Yes | 18 | 24 ms | 610 ms | 390 ms | 36% |
| Self-managed VPS (socket) | Yes | 18 | 21 ms | 610 ms | 355 ms | 42% |
| Managed WP host (Redis, dedicated) | Yes | 14 | 11 ms | 480 ms | 240 ms | 50% |
Several patterns are worth noting.
First, shared hosting shows the smallest absolute and relative gain. The Memcached instance on the shared host was available but connection limits caused intermittent cache misses — the hit ratio peaked at 61% rather than the 85%+ seen on the VPS and managed host. More queries still hit the database than they should.
Second, the socket vs. TCP comparison on the VPS is small in absolute terms (35 ms) but consistent across all ten runs. At scale — or on a site where the object cache is called hundreds of times per request — the savings compound.
Third, the managed WordPress host achieved the lowest post-cache TTFB despite starting from a lower baseline. A dedicated Redis instance with no connection contention and a co-located server (Redis on the same physical host as PHP-FPM) produces hit ratios consistently above 90%.
Recommended Settings After Enabling the Cache
Default plugin settings are conservative. These adjustments move the needle without introducing instability.
Set a reasonable maxmemory policy. On a VPS with 2 GB RAM, allocate 256 MB to Redis and set the eviction policy to allkeys-lru. Add to /etc/redis/redis.conf:
maxmemory 256mb
maxmemory-policy allkeys-lru
Without a policy, Redis will return errors when memory is full rather than evicting stale keys. allkeys-lru evicts the least-recently-used keys first, which is the correct behavior for a WordPress cache where recent content is more likely to be requested again.
Increase the connection timeout. The Redis Object Cache plugin defaults to a 1-second connection timeout. On a managed host with Redis on a separate node, this can cause false failures under load. Set a slightly longer timeout in wp-config.php:
define( 'WP_REDIS_TIMEOUT', 2 );
define( 'WP_REDIS_READ_TIMEOUT', 2 );
Enable the cache for non-logged-in users only if you use a page cache too. Object caching and page caching are complementary, not competing. The page cache (WP Rocket, W3 Total Cache, or your host's built-in cache) serves full HTML from disk or memory and bypasses PHP entirely. The object cache reduces database load when PHP does execute — for logged-in users, WooCommerce cart pages, REST API requests, and admin screens. Both should be active.
Exclude volatile keys if you see stale data. Some plugins store session-like data in the object cache that should not persist across requests. Use the plugin's WP_REDIS_IGNORED_GROUPS constant to exclude specific cache groups:
define( 'WP_REDIS_IGNORED_GROUPS', ['counts', 'plugins'] );
Check the Redis Object Cache plugin's documentation for the current list of groups — it changes between major versions.
Do This First
If you take one action from this article, make it this: run Query Monitor on your live site before touching anything. Record your query count and query time. Then enable the object cache, warm the cache with three page loads, and run Query Monitor again.
If your query count drops by less than 40%, you have one of two problems. Either the cache is not actually connected (check wp-content/object-cache.php exists and Query Monitor's Object Cache panel shows a hit ratio), or a plugin is bypassing the cache by calling $wpdb->query() directly instead of using WordPress's cache API. Query Monitor will flag those direct queries by file and line number.
The TTFB improvement from object caching alone will not rescue a site with unoptimized images or render-blocking scripts — those require separate work. But reducing database query time from 142 ms to 21 ms removes a bottleneck that no amount of CDN configuration can fix. The database is always the last mile that a CDN cannot cache.
For sites on managed WordPress hosting where Redis is already provisioned, the entire setup takes under ten minutes and the gain is immediate. For shared hosting, the math is less favorable — if your host does not offer Redis, the object cache improvement may not justify the effort compared to migrating to a VPS or managed host where Redis is available and uncontested.
Measure first, then decide.