Redis Object Cache for WordPress: Setup, Verify and When It Does Nothing

What is object cache?

An object cache stores the results of work WordPress has already done, so it does not have to repeat that work on every request. In practical terms, that usually means database query results, computed values, and other reusable pieces of data that PHP would otherwise have to build again from scratch.

Redis object cache WordPress setups use Redis as a persistent store for that data. Unlike the built-in object cache, which only lasts for a single page load, a persistent object cache keeps values between requests. When WordPress asks for the same object again, it can fetch it from Redis instead of running the same query or calculation again.

The key distinction is between object cache and page cache. A page cache stores a finished HTML page and serves it to anonymous visitors without running WordPress at all. That is fast, and it is the right tool for fully public, unchanged pages. An object cache, by contrast, helps the requests that still hit PHP: the WordPress admin, site search, account pages, cart and checkout, and pages viewed while logged in. If a page cannot be served from a full-page cache, object caching is one of the few levers that can still reduce repeated database work.

That is also why Redis is not a replacement for page caching. The two solve different problems, and on many sites they work best together. Page cache handles anonymous traffic; Redis helps the dynamic traffic that page cache must bypass. For a broader view of where caching fits, see the WordPress Core Web Vitals guide and the best WordPress cache plugins review.

How to set up Redis in WordPress?

Start with the server, not the plugin. Redis must actually be running on the server, or available through your host, before WordPress can use it. If your host offers an object-cache toggle, that is often the cleanest route, because the host has already handled the server side. If you manage the server yourself, confirm Redis is installed and running before you touch WordPress.

Next, install a Redis cache plugin. The widely used free option is Redis Object Cache, which provides a persistent object cache backend powered by Redis and supports WP-CLI. Activate the plugin, then enable the object cache. Enabling it installs the drop-in file object-cache.php, which is what actually connects WordPress to Redis on every request. Installing the plugin without enabling that drop-in does not give you a persistent object cache, and this is one of the most common setup mistakes.

Then check the connection settings. The settings you need to get right are the host, port, database, and prefix. Use the values your host provides rather than guessing, especially on shared or managed hosting where Redis may not be on the same server as your site. The prefix matters when more than one site shares a Redis instance: without a distinct prefix, sites can read each other’s cached objects, which leads to confusing, intermittent problems.

• Confirm Redis is running on the server, or enabled through your host.
• Install and activate a Redis cache plugin such as Redis Object Cache.
• Enable the object cache so the object-cache.php drop-in is installed.
• Enter the host, port, database, and prefix your host provides.
• Save, then verify the connection before judging performance.

Do not change several things at once. If you install Redis, switch page-cache settings, and change hosting in the same afternoon, you will not know which change helped or hurt. Set up Redis, verify it, and only then measure anything else. If you are diagnosing slow queries alongside this, the Query Monitor tutorial is a useful companion.

How to verify Redis is working?

Verification matters more than installation. A plugin can be active, a settings page can look complete, and Redis can still not be connected. Work through these checks in order, and do not skip the last one.

• Check the plugin status. It should report that it is connected to Redis, not merely installed.
• Watch the hit and miss statistics over real traffic. A cache that is connected should show activity growing as pages are visited; a flat line is a warning sign, not a result.
• If WP-CLI is available, use the plugin’s Redis commands to check status and diagnostics from the command line.
• Warm up the cache, then repeat the same load on a representative page, such as a logged-in page or a WooCommerce page that cannot be fully page-cached. Compare the repeat load with the first load, and test the same journey a visitor would take, not only the homepage.

Test on staging first when you can. The warm-up then repeat-load method described above is a method, not a promise of a particular result: the size of any improvement depends on how much repeated database work your site was doing in the first place. If the repeat load is not clearly better on the pages that still hit PHP, treat that as a finding, not a failure of the test. It may mean those pages were not bottlenecked on object caching.

Also check the pages that matter. A faster anonymous homepage may simply reflect page caching. The honest test for Redis is logged-in browsing, search, account areas, and cart and checkout behavior. For stores, the WooCommerce cache exclusions guide explains why those pages need special handling, and the WooCommerce speed optimization guide puts Redis in the wider store-performance picture.

When does Redis do nothing?

Redis helps most where WordPress repeats expensive work for requests that still reach PHP. WooCommerce stores are a strong example: product filtering, cart fragments, account pages, and checkout all involve dynamic queries that page cache cannot serve. Sites with heavy logged-in traffic, complex search, or many repeated queries fall into the same group.

It does nothing useful in several common situations, and recognizing them saves a lot of wasted effort. If your pages are fully page-cached and almost all visitors are anonymous, the page cache is already doing the work and Redis has little left to improve. On a tiny development site with few queries, there may be almost no repeated work to cache. If Redis is not actually running on the server, or the plugin is installed but the object cache is not enabled, nothing is being cached at all. And if the cache is connected but the site’s bottleneck is elsewhere, such as slow third-party scripts or unoptimized images, Redis will not fix that.

Troubleshooting: when the numbers do not move

Not Connected. Check that Redis is running, that the host and port match what your host provides, and that no firewall or host restriction is blocking the connection. If your host manages Redis, ask for the exact connection details rather than experimenting with common defaults.

Hit rate staying at 0. Confirm the object-cache.php drop-in is present and enabled, and that you are testing pages that actually use the object cache. Anonymous pages served from a full-page cache may never touch it. Test a logged-in or dynamic page, and give the cache real traffic before drawing conclusions.

Memory eviction. If Redis runs out of memory, it starts evicting cached items, and the cache becomes less effective. Check memory use and eviction behavior with your host, reduce what is cached if your setup allows it, or increase the memory available. A cache that constantly evicts is not a stable foundation for performance work.

When to disable and retest. If you see errors, stale content that will not clear, or worse behavior after enabling Redis, disable the object cache and retest the same pages. A clean before-and-after comparison on the same journey is worth more than guessing. If the site is clearly better without it, leave it off and fix the underlying problem first. Redis is a tool, not a requirement, and a site that does not need it should not carry it. For measuring those comparisons consistently, the best WordPress speed test tools guide is a good starting point.

Redis vs Memcached, briefly. Both are in-memory stores used for object caching, and both can work well. Redis is the more common choice in WordPress hosting and plugin support, and it offers persistence and data structures that Memcached does not. Choose based on what your host supports well and what your team can maintain, not on a generic claim that one is always faster. The right question is not which tool is better in theory, but which one is actually connected, monitored, and helping on your site.

If you have checked the connection, tested a dynamic page, and still cannot tell whether Redis is helping, get a second pair of eyes on it before adding more layers. A free speed audit can sort out whether your bottleneck is object caching, page caching, queries, or something else entirely, and what to fix first.

Common Questions

Frequently Asked Questions

Clear, honest answers about Redis setup, verification, and when it does nothing.