Redis Object Caching for WordPress: Why and How

Every WordPress page load runs database queries. Some are cheap and fast. Others, particularly on sites with WooCommerce, large menus, complex ACF field groups, or heavy plugin stacks, can stack up into dozens or even hundreds of queries per request. The object cache exists to prevent WordPress from running the same query twice in the same request. The problem is that by default it only lives in PHP memory for the duration of a single request, then it is gone. Redis fixes that by giving the object cache a persistent home that survives between requests and across multiple PHP workers.

This guide explains what the object cache stores, why persistence matters, and how to connect WordPress to Redis using the standard drop-in method. You will also learn how to verify the connection is working and avoid the most common mistakes.

What the WordPress Object Cache Actually Stores

WordPress ships with an internal caching API. When WordPress (or a plugin) fetches something from the database, it can store the result in the cache using wp_cache_set() and retrieve it later with wp_cache_get(). Core uses this extensively for things like:

• Post data and post metadata
• Term and taxonomy lookups
• User objects and user metadata
• Option values loaded via get_option()
• Navigation menu structure
• Transients stored in the database

Plugins that are written well use the same API. WooCommerce, for example, caches product data, cart fragments, and session lookups.

Without a persistent backend, every PHP worker builds this cache from scratch on every request. Worker A and worker B, serving two simultaneous visitors, each run the same queries independently. With Redis in place, Worker A stores the result, and Worker B reads it directly from Redis without touching the database at all.

When Does a Persistent Object Cache Actually Help?

Not every site benefits equally. A simple brochure site with full-page caching enabled will rarely hit the object cache on cached pages at all, because the PHP process is bypassed entirely. The object cache matters most when PHP is actually running:

• WooCommerce cart, checkout, and account pages (which cannot be full-page cached)
• Sites with logged-in users, such as membership sites or LMS platforms
• High-traffic sites where the database is a bottleneck even with full-page caching
• Sites with hundreds of options rows or large autoloaded options
• Any site running complex or custom queries that repeat across requests

If your database query time is low and you are serving mostly anonymous traffic with a full-page cache, Redis will still help at the margins, but the gains will be modest. If you are running WooCommerce or a membership platform, Redis is close to essential.

How the Drop-In Works

WordPress looks for a file at wp-content/object-cache.php. If that file exists, WordPress uses it as the object cache implementation instead of the built-in non-persistent one. This file is called a drop-in. It is not a plugin you activate through the dashboard. It sits directly in wp-content/ and is loaded very early, before plugins.

The most widely used drop-in for Redis is Redis Object Cache (by Till Krüss), which ships a drop-in file and a plugin that manages the connection and provides a status dashboard. There is also WP Redis from Pantheon. Both are reputable. The steps below follow the Redis Object Cache plugin, since it is the most common choice in the WordPress ecosystem.

Prerequisites

• A Redis server running and accessible from your web server. On a managed host this is usually already provisioned. On a VPS you can install Redis via your package manager and confirm it is running with redis-cli ping, which should return PONG.
• The PHP Redis extension (phpredis) or the predis library installed. phpredis is faster and preferred. Confirm it is loaded with php -m | grep redis.
• PHP 8.1 or higher with OPcache enabled, which you should already have.
• WP-CLI available on your server for command-line steps.

Step-by-Step Setup

1. Install the Plugin

wp plugin install redis-cache --activate

This installs the Redis Object Cache plugin but does not yet copy the drop-in or enable caching.

2. Configure the Connection in wp-config.php

Open wp-config.php and add your Redis connection details above the line that reads /* That's all, stop editing! */. A typical local socket or TCP connection looks like this:

// Redis over TCP (most common)
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );

// Optional: set a unique prefix if you run multiple WordPress installs on the same Redis instance
define( 'WP_REDIS_PREFIX', 'mysite_' );

// Optional: database index (0 is default)
define( 'WP_REDIS_DATABASE', 0 );

// Optional: password if Redis is protected
define( 'WP_REDIS_PASSWORD', 'your-redis-password' );

If your host provides a Unix socket path instead of a TCP address, use:

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );

Unix sockets are slightly faster than TCP loopback connections because they skip the network stack entirely.

3. Enable the Drop-In

wp redis enable

This copies the object-cache.php drop-in into wp-content/. You should see a confirmation message. You can also do this from the plugin’s dashboard page under Settings > Redis, but the WP-CLI route is cleaner in a deployment workflow.

4. Verify the Connection

wp redis status

A healthy output will show the status as connected and display the Redis server version, the client library in use, and a hit ratio if the cache has had time to warm up. If you see a connection error here, double-check your host, port, and password values in wp-config.php before going further.

You can also verify from the plugin dashboard in wp-admin, which shows real-time hit and miss counts. A low hit ratio immediately after enabling is normal. The cache warms as traffic flows through. Over time a healthy ratio on a busy site is typically well above 50 percent.

Common Mistakes to Avoid

Running Multiple Sites Without a Prefix

If you have more than one WordPress install pointed at the same Redis instance, you must set WP_REDIS_PREFIX to something unique per site. Without a prefix, the sites will share and overwrite each other’s cached values, which causes subtle and confusing bugs.

Forgetting the Drop-In After a Deploy

Some deployment workflows delete and recreate the wp-content directory on every deploy. If your process removes wp-content/object-cache.php, Redis will silently stop being used. Add the wp redis enable step to your deploy script, or explicitly include the drop-in file in your repository.

Confusing the Object Cache With Full-Page Caching

Redis object caching and full-page caching are complementary, not the same thing. Full-page caching (as provided by LiteSpeed Cache on LiteSpeed servers) stores complete HTML responses and serves them without running PHP at all. The object cache helps when PHP does run. You want both on a busy site.

Not Setting a Timeout or Eviction Policy

Redis will eventually run out of memory if keys are never evicted. On your Redis server, set a maxmemory limit and an eviction policy. For a WordPress object cache, allkeys-lru (evict the least recently used keys when memory is full) is a sensible default. This is a server-level setting in redis.conf, not something you configure in WordPress.

Checking the Impact on Core Web Vitals

A faster object cache most directly reduces server response time (Time to First Byte), which contributes to LCP. The Core Web Vitals thresholds to aim for are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. Use PageSpeed Insights before and after enabling Redis and compare the server response time in the diagnostics section. Keep in mind that PageSpeed Insights shows both lab data (synthetic) and field data (real user measurements from CrUX), and they can differ significantly. Look at both.

If you are on a managed WordPress host that provisions Redis for you, the connection details and drop-in setup may already be handled at the platform level, saving you the configuration steps above.

Takeaway

The default WordPress object cache is a short-lived in-memory store that evaporates after every request. Redis gives it persistence, which means your database answers the same question once instead of hundreds of times per minute. The setup is straightforward: install a Redis server, confirm the PHP extension is loaded, define your connection constants in wp-config.php, run wp redis enable, and verify with wp redis status. If your site runs WooCommerce, hosts logged-in users, or carries any meaningful traffic, this is one of the highest-return configuration changes you can make.