Redis object cache for WordPress: when it helps and how to set it up

A complete guide to Redis object caching for WordPress: installation, memory configuration, eviction policies, cache key salts, WooCommerce considerations, performance benchmarks, and troubleshooting.

Redis object cache helps WordPress avoid repeating expensive database work. It is not a replacement for page cache, and it will not fix slow third-party scripts, but it can make admin, WooCommerce, and logged-in traffic noticeably faster.

When Redis helps

Redis object cache is most effective when:

The site has many logged-in users (membership, LMS, ecommerce)
WooCommerce product and category pages feel slow
Admin screens (post list, plugin page, WooCommerce orders) are sluggish
The database shows repeated identical wp_options, wp_postmeta, or wp_usermeta queries
Full-page cache cannot cover the traffic (logged-in users bypass page cache)

It helps less on:

Small brochure sites where Cloudflare or page cache already handles 99% of requests
Sites with very low traffic (the overhead is not justified)
Sites where the bottleneck is slow external APIs, heavy JavaScript, or unoptimised images

What object cache does vs page cache

Aspect	Page cache	Object cache
What it stores	Full HTML pages	Database query results, computed values
Who benefits	Anonymous visitors	All visitors, especially logged-in users
Typical tools	Nginx FastCGI cache, Varnish, Cloudflare APO	Redis, Memcached
WordPress integration	Cache plugins or server config	Drop-in (`object-cache.php`)
WooCommerce impact	Limited (cart/checkout bypass cache)	Significant (product queries, options)

You need both. Page cache for public traffic, object cache for everything page cache skips. If the database itself is the bottleneck, pair this with database optimisation for WordPress before reaching for more RAM.

Installation

Step 1: Install Redis server

apt update
apt install redis-server
systemctl enable --now redis-server

Step 2: Install PHP Redis extension

apt install php-redis
# or for specific PHP version
apt install php8.3-redis

Restart PHP-FPM:

systemctl restart php8.3-fpm

Step 3: Verify

redis-cli ping
# Should respond: PONG

php -m | grep redis
# Should show: redis

Memory configuration

Edit /etc/redis/redis.conf:

maxmemory 256mb
maxmemory-policy allkeys-lru

Choosing the right memory limit

Site type	Recommended maxmemory
Small brochure site (few plugins)	64–128 MB
Medium WordPress (20–40 plugins, moderate traffic)	128–256 MB
WooCommerce / membership site	256–512 MB
High-traffic multisite	512 MB – 1 GB

Do not leave Redis unlimited on a small VPS. It can consume memory needed by PHP-FPM workers and MySQL’s buffer pool. On a 2 GB VPS, 128–256 MB for Redis is a safe ceiling.

Eviction policy

allkeys-lru — Evicts least recently used keys when memory fills (recommended for most sites)
volatile-lru — Only evicts keys with an expiry set (safer but less effective)
noeviction — Returns errors when memory is full (do not use for WordPress)

Restart after config changes:

systemctl restart redis-server

WordPress configuration

Install the drop-in plugin

Use a maintained Redis object cache plugin (Redis Object Cache by Till Krüss is the most widely used). The plugin installs a wp-content/object-cache.php drop-in.

Add a cache key salt

In wp-config.php, add before the “stop editing” line:

define('WP_CACHE_KEY_SALT', 'example.com:');

If multiple WordPress sites share one Redis instance, unique salts are essential. Without them, Site A can read cached data that belongs to Site B.

Verify the connection

wp redis status
wp cache type

Expected output:

Status: Connected
Client: PhpRedis (v6.x)

Performance monitoring

Check Redis stats

redis-cli info stats
redis-cli info memory
redis-cli info keyspace

Key metrics:

Metric	What it means	Good value
`keyspace_hits`	Successful cache reads	Higher is better
`keyspace_misses`	Cache misses (went to DB)	Lower is better
`evicted_keys`	Keys removed due to memory pressure	Should be near zero
`used_memory_human`	Current memory usage	Should be under maxmemory
`hit rate`	hits / (hits + misses)	> 90% is healthy

Calculate hit rate:

redis-cli info stats | grep keyspace
# Example output:
# keyspace_hits:154230
# keyspace_misses:8234
# Hit rate: 154230 / (154230 + 8234) = 94.9%

If the hit rate drops below 80%, the cache is too small or caching too many short-lived items.

Monitor during traffic

redis-cli --stat

This shows a live stream of requests per second, hits, and misses.

WooCommerce considerations

Redis can significantly improve WooCommerce admin and product queries, but it does not make cart and checkout cacheable. Keep page cache bypass rules for:

URL path	Reason
`/cart/`	Dynamic per-user state
`/checkout/`	Dynamic per-user state
`/my-account/`	Logged-in user pages
`/wp-json/wc/`	WooCommerce REST API
Any URL with `woocommerce_items_in_cart` cookie	Cart-dependent display

A common Redis + page cache setup for WooCommerce:

Nginx FastCGI cache for all public pages (with bypass rules for cart/checkout/my-account)
Redis object cache for database query results, transients, and options
Cloudflare CDN for static assets and edge caching

Troubleshooting

Site breaks after enabling Redis

# Flush Redis
wp cache flush
redis-cli FLUSHDB

# Disable the drop-in
mv wp-content/object-cache.php wp-content/object-cache.php.disabled

Most Redis issues come from stale cached data, shared cache keys across sites, or memory pressure.

Redis is using too much memory

redis-cli info memory | grep used_memory_human
redis-cli --bigkeys

--bigkeys lists the largest keys. WordPress transients can grow unexpectedly large.

Connection refused

redis-cli ping
systemctl status redis-server

Check if Redis is bound to the correct interface. Default is 127.0.0.1, which is correct for local use.

Slow performance after enabling Redis

The cache needs to warm up. The first few minutes after enabling Redis may be slower as the cache populates. Check after 10–15 minutes of normal traffic.

If it stays slow:

Check that maxmemory-policy is not noeviction (causes errors when full)
Verify PHP Redis extension is using the phpredis driver, not the Predis pure-PHP library (phpredis is faster)
Check disk I/O on the Redis dump file (/var/lib/redis/dump.rdb). On I/O-constrained VPS, disable periodic saves: config set save ""

Removing Redis

If Redis causes more problems than it solves:

# Disable the WordPress drop-in
mv wp-content/object-cache.php wp-content/object-cache.php.disabled

# Stop and disable Redis
systemctl stop redis-server
systemctl disable redis-server

# Optional: remove Redis
apt purge redis-server

The site will revert to WordPress’s default transient-based caching. This is slower but more predictable if your Redis setup was problematic.