Visit Website →
← Back to blog

Hit a 50%+ Cache Ratio with Redis Object Cache for WordPress

September 29, 2026
Hit a 50%+ Cache Ratio with Redis Object Cache for WordPress

Redis object cache gives WordPress a persistent, in-memory storage layer for database query results, session data, and transients, cutting the repeated database lookups that slow down dynamic pages. It benefits high-traffic blogs, WooCommerce stores, and sites with sluggish admin dashboards, and it requires a running Redis server plus a compatible plugin or drop-in file. If it's already installed, the next move is confirming it's actually caching, not just present.

TL;DR:

  • Proper Redis setup requires matching the plugin version, PHP extension activation, and correct configuration of connection details, memory limits, and key prefixes for stability.
  • Keeping Redis on the same local network or server as WordPress significantly reduces latency and improves cache speed compared to remote instances.
  • Monitoring cache metrics such as keyspace hits, misses, evicted keys, and latency is essential for maintaining optimal performance and avoiding memory-related issues.
  • Misconfigurations like an incompatible eviction policy, key prefix conflicts, or missing $found parameter checks in cache calls can cause subtle bugs that negate speed benefits.
  • High-traffic WooCommerce stores or large multisite networks often require enterprise features like auto-tiering, persistence, or higher memory limits for reliable caching at scale.
inSave Hosting
Simplify Your WordPress Hosting
InSave Hosting combines WordPress-focused hosting, performance features, security tools, and migration support for smoother website management.
Explore hosting solutions

Table of Contents

How Redis object caching works with WordPress

WordPress ships with an object cache by default, but that cache is non-persistent: it resets on every page load, so it only helps within a single request. Redis replaces that with a persistent backend that survives between requests, so a query run on one-page load can be reused on the next.

The mechanism runs through two core functions, wp_cache_get() and wp_cache_set(). When a plugin or WordPress core calls wp_cache_get(), the request goes to Redis instead of re-querying MySQL, and wp_cache_set() writes the result back for future use. The Redis Object Cache plugin handles this connection and supports several client libraries and deployment patterns.

  • PhpRedis and Predis are the two supported PHP clients, with PhpRedis generally preferred for its speed since it's a compiled C extension.
  • Clustering and Sentinel setups are supported for high-availability Redis deployments.
  • TLS connections and WP-CLI commands are built in, letting developers manage the cache from the terminal.

Before installing anything, check the plugin's own listing for its tested WordPress version and PHP requirement, since object cache drop-ins interact deeply with core and a mismatch can cause instability.

Installation and configuration for common hosting setups

Getting Redis running behind WordPress involves three separate pieces: the Redis server itself, a PHP extension that lets PHP talk to it, and a plugin or drop-in file that tells WordPress to use it. Skipping any one of these leaves the cache silently inactive.

Pro Tip: Confirm the PhpRedis extension is enabled with php -m | grep redis before installing any plugin, since a missing extension is the most common reason Redis caching never activates.

  1. Provision a Redis server, either installed directly on a VPS or dedicated box, or provisioned through a managed hosting environment that already runs Redis for you.
  2. Enable the PhpRedis PHP extension (or Predis as a fallback if the extension isn't available) so PHP can open a connection to Redis.
  3. Install the Redis Object Cache plugin from the WordPress plugin directory, or drop object-cache.php into wp-content manually.
  4. Set connection parameters in wp-config.php: host, port, authentication password, and TLS flags if the connection crosses a public network.
  5. Enable the object cache from the plugin's settings screen or with WP-CLI, then run a test page load to confirm it connects.

A few configuration details matter more than they look. Set a unique key prefix (WP_REDIS_PREFIX) for every site sharing a Redis instance, since two sites writing to the same keyspace will corrupt each other's cached data. On multisite or when you run staging and production against the same server, assign each environment its own Redis database number rather than relying on prefixes alone.

Memory settings deserve attention too. For a caching workload, maxmemory should be set to a sensible limit and paired with an eviction policy, since an unbounded cache will eventually consume all available RAM. Redis eviction policy documentation recommends allkeys-lru as a reasonable default when you're not sure which policy fits your access pattern.

Network latency is the detail most setups get wrong. Redis is fast, but a round trip to a remote server on a different network adds latency to every single cache read, and WordPress makes many of them per page load. Keeping Redis on the same machine or the same private network as the web server matters more for perceived speed than adding extra memory to a distant instance. For readers who want a walkthrough with screenshots, our guide on enabling object cache on WordPress covers the same flow with quick fixes for common install snags.

WP-CLI, Redis CLI, and developer checks for verifying the cache

Once Redis is connected, confirm it's actually doing its job rather than assuming the plugin activation screen tells the whole story.

  • Run wp redis status to see connection details and whether the drop-in is active.
  • Run wp redis cli info or connect directly with redis-cli INFO to pull keyspace_hits, keyspace_misses, evicted_keys, and used_memory_dataset.
  • Use redis-cli LATENCY HISTORY to spot recent latency spikes tied to slow commands.
  • Flush selectively with wp cache flush only when necessary, since a full flush discards every warm entry and temporarily slows the site while the cache repopulates.

At the code level, one bug shows up constantly: calling wp_cache_get() without its $found parameter. If a cached value is false, null, or 0, code that only checks the return value can't tell a legitimate stored value apart from a cache miss. The WordPress developer documentation for wp_cache_get() recommends always passing $found when cached values might be falsey, and testing this on staging before pushing a caching-dependent plugin update to production catches the bug before it reaches visitors.

Common problems and fixes for Redis-backed WordPress sites

Most Redis-related WordPress failures trace back to one of four causes: a broken connection, a memory limit hit with the wrong eviction policy, a key prefix collision, or a plugin that assumes cache values are never falsey.

  1. Site crashes or throws errors when Redis is unreachable. This usually means the Redis service stopped, a firewall rule changed, or connection credentials in wp-config.php are stale. Confirm the server is running with redis-cli PING and check that the host and port match what's configured in WordPress.
  2. Writes start failing under load. If Redis is configured with noeviction and hits its memory ceiling, subsequent write commands fail outright, which for WordPress can mean broken admin screens or failed page saves. Switching to an eviction policy such as allkeys-lru, or increasing maxmemory, resolves this.
  3. Two sites on the same server show each other's cached content. This is a prefix collision. Set a distinct WP_REDIS_PREFIX per site, or better, assign separate Redis database numbers to staging and production so they never share a keyspace.
  4. A plugin behaves inconsistently after caching is enabled. This often points to the $found parameter issue described above, or a drop-in that doesn't fully support the plugin's caching calls. Temporarily disable the object-cache.php drop-in on a staging copy to confirm whether the plugin misbehaves with or without Redis in the loop.

Pro Tip: Keep a staging clone with Redis disabled specifically for this kind of B diagnosis. If a bug disappears the moment the drop-in is removed, the root cause is almost always cache-related, not the plugin itself.

Watching evicted_keys and the hit ratio over time catches memory pressure before it turns into an outage, which is exactly what the next section covers.

Performance monitoring and operational best practices

A Redis instance that's technically running isn't the same as one that's helping. The number that matters most is the cache hit ratio: hits divided by the sum of hits and misses. Redis's own monitoring guidance treats a hit ratio above 50% as a general guideline for a healthy cache, and a ratio well below that suggests the cache is either too small, misconfigured, or being invalidated too aggressively.

  • Track keyspace_hits and keyspace_misses from INFO output to calculate the hit ratio over time.
  • Watch evicted_keys: a rising count means the working set no longer fits in available memory.
  • Monitor used_memory_dataset against your configured maxmemory to see how close the instance is to its ceiling.
  • Use LATENCY DOCTOR for a plain-language read on which commands are causing slow responses.

For caching workloads specifically, Redis documentation notes that letting memory reach 100% is acceptable as long as an eviction policy is in place, since evictions are the intended way a cache sheds old data. The trade-off is that heavy eviction activity increases write latency, so a spike in evictions alongside slowing page loads is a signal to look at memory sizing, not just accept it as normal wear. allkeys-lru remains the common default for general caching, while volatile-ttl fits better when the application already assigns expiration times to cached objects, per Redis's eviction policy reference.

Scaling signals worth watching for: a hit ratio that keeps declining despite no code changes, eviction counts climbing week over week, or latency samples from Redis's latency monitoring tools showing recurring spikes on the same command. Any of these point toward more memory, a second instance, or, for very large datasets, tiered storage options. A short-TTL local cache in front of Redis for a handful of extremely hot keys can also relieve pressure without a hardware change. For a broader look at how server-level caching layers interact with object caching, see our guide on caching in hosting environments.

Illustration of cache hits evictions and latency

Advanced options beyond a basic Redis setup

Readers running high-traffic WooCommerce stores or agencies managing many client sites often outgrow the free plugin and stock Redis configuration. Object Cache Pro is the commercial step up, adding batched server requests, compression that reduces memory and network overhead, cache prefetching, built-in analytics, TLS support, and dedicated health checks.

On the Redis side, enterprise deployments add features like Auto Tiering, which keeps hot data in RAM while moving warm data to flash storage, described in Redis's Auto Tiering documentation, and persistence options such as RDB snapshots or AOF logs for durability, covered in Redis's persistence guide. Most pure caching setups run without persistence at all, since the data is disposable and rebuilds from the database.

  • Consider the upgrade path when your working set regularly exceeds available memory.
  • Consider it when traffic patterns show sustained high write volume, not just reads.
  • Consider it when your team lacks the operational capacity to hand-tune eviction and monitoring.
  • Weigh the added cost against how much manual tuning it would replace.

Running Redis object cache at the hosting level

Hosting teams generally choose between a local Redis instance on the same server as WordPress or a managed, remote Redis service, and the decision comes down to latency tolerance and how much operational overhead the team wants to own. A local instance keeps round trips short, which matters given how many cache reads a single WordPress page load generates.

On the hosting side, the safeguards that matter are consistent PHP extension management so PhpRedis stays available across updates, TLS support for any connection that crosses a network boundary, and routine monitoring of the Redis service itself, not just the website in front of it. Daily backups and staged migrations reduce the risk of losing cache configuration during a server move. Our piece on WooCommerce hosting requirements covers how these same considerations play out for stores with heavier database loads.

What the data actually supports

The most overrated piece of advice in Redis object cache guides is that installing the plugin alone fixes slow WordPress sites. It doesn't. A misconfigured eviction policy, a missing key prefix, or code that never checks the $found parameter can quietly cancel out any speed gain, and none of those show up as an error message. They show up as a site that feels the same as before, or worse, one that fails unpredictably under load.

What deserves more attention than it gets is monitoring. Most WordPress site owners treat Redis as fire-and-forget: connect it once, never look at the hit ratio again. That's backward. A cache hit ratio and eviction count checked monthly would catch memory pressure long before it becomes a crash during a traffic spike.

If there's one thing to prioritize first, it's proximity: keeping Redis close to the web server matters more than almost any other tuning decision, including memory size. A fast connection to a well-configured cache beats a slow connection to a generously sized one every time.

— Ihor

Making Redis-backed WordPress hosting simpler

Setting up Redis correctly involves PHP extensions, connection parameters, eviction policies, and ongoing monitoring, which is a lot of moving parts for a site owner who just wants faster page loads. inSave Hosting

Our WordPress hosting plans, including WP Start, WP Growth, WP Pro, and WP Agency, are built to handle PHP extension management and Redis compatibility without you having to touch a server configuration file. For readers who want full control over their own Redis instance, our VPS hosting plans, iS-11 through iS-22, give you root access to configure eviction policies and memory limits directly.

  • Free migration may be included when moving a Redis-backed site from another host.
  • A money-back guarantee may cover the switch if the setup doesn't fit your workflow.

Check plan details on the WordPress hosting page or reach out about a migration to get started.

Authoritative docs and plugin pages to bookmark

Sources

FAQ

What is Redis and its purpose?

Redis is an in-memory data store that WordPress can use as a persistent object cache, keeping frequently requested database results available in RAM instead of re-querying MySQL each time. Its purpose in a WordPress context is speeding up dynamic operations like admin screens, WooCommerce lookups, and repeated queries across page loads.

Is Redis L1 or L2 cache?

Redis functions as an L2-style cache for WordPress: it sits behind the request-level (L1) object cache that WordPress uses by default, and it persists data between requests rather than resetting on every page load. Some setups add a short-lived local cache in front of Redis for extremely hot keys, which effectively creates an L1 layer ahead of it.

What are the disadvantages of using Redis cache?

Redis adds a new service to manage, monitor, and secure, along with connection overhead if it's not colocated with the web server. Misconfigured eviction policies or a missing $found parameter check in cache calls, as described in WordPress's developer documentation, can also introduce subtle bugs rather than pure performance gains.

Can Redis be used as a cache?

Yes, caching is one of Redis's most common uses, and for WordPress it works through plugins like Redis Object Cache or the paid Object Cache Pro. It stores query results and transients in memory so repeated requests skip the database entirely.