WordPress’s default object cache only lives for the length of one page request — it’s wiped the moment the page finishes loading. On a busy site, that means the same queries run over and over, every single visit. A persistent object cache like Redis fixes this by keeping cached data alive between requests.

Installing Redis

On most VPS setups:

sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server

Check it’s running with redis-cli ping — it should reply PONG.

Connecting WordPress

Install the Redis Object Cache plugin (it’s just a drop-in, not bloat — it copies a single object-cache.php file into wp-content), then 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_DATABASE', 0);

Then enable it from the plugin’s settings page. You’ll see a status showing “Connected” if it’s working.

What this actually changes

Options, transients, term queries, and most WooCommerce lookups now get cached in memory instead of hitting MySQL every time. On stores with a large product catalog this is usually the single biggest win available short of a full CDN setup — bigger than most “speed” plugins on their own.

The part people skip: separate databases per site

If you’re running Redis for more than one WordPress install on the same server, give each one its own WP_REDIS_DATABASE number. Otherwise cache keys can collide between sites, which is a genuinely annoying bug to track down later.

Monitor memory usage with redis-cli info memory once it’s live for a week — if it’s growing unbounded, you likely have a plugin generating transients that never expire, which is worth finding before it becomes a real problem.