Redis as WordPress cache: when you need it and how to verify it works

Redis as an object cache for WordPress reduces MySQL queries by holding cached results in memory. It makes sense on sites with real traffic and on a server where you can install an additional service. On basic shared hosting with a few hundred daily visits, it's often just another daemon to monitor without measurable benefits. This guide covers installation, plugin configuration, and the command to verify it's actually doing something.

Installing Redis on Ubuntu

Ubuntu includes Redis in the official repositories. The redis-tools package also brings redis-cli, which you'll need for verification later on:

sudo apt update
sudo apt install redis-server redis-tools

Verify the service is running:

sudo systemctl status redis-server

Those wanting a more recent version than what Ubuntu packages can add the official Redis repository (package redis instead of redis-server), but for WordPress caching, the distribution version is usually sufficient.

Configuring Redis as cache

By default, Redis has no memory limit set and doesn't automatically discard old keys. For caching use, the official Redis documentation indicates a dedicated configuration in the redis.conf file:

maxmemory 2mb
maxmemory-policy allkeys-lru

The maxmemory value should be adapted to available RAM on your server (2 MB is just the documentation example). With allkeys-lru, Redis automatically discards the least-used keys when the limit is reached, without requiring the application to set a TTL.

The WordPress object cache plugin

The most widely used plugin is Redis Object Cache, available on wordpress.org, developed by Till Krüss. The plugin supports Predis, PhpRedis (PECL), Relay, replication, Sentinel, clustering, and WP-CLI.

After installation, go to Settings → Redis from the dashboard (or Network Admin → Settings → Redis on multisite) to enable the cache. If automatic connection doesn't work, the plugin's official installation file indicates the constants to add to wp-config.php, above the line /* That's all, stop editing! */:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PREFIX', 'site-name');
define('WP_REDIS_DATABASE', 0); // 0-15
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

WP_REDIS_PREFIX and WP_REDIS_DATABASE are useful when multiple WordPress sites share the same Redis instance: without a different prefix or database number, flushing one site's cache will also delete the other sites' data.

Those managing plugins via Composer can use the equivalent WP-CLI commands:

composer require wpackagist-plugin/redis-cache
wp redis enable
wp redis status

Verifying the cache is working: redis-cli

The command that matters is INFO stats, which returns two cumulative counters: keyspace_hits (keys found in cache) and keyspace_misses (keys requested but absent). The official Redis documentation on eviction explains how to calculate the cache hit rate:

redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"

keyspace_hits:38291847
keyspace_misses:4982731

The formula is:

keyspace_hits / (keyspace_hits + keyspace_misses) * 100

A lower-than-expected value can signal an unsuitable eviction policy: in that case, also check evicted_keys in the same INFO stats output.

To see how many keys are present and how long they stay alive, use:

redis-cli INFO keyspace

which returns one line per database, like db0:keys=42857,expires=41200,avg_ttl=3542. If avg_ttl is much lower than expected from the plugin, keys expire before being reused and the hit rate suffers.

To check how much memory Redis is using:

redis-cli INFO memory | grep used_memory_human

A value that grows continuously without stabilising, with maxmemory-policy set correctly, should be investigated: it can indicate keys without expiry that the plugin isn't handling as expected.

When Redis isn't needed

Not every WordPress site benefits from an external object cache. Signs that suggest it probably isn't worth installing:

• Low traffic: if the site receives only a few hundred visits per day, page caching (even just from an already-installed caching plugin) eliminates most repeated queries without needing an extra service to manage.
• Shared hosting without Redis access: on many shared hosting plans, there's no way to install or reach a Redis instance, nor to run redis-cli. In these cases, the practical choice is a page-level cache plugin (which doesn't require external daemons) or upgrading to a plan with additional services.
• Static or near-static site: if content changes rarely, page caching with a long TTL solves the same problem Redis would address at query level, with fewer components to maintain.

Before installing Redis, it's worth asking whether the actual bottleneck is really repeated database queries. If you're unsure, the answer lies in the INFO stats numbers after a few days of activity: if the hit rate stays near zero or traffic doesn't justify another daemon, uninstall it without regrets.