Adding Object Cache to WordPress with Redis (Step by Step)

Every WordPress site hits the same wall. Pages start fast, traffic grows, the database query count creeps up, and one day your dashboard takes six seconds to load and your admin-ajax requests start timing out. The fix is rarely "buy more CPU." It's almost always object cache.

Look, I'm going to be real with you. WordPress runs hundreds of SELECT queries on every page load, most of them looking up the same option rows, user metas, and term hierarchies over and over. Redis object cache puts those answers in memory and serves them in microseconds instead of milliseconds. The before/after typically lands at 3-5x faster page loads with zero theme or plugin changes.

Here's the exact setup that works on a production WordPress site.

What object cache actually does (vs page cache)

These are not the same thing. Page cache (the WP Super Cache, W3 Total Cache, or LiteSpeed kind) stores rendered HTML for anonymous visitors. It does nothing for logged-in users, the admin area, or REST API calls.

Object cache stores the results of database queries in memory. It speeds up:

• The admin dashboard for editors and shop managers
• WooCommerce cart, checkout, and product pages (which can't use page cache)
• REST API endpoints that headless front-ends rely on
• Logged-in user sessions on membership sites

If your site is mostly anonymous blog traffic, page cache moves the needle more. If your site has logged-in users, WooCommerce, or REST API consumers, object cache is the bigger lever.

Why Redis specifically

WordPress object cache can run on Memcached, APCu, or Redis. Redis wins for three reasons:

1. Persistence. Restart your server and the cache survives. Memcached forgets everything.
2. Eviction control. You pick the policy (allkeys-lru, volatile-lru, etc.) instead of inheriting whatever the host configured.
3. Cluster mode. When you outgrow one node, Redis scales horizontally. Memcached requires manual sharding.

Prerequisites

You need three things:

• A running WordPress site (any version 5.6+, but 6.x recommended)
• A Redis instance reachable from your WordPress server
• WP-CLI installed (optional but it makes verification trivial)

If you don't have Redis yet, spin one up on Elestio in one click. You'll get the connection details (host, port, password, TLS endpoint) on the service overview page.

Step 1: Install the Redis Object Cache plugin

The maintained plugin to use is Redis Object Cache by Till Krüss. From your WP admin:

Plugins → Add New → search "Redis Object Cache" → Install → Activate

Or via WP-CLI:

wp plugin install redis-cache --activate

The plugin won't do anything until you connect it to a Redis instance.

Step 2: Wire it up in wp-config.php

Add these lines above the /* That's all, stop editing! */ comment in wp-config.php:

define( 'WP_REDIS_HOST', 'your-redis-instance.vm.elestio.app' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PASSWORD', 'your-redis-password' );
define( 'WP_REDIS_SCHEME', 'tls' );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_CACHE_KEY_SALT', 'yoursite.com' );

Two things people miss:

• WP_REDIS_SCHEME = 'tls' is mandatory if your Redis instance is TLS-only (managed providers like Elestio are). Skip it and connections fail silently.
• WP_CACHE_KEY_SALT isolates cache keys per site. Without it, multisite installations or shared Redis instances will collide.

Step 3: Enable the drop-in

Inside WordPress admin go to Settings → Redis, then click Enable Object Cache. The plugin will copy object-cache.php to your wp-content directory. That file is the actual drop-in WordPress loads on every request.

Or via WP-CLI:

wp redis enable

Step 4: Verify it's working

Three ways to confirm cache is live:

# Status check
wp redis status

# Live stats
wp redis info

# Watch key hits in real time (from your Redis instance)
redis-cli -h your-redis-instance.vm.elestio.app -a yourpass --tls MONITOR

You should see hit rates climb past 90% within a few minutes of normal traffic. If the hit rate stays at 0%, something's wrong with your connection config: re-check the TLS scheme and password.

Real before/after numbers

On a typical WooCommerce site with ~200 products and 50 plugins, here's what I see consistently:

The dashboard delta is what stakeholders feel. The DB query reduction is what keeps your MySQL CPU off the ceiling at peak hours.

Common gotchas

A few traps to watch:

• Multisite + shared Redis. Every site on a multisite network MUST set a unique WP_CACHE_KEY_SALT, otherwise plugin and option keys collide across sites and you'll see ghost data appear in the wrong places.
• Plugin cache flushes. Some plugins (looking at you, certain caching combos) call wp_cache_flush() on every save. That nukes the entire object cache. Watch your redis-cli INFO for evicted_keys spikes.
• Maxmemory policy. Set Redis to maxmemory-policy allkeys-lru for WordPress. The default noeviction will start refusing writes once memory fills, which silently breaks the cache.
• Object Cache Pro vs the free plugin. The free Redis Object Cache plugin is fine for 99% of sites. Object Cache Pro adds async writes and prefetching, which matter at very high traffic. Skip it until you're past a million requests per month.

Deploy a managed Redis instance

One click, TLS configured, backups running, password rotation handled:

• Redis on Elestio
• WordPress on Elestio

Spin up Redis, copy the connection details into wp-config.php, enable the drop-in, and your admin dashboard stops feeling like 2008.

Thanks for reading ❤️

See you in the next one 👋