WordPress Object Caching with Redis: Eliminate Redundant Database Queries

Every WordPress page request triggers dozens of database queries. Even a simple blog post page typically queries for the post content, post meta, terms, user data, site options, and widget configurations. Without caching, every visitor triggers the same queries against the same rows in the database. WordPress has a built-in object cache, but by default it is non-persistent — it exists only for the duration of a single request and is discarded afterward. Adding Redis as a persistent backend transforms the object cache into a server-side store that survives across requests, so the second visitor to any page pays a fraction of the database cost the first visitor did.

How the WordPress Object Cache API Works

WordPress's object cache API is built around three functions: `wp_cache_set($key, $data, $group, $expire)`, `wp_cache_get($key, $group)`, and `wp_cache_delete($key, $group)`. Core WordPress uses this API extensively — option loading, user metadata, term lookups, and transients all flow through it. The default non-persistent cache (`wp-includes/cache.php`) stores values in a PHP array. To make the cache persistent, you drop a `object-cache.php` file into `wp-content/` — WordPress automatically loads it instead of the built-in implementation. This file provides the same function signatures but routes all storage to Redis, Memcached, or another backend. No core files are modified, and the entire cache becomes persistent transparently.

Installing and Configuring Redis on Ubuntu

Install Redis: `apt install redis-server -y`. By default, Redis listens on 127.0.0.1:6379, which is correct for a WordPress site running on the same server. Configure Redis memory limits in `/etc/redis/redis.conf`: set `maxmemory 256mb` and `maxmemory-policy allkeys-lru` to evict the least recently used keys when memory is full. This prevents Redis from growing without bound and ensures frequently accessed data stays in cache while stale data is evicted. Restart Redis with `systemctl restart redis-server`. Verify it is running: `redis-cli ping` should return PONG. Install the PHP Redis extension: `apt install php8.2-redis -y && systemctl restart php8.2-fpm`.

The Redis Object Cache Plugin

The Redis Object Cache plugin by Till Krüss is the standard choice for connecting WordPress to Redis. Install and activate it from the WordPress plugin directory. The plugin handles dropping the `object-cache.php` drop-in automatically through its admin interface. Navigate to Settings > Redis and click Enable Object Cache. The plugin shows connection status, cache hit rate, and a breakdown of which cache groups are being used. By default it connects to 127.0.0.1:6379. For custom Redis configurations — different port, socket connection, or password — define the `WP_REDIS_HOST`, `WP_REDIS_PORT`, and `WP_REDIS_PASSWORD` constants in `wp-config.php` before the plugin initializes.

Cache Groups and Selective Invalidation

WordPress organizes cached items into groups — 'options', 'users', 'posts', 'terms', 'transient', and more. Understanding groups lets you selectively flush related data. When you update a post, WordPress invalidates the 'posts' group entries for that post ID. When options change, the 'options' group is cleared. You can define custom groups in your plugin code to namespace your data: `wp_cache_set('user_feed_'.$user_id, $feed_data, 'myplugin_feeds', 3600)`. To flush only your plugin's group without clearing the entire cache, use `wp_cache_delete` on specific keys or implement a version-based cache busting pattern where you increment a stored version number and include it in all your cache keys.

Measuring Performance Impact

Use Query Monitor to observe the before and after impact of Redis caching. Without Redis, a typical WordPress page shows 30-80 database queries on first load. With Redis warmed up, the same page should show significantly fewer queries — sometimes as few as 5-10 — because most option lookups and term queries are served from the cache. The Redis plugin's dashboard shows the cache hit ratio: a well-warmed cache typically achieves 85-95% hit rates. Use `redis-cli monitor` during a test request to see every Redis command in real time, which reveals exactly what is being cached and retrieved. Load testing with a tool like Apache Bench before and after Redis shows the throughput improvement: pages per second typically doubles or triples for database-heavy pages.

Caching Pitfalls and Debugging

The most common caching bug is stale data: a value is cached but the source changes and the cache is not invalidated. WordPress's internal APIs handle this for standard data, but custom code that writes directly to database tables without using WordPress functions bypasses cache invalidation entirely. Always use WordPress's update functions — `update_post_meta`, `update_option`, `wp_set_object_terms` — rather than raw `$wpdb` queries when working with data types the object cache knows about. For custom tables, implement explicit cache invalidation in your write functions. Another pitfall is caching user-specific data in a shared cache group — always include the user ID in the cache key when the data varies by user to prevent one user from seeing another's cached data.