WordPress Object Caching with Redis: Speed Up Your Site at the Database Level

Most WordPress speed guides focus on page caching — storing fully rendered HTML so the server skips PHP and database work for repeat visitors. That’s a great start, but there’s another layer of caching that can make a significant difference: object caching.

Object caching stores the results of expensive database queries and PHP computations in memory. Without it, WordPress re-runs those queries on every page load, even when the data hasn’t changed. With a persistent object cache backed by Redis, those results are stored in fast in-memory storage and reused across requests.

How WordPress Object Caching Works

WordPress includes a built-in object cache (WP_Object_Cache), but by default it only lasts for a single page request. Every new request starts fresh — no memory of what was computed before.

A persistent object cache extends this so cached objects survive across requests. Redis is the most widely used backend for this because it’s fast, supports complex data structures, and handles expiration cleanly.

When Redis is connected to WordPress:

1. WordPress checks Redis before querying the database
2. If the data is in Redis (a “cache hit”), it returns immediately
3. If not (a “cache miss”), WordPress queries the database and stores the result in Redis for next time

For sites with high traffic or complex queries — WooCommerce stores, membership sites, sites with many plugins — this can cut database queries by 50–90% on cached requests.

What Gets Stored in the Object Cache

WordPress stores a wide range of things in the object cache, including:

• Post data and post metadata
• User data and capabilities
• Term/taxonomy queries
• Options (get_option() calls — WordPress makes hundreds of these per request)
• Transients (when stored externally)
• Theme and plugin data

Plugins like WooCommerce add their own cache groups too — product data, cart sessions, and more all benefit from a persistent cache.

Setting Up Redis Object Caching in WordPress

Step 1: Check if Redis is Available

Many managed WordPress hosts — including Rocket.net — provide Redis as part of their hosting environment. If you’re on a host that includes Redis, you may just need to enable it rather than install anything yourself.

On a VPS or unmanaged server, install Redis:

# Ubuntu/Debian
sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server

Verify it’s running:

redis-cli ping
# Should return: PONG

Step 2: Install a Redis Object Cache Plugin

The most widely used plugin is Redis Object Cache by Till Krüss. Install it from the WordPress plugin directory or via WP-CLI:

wp plugin install redis-cache --activate

Step 3: Configure the Connection

By default, the plugin connects to 127.0.0.1:6379. If your Redis instance is on the same server with default settings, no extra configuration is needed.

For custom setups, add to wp-config.php:

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); // Redis database index

If your Redis instance requires a password:

define('WP_REDIS_PASSWORD', 'your-redis-password');

Step 4: Enable the Cache

From the WordPress dashboard, go to Settings → Redis and click Enable Object Cache. This drops a wp-content/object-cache.php drop-in file that WordPress uses automatically.

You can also enable it via WP-CLI:

wp redis enable

Step 5: Verify It’s Working

Check the Redis dashboard in Settings → Redis. You should see:

• Status: Connected
• Hit ratio climbing as traffic comes in
• Memory usage reflecting cached objects

You can also check via WP-CLI:

wp redis status
wp redis info

Understanding Cache Hit Ratio

The hit ratio is the percentage of object cache requests served from Redis rather than the database. A low hit ratio (under 50%) early on is normal — the cache needs to “warm up” as requests come in.

On an established site with consistent traffic, a healthy hit ratio is typically 80–95%. If yours stays low, possible causes include:

• Cache keys changing frequently — dynamic query arguments or user-specific data that can’t be shared
• Very low TTL settings — objects expiring before they get reused
• High site diversity — many unique pages or users generating unique queries

Tuning Redis for WordPress

Set a Memory Limit

Redis keeps all data in memory. Without a limit, it can grow unbounded. Set a max memory and an eviction policy:

# In redis.conf or via redis-cli
maxmemory 256mb
maxmemory-policy allkeys-lru

allkeys-lru means Redis will evict the least-recently-used keys when it hits the memory limit — a sensible default for a WordPress cache.

Separate Redis Databases or Instances

If you run multiple WordPress sites on the same server, use separate Redis databases or separate Redis instances to avoid key collisions:

// Site 1
define('WP_REDIS_DATABASE', 0);

// Site 2
define('WP_REDIS_DATABASE', 1);

Or use a key prefix:

define('WP_REDIS_PREFIX', 'mysite_');

Consider Redis Sentinel or Cluster for High Availability

For production sites where uptime matters, Redis Sentinel provides automatic failover. Redis Cluster adds horizontal scaling. These are advanced setups — most WordPress sites don’t need them — but they’re available if your traffic warrants it.

Object Caching vs. Page Caching

These two caching layers work at different levels and complement each other:

	Page Cache	Object Cache
What it stores	Full HTML pages	Database query results, PHP objects
Who benefits	Logged-out visitors	All visitors, including logged-in users
Bypass conditions	Logged-in users, cart pages, etc.	Rarely bypassed
Speed gain	Eliminates PHP + DB entirely	Reduces DB queries within PHP execution

Page caching is faster for anonymous visitors because it skips PHP entirely. Object caching shines for:

• Logged-in users (WooCommerce customers, members, admins)
• Pages that can’t be page-cached (checkout, account pages)
• Admin dashboard performance
• Sites with many unique page combinations

Use both together for maximum effect.

Does Managed Hosting Handle This For You?

On shared or entry-level hosting, you typically install and configure Redis yourself. On quality managed WordPress hosting, Redis is often included, configured, and maintained as part of the platform.

Rocket.net includes Redis object caching built into their managed WordPress hosting environment — no plugin configuration or server tuning required. It’s enabled by default, which means you get the benefits without the setup steps above. Combined with their page caching layer and global CDN, it’s one less performance bottleneck to worry about.

If you’re currently managing Redis manually on a VPS — or going without object caching entirely — it’s worth comparing that effort against what a managed host includes out of the box.

Monitoring Cache Performance Over Time

Once Redis is running, keep an eye on:

• Hit ratio — aim for 80%+ on established sites
• Memory usage — ensure it stays within your maxmemory limit
• Eviction rate — high evictions suggest memory is too tight
• Connected clients — unusual spikes can indicate connection leaks

The Redis Object Cache plugin dashboard shows most of this. For deeper visibility, tools like RedisInsight (a free GUI from Redis) let you inspect keys, monitor commands, and profile memory usage.

Common Issues and Fixes

Plugin shows “Not connected” Check that Redis is running (redis-cli ping) and that the host/port in wp-config.php matches your Redis configuration.

High memory usage Reduce the maxmemory limit and let allkeys-lru eviction handle old entries. Or audit which plugins are storing large objects in the cache.

Cache not persisting between requests Confirm the object-cache.php drop-in is present in wp-content/. Without it, WordPress uses its default non-persistent cache.

Performance not improving If your bottleneck isn’t database queries (check with Query Monitor plugin), object caching won’t help much. Profile first, then optimize.

Summary

WordPress object caching with Redis is one of the most effective performance improvements for dynamic sites — particularly those with logged-in users, complex queries, or heavy plugin usage. It reduces database load, speeds up response times, and scales well as your traffic grows.

The steps are straightforward: install Redis, connect it to WordPress, enable the drop-in, and monitor the hit ratio. On a managed host that includes Redis by default, you skip most of that work entirely.

If your WordPress site is still running without a persistent object cache, adding one is one of the higher-value performance changes you can make today.

---

Ready to run WordPress on a host that includes Redis object caching out of the box? Try Rocket.net — managed WordPress hosting built for speed, with Redis, page caching, and a global CDN included in every plan.