WordPress makes a lot of database queries. Even a fairly simple page can involve dozens of queries to fetch settings, posts, metadata and other information.
WordPress has a built-in object cache which avoids repeating queries within the same request. The problem is that, by default, the cache disappears as soon as the request finishes.
The next visitor comes along and WordPress has to do much of the same work again.
Redis solves this by keeping cached objects in memory between requests. I’ve been using it alongside EasyEngine, which manages WordPress in Docker containers.
Configuring Redis
EasyEngine can provide Redis as part of its WordPress stack. For other server stacks, you may need to install it separately.
I use the WP Redis
First, add the connection details to wp-config.php:
1$redis_server = array(2 'host' => 'global-redis',3 'port' => 6379,4);5 6define('WP_CACHE_KEY_SALT', 'example.com_obj:');
The hostname depends on your setup. In this example, global-redis is a Redis service reachable from the WordPress PHP container.
The cache key salt is important if multiple WordPress installations share the same Redis instance. Without a unique prefix, cache entries from different sites could conflict.
I also configure a separate prefix for Nginx’s page caching, which is a different cache entirely.
Enabling the object cache
Installing the plugin isn’t quite enough. WordPress uses an object-cache.php drop-in to replace its default object caching implementation.
With WP Redis, this can be enabled using WP-CLI.
1wp redis enable
The command creates the necessary drop-in and allows WordPress to start using Redis for persistent object caching.
You can check the connection with:
1wp redis info
And WordPress’s Site Health screen should report that a persistent object cache is being used.
Checking that it’s working
One mistake is assuming that because Redis is running, WordPress must be using it.
Redis could be perfectly healthy while WordPress is still falling back to its normal in-memory cache.
I check the plugin’s connection status and use Query Monitor to inspect database queries. The WP Redis plugin also provides debugging commands which can help investigate cache hits and misses.
It’s worth remembering that a cache hit still has a cost. PHP needs to communicate with Redis, and the cached data needs to be retrieved and decoded.
If the database query was already very cheap, Redis might not make much difference.
Redis isn’t page caching
There’s an important distinction between object caching and page caching.
A page cache stores the final HTML response, allowing a visitor to receive the page without WordPress running at all.
Redis object caching works inside WordPress. PHP still runs, but it can retrieve objects from Redis instead of repeatedly querying the database.
This makes it particularly useful for uncached requests, such as administration pages, logged-in users and dynamic content.
For public pages already served by a CDN or Nginx, Redis might not get involved at all.
Is it worth enabling?
For most WordPress sites with a reasonable amount of traffic or database activity, persistent object caching is worth considering.
It doesn’t automatically make every website faster, and a poorly configured Redis instance can introduce its own problems.
But when it’s configured correctly, it removes a lot of repeated database work without requiring changes to the application.
The important thing is to measure the difference, check that WordPress is actually connected, and remember that Redis is only one part of the caching stack.