Redis is an in-memory database that caches the results of WordPress queries to MySQL. Instead of repeated database calls, WordPress reads data from RAM — the speed difference is enormous.

Installing Redis on a VPS (Ubuntu)

sudo apt update
sudo apt install -y redis-server

# Start and enable on boot
sudo systemctl enable --now redis-server

# Check
redis-cli ping
# PONG — everything works

Configuring Redis for WordPress

Install the PHP extension

sudo apt install -y php-redis
sudo systemctl restart php8.2-fpm  # or your PHP version

Add to wp-config.php

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_CACHE', true);

Install the plugin

Install the Redis Object Cache plugin under Admin → Plugins → Add New. After activation, go to Settings → Redis and click «Enable Object Cache».

✅ The status should show «Connected» and «Object cache is enabled».

Optimization results

Metric	Before Redis	After Redis
TTFB	800–1200 ms	80–150 ms
DB queries	80–150	5–10
CPU load	High	Low

⚠️ On hosting without VPS access, use a plugin-based cache instead of Redis (WP Super Cache or W3 Total Cache).

Monitoring Redis

# Stats
redis-cli info stats | grep -E 'hits|misses|expired'

# Clear cache
redis-cli flushdb

# Real-time monitoring
redis-cli monitor

Diagnosing Redis connection errors

The WordPress object cache depends on three independent components: the Redis service, the PHP extension, and the plugin itself. An error can occur at any of these layers.

Error text or status	Cause	What to do
Status: Not connected in Redis Object Cache	The redis-server service is not running, or it listens on an address and port different from the one set in WP_REDIS_HOST	Check systemctl status redis-server and run redis-cli -h 127.0.0.1 ping
PHP Fatal error: Uncaught Error: Class "Redis" not found	The php-redis extension is not installed for the PHP version used by the PHP-FPM pool	Run php -m \| grep redis for the actual PHP-FPM version in use
(error) NOAUTH Authentication required	requirepass is enabled in redis.conf, but no password is set in WP_REDIS_PASSWORD	Add define('WP_REDIS_PASSWORD', '...') to wp-config.php
Object cache is enabled, but TTFB has not changed	A full HTML cache from another plugin is also enabled and masks the Redis effect, or the bottleneck is CPU rather than the database	Check redis-cli info stats for the actual hit rate

For caching PHP sessions in Redis separately from the object cache, see the article on PHP sessions in Redis.

When Redis will not help

A site on shared hosting without root access — there is nowhere to install and run redis-server; you need a VPS or a dedicated server
The real problem is not repeated SELECT queries but a single slow reporting query once a day — an object cache speeds up frequently repeated calls, not one-off ones
A site with one visitor an hour — the cache never gets warm before the next eviction and provides no noticeable effect
A database that is already small and fast (up to 10,000 rows) with no complex JOINs — the gain from Redis will be tens of milliseconds, not a multiple
The site's bottleneck is not the database but rendering a heavy visual page builder — general front-end speedup measures are more effective there

For general WordPress speedup principles that also apply on top of Redis, see the article on WordPress speed.

Setting a memory limit and key eviction

Without a memory limit, Redis can take up all the RAM available on the server. Set a limit and an eviction policy explicitly:

# /etc/redis/redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lru

The allkeys-lru policy evicts the least recently used keys once the limit is reached — a safe choice for a WordPress object cache. After changing the configuration, restart the service:

sudo systemctl restart redis-server

For diagnosing slow queries that Redis does not fix by itself, see the article on the MySQL slow query log.

How to confirm Redis is actually reducing load

The hit rate in redis-cli info stats is above 90% after a few hours under normal load
The number of SQL queries per page in Query Monitor has dropped noticeably compared to a measurement without Redis
used_memory stays within the configured maxmemory without evicted_keys constantly climbing
TTFB stays reliably under 150 ms across several consecutive runs, not just the first one

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'
redis-cli info memory | grep used_memory_human
redis-cli info clients | grep connected_clients