Every performance optimization article seems to recommend Redis. “Install Redis for faster
WordPress.” It’s mentioned so often that site owners assume it’s a universal solution. So they
install Redis, enable a caching plugin, see a green “Connected” status, and wonder why their site
doesn’t feel noticeably faster.

The truth I’ve learned through years of WordPress optimization is that Redis object caching helps
specific sites in specific situations. For some sites, it’s genuinely transformative. For others, it
adds complexity without meaningful benefit. And for a surprisingly large number of sites claiming to
use Redis, it’s “enabled” but not actually functioning correctly—Connection is established but
caching isn’t happening.

This guide cuts through the hype to explain what Redis actually does for WordPress, which sites
genuinely benefit, and most importantly, how to verify your Redis implementation is working. You’ll
understand the difference between object caching and page caching, why admin dashboards often
improve more than front-end pages, and how to diagnose when Redis is connected but not caching.

Understanding How WordPress Object Caching Works

Before discussing Redis specifically, you need to understand what the WordPress object cache does.
It’s fundamentally different from page caching, and confusing the two leads to incorrect
expectations.

The Problem Object Cache Solves

WordPress generates pages dynamically. When someone visits a post, WordPress loads, queries the
database for the post content, retrieves site options, checks user authentication, loads plugin
data, runs template functions—making potentially dozens or hundreds of database queries before
producing the final HTML.

Many of these database queries are repetitive. The same site options get loaded on every request.
User metadata gets queried multiple times as different components check permissions. Post meta gets
fetched repeatedly as the template runs. These redundant queries waste database resources.

The object cache addresses this by storing query results in memory during a request. When WordPress
first fetches site options, the result is cached. When a plugin tries to fetch those same options
later in the same request, the cached value is returned instantly without hitting the database
again.

WordPress Default Object Cache Limitation

WordPress includes a built-in object cache, but it has a critical limitation: it only persists for
the duration of a single request. When the request ends and PHP terminates, the cache disappears.
The next request starts fresh with an empty cache.

This means the default object cache only prevents redundant queries within a single page load—it
doesn’t help across requests. If 100 visitors request your homepage, each request makes its own
database queries from scratch. The cache never shares data between requests.

How Persistent Object Cache Changes This

Redis and Memcached are persistent object cache backends. They run as separate services that store
cached data in memory, persisting between PHP requests. When WordPress caches a value in Redis, that
value remains available for subsequent requests.

Now when 100 visitors request your homepage, the first request populates the cache. The remaining 99
requests can retrieve cached data from Redis without querying the database. Options that would be
fetched separately by each request are cached once and shared.

This is the fundamental value proposition: sharing cached data across requests to reduce overall
database load and speed up WordPress execution.

Object Cache vs. Page Cache

This distinction is critical for understanding when Redis helps. Page caching and object caching are
completely different layers.

Page caching stores the complete HTML output of a page. When a cached page exists, WordPress doesn’t
run at all—the web server returns the cached HTML directly. Page caching is the most impactful
performance optimization because it eliminates WordPress processing entirely for cached requests.

Object caching stores data fragments used while generating pages. WordPress still runs, still
processes templates, still produces output—but with fewer database queries because
commonly-requested data comes from cache.

Here’s the key insight: when page cache serves a request, object cache is never consulted. Page
caching bypasses WordPress completely. Object caching only helps with requests that actually run
WordPress: cache misses, logged-in users, dynamic pages excluded from page caching.

If your page caching is effective and most visitors see cached pages, Redis provides minimal
additional benefit for those visitors. They’re not running WordPress, so object caching never kicks
in.

When Redis Genuinely Helps

Understanding the distinction between page and object caching reveals which sites benefit most from
Redis.

Sites with Significant Logged-In Traffic

Page caching typically excludes logged-in users because they often see personalized content. If a
significant portion of your traffic is logged in, those users bypass page cache and run WordPress
fully for each request. Redis helps these users by caching the common data they’d otherwise query
repeatedly.

Membership sites, online communities, learning platforms, and any site where users log in frequently
fall into this category. If 30% of your traffic is logged in, Redis potentially helps 30% of your
requests meaningfully.

WordPress Admin Dashboard

The WordPress admin is never page-cached and generates substantial database queries. Dashboard pages,
post editing screens, plugin settings—all of these run dozens of queries to display their
interfaces.

Redis often provides the most noticeable improvement in admin responsiveness. The dashboard might
load in 3 seconds without Redis but 1.5 seconds with it. For site administrators who spend hours in
the dashboard, this improvement is tangible and appreciated.

E-Commerce Sites

WooCommerce sites have many pages that can’t be page-cached: cart pages (personalized to user),
checkout pages, account pages. Product queries for pricing and inventory run repeatedly. Order
processing triggers numerous database operations.

Redis caches product data, user session information, and transient data like cart contents. For busy
WooCommerce stores, this can meaningfully reduce database load and improve response times for the
shopping experience.

High-Traffic Sites Under Load

Even with page caching, high-traffic sites experience cache misses. When many simultaneous visitors
request content that’s not cached—maybe new content, or cache just expired—all those requests hit
WordPress directly. Redis helps these cache-miss situations by ensuring the WordPress runs are as
efficient as possible.

Database connection limits become relevant at high traffic. If your database server can handle 50
concurrent connections and traffic spike causes 100 simultaneous WordPress requests, you hit
connection limits. Redis reduces queries per request, reducing database load and helping the server
handle traffic spikes.

Sites with Complex Plugin Stacks

Some plugins are database-heavy, making many queries per page load. Social sharing plugins checking
share counts, SEO plugins loading various settings, page builders with complex saved templates—these
all generate queries that Redis can cache.

If Query Monitor shows your pages making 200+ database queries, Redis likely helps. Well-optimized
sites might make 30-50 queries per page; Redis provides less relative benefit there.

When Redis Provides Minimal Benefit

Recognizing when Redis doesn’t help prevents wasted effort and unnecessary complexity.

Well-Cached Static Content Sites

A blog or news site where 95%+ of visitors are anonymous and page caching works effectively sees
minimal Redis benefit. Those visitors hit page cache. The few cache misses might be slightly faster
with Redis, but the overall impact is negligible.

If your page cache hit rate is 90%+ and admin users are rare, Redis probably isn’t worth the added
infrastructure.

Low-Traffic Sites

Without significant concurrent load, database queries are already fast. Your MySQL server handles 10
queries in 5 milliseconds. Caching those 10 queries in Redis might save 3 milliseconds. The
improvement exists but is imperceptible to users.

Redis adds operational complexity: another service to install, configure, monitor, update. For
low-traffic sites, the complexity cost often exceeds the performance benefit.

Sites with Simple Plugin Stacks

A minimal WordPress site with few plugins makes fewer database queries. There’s less redundant data
to cache, so Redis provides less relative improvement. If your pages make 30 queries and Redis can
cache half of them, you save 15 queries—maybe 10 milliseconds. Not wasted, but not transformative.

Setting Up Redis for WordPress

If your site matches the “genuinely helps” categories, here’s how to implement Redis properly.

Installing Redis Server

On Ubuntu or Debian systems, install Redis with apt: sudo apt install redis-server. This installs
Redis and starts it as a system service.

After installation, verify Redis is running with sudo systemctl status redis-server. You should see
“active (running)” in the output. Test the connection with redis-cli ping—a working Redis responds
with “PONG”.

Redis runs on port 6379 by default, listening only on localhost. For single-server WordPress
installations, this default is secure and correct. Don’t expose Redis to external networks unless
you specifically need distributed caching.

Configuring Redis Memory

Redis stores everything in RAM, so you need to limit its memory consumption. Edit
/etc/redis/redis.conf and set maxmemory to an appropriate value. For a single WordPress site,
64-256MB is typically sufficient. Set maxmemory-policy to allkeys-lru (least recently used eviction)
to handle memory limits gracefully.

After changing configuration, restart Redis: sudo systemctl restart redis-server.

Installing PHP Redis Extension

PHP needs the Redis extension to communicate with the Redis server. Install it with apt: sudo apt
install php8.3-redis (adjust the version number for your PHP version). Restart PHP-FPM to load the
extension: sudo systemctl restart php8.3-fpm.

Verify the extension is loaded: php -m | grep redis should show “redis” in the output.

WordPress Plugin Configuration

The Redis Object Cache plugin is the most common way to connect WordPress to Redis. Install it from
the WordPress plugin directory, then navigate to Settings > Redis in the admin dashboard.

Click “Enable Object Cache” to install the object-cache.php drop-in file. This file replaces
WordPress’s default object cache with one that uses Redis. The plugin should show “Connected” status
with a green indicator.

Optionally, add configuration constants to wp-config.php for custom setups: WP_REDIS_HOST for the
Redis server address (default is 127.0.0.1), WP_REDIS_PORT for non-standard ports, WP_REDIS_PASSWORD
if authentication is configured, and WP_REDIS_DATABASE for selecting a specific Redis database
number.

Verifying Redis Is Actually Working

This is where many implementations fail. Redis might show “connected” but not actually cache
WordPress data. Verification confirms the entire pipeline is working.

Plugin Dashboard Indicators

The Redis Object Cache plugin shows connection status and statistics. “Connected” is necessary but
not sufficient—it only confirms PHP can reach the Redis server. Look at the additional metrics.

Cache hit rate indicates how often cached data is returned versus new data being cached. After the
cache warms up (visit several pages to populate it), hit rate should be 80-95% or higher. If hit
rate stays near zero, data isn’t being cached effectively.

Memory usage shows how much data is stored. An empty or near-empty cache suggests caching isn’t
happening. Typical WordPress sites store several megabytes in object cache.

Cached keys count grows as WordPress stores data. Zero keys or very few keys indicates a problem.

Command Line Verification

Direct Redis inspection reveals exactly what’s happening. Run redis-cli and use the INFO command to
see overall statistics. The keyspace section shows how many keys are stored in each database. The
stats section shows total commands processed, hits, and misses.

Run KEYS “*” to list all cached keys (don’t run this on production with large caches—it can block
Redis). WordPress keys typically include your table prefix or site URL as identifiers. If you see
WordPress-related keys, caching is storing data.

Use MONITOR mode to watch Redis commands in real-time: redis-cli monitor. Then load WordPress pages
and observe the GET and SET commands flowing. If you see activity during page loads, WordPress is
communicating with Redis. If MONITOR shows nothing during page loads, the connection isn’t being
used.

Query Monitor Verification

Query Monitor is invaluable for verifying object cache impact. Install the plugin and view its panel
after loading pages.

The Object Cache section shows cache statistics for the request: hits, misses, and the breakdown by
cache group. With Redis working, you should see many hits—data retrieved from cache rather than
freshly queried.

Compare query counts with and without Redis. Disable Redis temporarily (rename object-cache.php),
load a page, note the query count. Re-enable Redis, load the same page, compare. Fewer database
queries confirm Redis is reducing database load.

Before/After Performance Comparison

The ultimate verification is measurable performance improvement. Before enabling Redis, benchmark
representative pages using Query Monitor’s timing or a tool like WPBenchmarks.

Note PHP execution time and database query time specifically. Enable Redis, warm the cache by
visiting pages, then benchmark again. You should see reduced query counts and reduced query time.
PHP execution time might improve modestly; total time improvements depend on how database-heavy your
pages were.

Admin dashboard timing often shows the most dramatic improvement. Time your dashboard load before and
after—improvements of 30-50% are common for plugin-heavy admin environments.

Common Redis Problems and Solutions

When Redis doesn’t work as expected, these are the typical causes.

Connection Failures

If WordPress can’t connect to Redis, you’ll see connection errors or “Not Connected” status in the
plugin.

First, verify Redis is running: sudo systemctl status redis-server. If it’s failed, check logs for
why: sudo journalctl -u redis-server.

Second, confirm PHP can reach Redis by running a simple test script that attempts to connect.
Connection refused errors indicate Redis isn’t listening or firewall is blocking. Permission denied
suggests authentication mismatch.

Third, check wp-config.php settings match your actual Redis configuration—correct host, port, and
password.

Connected But Not Caching

The most frustrating issue: connection works but caching doesn’t happen. Common causes include:

Missing or incorrect object-cache.php drop-in. Check that wp-content/object-cache.php exists and was
created by your Redis plugin. If it’s from an old plugin or different caching system, remove it and
let your Redis plugin regenerate it.

Plugin conflicts where another caching plugin provides its own object-cache.php. You can only have
one. Deactivate conflicting plugins.

WP_CACHE constant set to false in wp-config.php disables caching. Ensure it’s not blocking object
cache.

Redis database number mismatch—if you’re using a specific database number, ensure wp-config.php
settings match and that database exists in Redis.

Cache Filling Up or Evicting

If maxmemory is too small, Redis starts evicting data. This causes inconsistent caching behavior—data
disappears unexpectedly, hit rates drop.

Check memory status with redis-cli INFO memory. If used_memory approaches maxmemory consistently,
increase the limit in redis.conf. Also verify evicted_keys—a growing count indicates memory
pressure.

Some plugins store excessive data in object cache. If memory fills rapidly after cache flushes, audit
what’s being cached. The Redis Object Cache plugin can show key sizes to identify bloat.

Stale Data Issues

Object cache should be flushed when content changes. If you see stale data on your site, cache
invalidation isn’t working correctly.

WordPress core flushes relevant cache when posts and options change, but not all scenarios are
covered. Plugin or theme updates don’t automatically flush cache. After updates, manually flush
Redis through the plugin dashboard or by running redis-cli FLUSHDB.

Some plugins don’t properly invalidate cache when their data changes. If specific plugin data seems
stale, that plugin might not support object caching correctly.

Redis Configuration Optimization

Default Redis configuration is reasonable, but optimization can improve WordPress performance
further.

Memory Sizing

Too little memory causes eviction and inconsistent caching. Too much wastes RAM that could serve
other purposes.

Start with 128MB for a typical WordPress site. Monitor usage over time—if usage stays under 50%
consistently, you can reduce allocation. If you hit eviction, increase it.

WooCommerce and busy sites with many transients need more—256MB or more isn’t unusual for complex
sites.

Eviction Policy

maxmemory-policy determines what happens when memory fills. allkeys-lru evicts least recently used
keys across all keys—generally appropriate for WordPress caches. volatile-lru only evicts keys with
TTL set, preserving permanent keys—useful if you want some keys never evicted.

For WordPress object caching, allkeys-lru is typically correct. Stale cache data isn’t precious—it
can be regenerated.

Persistence Settings

Redis can persist data to disk, surviving restarts. For WordPress object caching, persistence is
usually unnecessary—cache is regenerated quickly from database queries. Disabling persistence
reduces disk I/O and simplifies operation.

In redis.conf, set save “” (with no save points) to disable RDB snapshots. Set appendonly no to
disable AOF persistence. Cache will be empty after Redis restart, but that’s acceptable for object
cache use.

Multiple WordPress Sites

If multiple WordPress sites share a Redis server, use separate databases or key prefixes to prevent
cache collisions.

Each site can use a different Redis database (0-15 by default) via WP_REDIS_DATABASE constant.
Alternatively, set unique WP_REDIS_PREFIX for each site to namespace keys.

Failure to separate sites means one site’s cache flush affects another site. Key collisions can cause
strange behavior when sites share key names.

Ongoing Maintenance

Redis requires minimal maintenance but shouldn’t be completely ignored.

Monitoring

Periodically check Redis statistics for health indicators. Memory usage trending upward without
stabilizing suggests cache bloat. Evictions occurring regularly indicate memory pressure. Connection
errors appearing indicate problems.

Basic monitoring script that checks redis-cli INFO and alerts on anomalies is worthwhile for
production sites.

After Updates

Flush object cache after WordPress core, theme, or plugin updates. Updated code might cache data
differently, and stale cache from old code can cause issues.

Most update processes don’t trigger cache flush automatically. Add it to your update checklist or use
deployment tools that include cache clearing.

Resizing Over Time

Site growth changes caching needs. A site that started with 50 posts and 3 plugins might grow to 500
posts and 15 plugins. Cache memory needs scale accordingly.

Review Redis memory usage quarterly. If consistently near limits, increase allocation. If
consistently using fraction of allocation, reduce it to free memory for other uses.

Conclusion

Redis object caching provides real value for WordPress sites with significant dynamic
traffic—logged-in users, e-commerce transactions, complex admin use. For these sites, Redis reduces
database load and improves response times measurably.

For sites that are primarily static content with effective page caching, Redis adds complexity
without proportional benefit. The page cache handles most traffic; the few remaining requests don’t
generate enough database load to justify Redis infrastructure.

The critical step regardless of your situation is verification. “Connected” status isn’t
enough—verify that data is actually being cached, hit rates are healthy, and measurable performance
improvement occurred. Too many sites have Redis “enabled” but non-functional, representing wasted
effort and false confidence.

Use the verification methods in this guide to confirm your implementation works. If it does, you’ve
genuinely improved your site’s performance. If it doesn’t, you’ve identified a problem to fix rather
than assuming all is well.