Quick answer: Redis object caching gives WordPress a persistent in-memory store for options, query results and other objects via a drop-in (object-cache.php), instead of rebuilding them from MySQL on every request. It helps dynamic sites (WooCommerce, memberships, busy publishers) where page cache cannot cover logged-in or cart users. Use Redis alongside page caching for anonymous visitors, monitor hit rates, and flush carefully after deploys or corrupted states.
Page caching makes anonymous HTML fast. It does little for logged-in members, cart sessions or highly personalised views. That is where an object cache such as Redis earns its keep.
Object cache versus page cache versus browser cache
A quick recap (longer version in browser, page and object caching):
- Browser cache: files on the visitor’s device
- Page cache: full HTML for a URL
- Object cache: application-level objects and query results in memory
Redis is a popular engine for the third layer. Memcached is the other common choice. On WordPress hosts in 2018, Redis support is increasingly offered as a one-click add-on.
What WordPress stores in the object cache
With a persistent object cache enabled, WordPress can store:
- Options and alloptions-style lookups
- Transient values (when not forced to the database)
- Cached query results plugins and themes choose to store
- Menu and widget data depending on setup
Without persistence, WordPress still has an in-memory cache per request that dies when the request ends. Redis makes those savings survive across requests.
When Redis helps most
Strong candidates:
- WooCommerce stores with many products, options and logged-in shoppers
- Membership or LMS sites where most browsing happens after login
- High-traffic sites with expensive queries page cache cannot absorb alone
- Multisite networks with heavy options churn
Weaker candidates:
- Small brochure sites already served almost entirely from page cache
- Broken themes that bypass APIs and hammer MySQL with uncached custom SQL (Redis will not magically rewrite bad queries; you still need query hygiene)
Typical setup shape
Exact steps depend on hosting, but the shape is stable:
- Install and run a Redis server reachable from the web tier (TLS and password where supported)
- Install a Redis object cache plugin that provides the drop-in, or place a maintained
object-cache.php - Configure connection host, port, database index and authentication
- Enable the object cache and confirm WordPress reports it as connected
- Watch the site: admin screens, cart, checkout, login
Managed hosts often hide Redis behind a panel toggle. Use their documented path when you are on that platform; fighting the host’s caching stack creates double-cache confusion.
Configuration notes that matter
- Separate Redis databases or key prefixes per environment (staging vs production) so a flush on staging cannot touch production keys if they share a server
- Memory limits and eviction policy on the Redis instance; an undersized Redis that constantly evicts hot keys underperforms
- Do not expose Redis to the public internet
- Object cache ≠ session store by default; some stacks also use Redis for PHP sessions, which is a separate decision
Proving it works
After enabling:
- Check the plugin or host UI for connection status and hit/miss metrics
- Compare database query counts on a logged-in page load before and after (Query Monitor helps)
- Load cart and my-account flows repeatedly and watch origin CPU
- Confirm that updating a post or product still appears correctly (plugin cache invalidation paths)
If hit rate is tiny, you may be misconnected, constantly flushing, or running a page that barely uses the object cache APIs.
Flushes and failure modes
Flushing Redis clears stored objects. WordPress will rebuild them, which can cause a temporary load spike (cache stampede) on busy sites. Prefer targeted invalidation when tools allow it.
Symptoms of trouble:
- Odd stale options or widgets after a migrate (flush and re-test)
- Site down when Redis is unreachable and the drop-in fails hard (prefer graceful degradation configs where available)
- Conflicts with aggressive page caches serving personalised HTML (usually a page-cache rule problem, not Redis itself)
Keep backups and a way to disable the drop-in quickly via filesystem if admin becomes unreachable.
Security and operations
Treat Redis credentials like database passwords. Restrict by firewall to web nodes. On VPS builds, bind to private interfaces only. Patch Redis like any other service.
Monitor memory and CPU. A noisy plugin writing huge objects can fill Redis and hurt everyone on the server.
Pair with the rest of the performance stack
Redis does not replace:
- Image optimisation and lazy loading
- Sensible hosting
- Lean plugins (essential plugin discipline)
- Page cache for anonymous traffic
Think in layers. Each layer removes a different kind of work.
Extra practical notes
Take one afternoon to apply the ideas in this article on a staging copy first. Write down what you changed, how you tested it, and what metric should move. Small documented improvements beat large undocumented rebuilds. If you get stuck on implementation details specific to your stack, capture screenshots of settings and error messages so any specialist you bring in can diagnose quickly without starting from zero.
Migration and cloning gotchas
When you clone production to staging, either point staging at a separate Redis database or disable the object cache on staging. Otherwise staging and production can share keys and produce confusing overwrites. After a migrate to new hosting, rebuild the drop-in connection settings from scratch using the new host’s Redis credentials rather than copying old environment variables blindly. Then flush once and smoke-test login, cart and a plugin settings screen.
FAQ
Is Redis free?
Redis the software is open source. Your host may charge for a Redis add-on or the RAM it consumes. Factor that into cost versus a larger MySQL box.
Will Redis speed up a slow page builder homepage for logged-out users?
Page cache usually matters more for that case. Redis still helps admin and dynamic bits, but full-page HTML caching is the first win for anonymous marketing pages.
Can I use Redis with LiteSpeed or Varnish page cache?
Yes. They operate at different layers. Configure exclusions correctly for carts and accounts.
Faster dynamic WordPress, with eyes open
Redis object caching for WordPress sites cuts repeat database work for dynamic and logged-in traffic. Enable it when page cache alone leaves MySQL busy, validate hit rates, and keep it secured and sized properly. Combined with good page caching and lean plugins, it is one of the most reliable backend performance upgrades you can make.
If you need WordPress performance tuned across page cache, object cache and hosting, our Turn visitors into customers work includes practical speed fixes aimed at real user paths, not only homepage scores.
