# Object Cache Explained (No Technical Jargon)
Your WordPress site makes 80 database queries to load one page. It doesn’t have to.
Most sites query the database for the same information, on every single page view. Your site title. Your active plugins. Your menu structure.
Object cache remembers these answers. So your server doesn’t ask the same questions a thousand times per minute.
—
## The Restaurant Analogy
Imagine a busy restaurant.
**Without object cache:**
Every time a customer orders water, the waiter runs to the kitchen, fills a glass, and walks back. Even the next table ordering water means another trip to the kitchen.
**With object cache:**
The waiter remembers: “The kitchen has a water station.” After fetching water once, they know where to go. No need to think about it again.
Your WordPress database is the kitchen. PHP is the waiter. Object cache is the memory of where things are.
—
## Why WordPress Queries the Database 100x Per Page
Here’s what happens on every page load:
1. **Site options** loaded (20-50 queries)
2. **Post metadata** retrieved (10-30 queries)
3. **User capabilities** checked (5-15 queries)
4. **Transient values** accessed (5-10 queries)
That’s before your content even displays.
Object cache stores these in RAM instead. RAM is 10,000x faster than asking the database.
—
## What Gets Cached?
Not everything. Just the things WordPress asks for repeatedly.
| Data Type | Typical Queries/Page | Cached? |
|———–|———————|———|
| Site options | 20-50 | Yes |
| Post metadata | 10-30 | Yes |
| User data | 5-15 | Yes |
| Transient API calls | 5-10 | Yes |
| Taxonomy terms | 5-15 | Yes |
| Cache invalidation keys | 5-10 | Yes |
| Actual post content | 1-2 | Sometimes |
**With object cache enabled:** 100 queries → 12 queries.
**Result:** Page load time drops 200-800ms.
—
## Redis vs Memcached: Which One?
They do the same job. Store data in RAM. Serve it fast.
**Redis** (more common, more features)
– Persistent storage option
– Built-in data types (lists, sets, hashes)
– Can survive a server restart
– Slightly heavier on resources
**Memcached** (simpler, lighter)
– Pure cache, nothing persistent
– Drops everything on restart
– Lower memory overhead
– Easier to configure
**Which should you use?**
Most managed WordPress hosts give you Redis or Memcached pre-configured. Use what they offer.
If you’re self-hosting: Redis for complex setups. Memcached for simple caching.
—
## How to Enable Object Cache
### Method 1: Your Host Does It (Easiest)
**Rocket.net:** One-click enable in the panel
**Kinsta:** Add `REDIS_HOST` and `REDIS_CACHE_KEY` constants
**Cloudways:** Enable in Application Settings
**WP Engine:** Automatic, no setup needed
### Method 2: WP-Config (When Your Host Supports It)
Add to `wp-config.php`:
“`php
define(‘WP_CACHE’, true);
define(‘WP_REDIS_HOST’, ‘
define(‘WP_REDIS_PORT’, 6379);
“`
Then install the Redis Object Cache plugin or enable via WP-CLI:
“`bash
wp plugin install redis-cache –activate
wp redis enable
“`
### Method 3: Plugin-Based (Last Resort)
If your host doesn’t support object cache natively, use:
– **LiteSpeed Cache** (if on LiteSpeed server)
– **WP Super Cache** (basic file-based caching)
– **Batcache** (if on WordPress.com VIP or similar)
**Note:** File-based caching ≠ Redis/Memcached. It’s slower, but still helps.
—
## Checking If It’s Working
### Method 1: Query Monitor (Visual)
Install the Query Monitor plugin. Look at the “Queries” tab.
**Before object cache:** 80-150 queries
**After object cache:** 10-30 queries
### Method 2: WP-CLI (Command Line)
“`bash
wp cache stats
“`
Shows hits, misses, and memory used.
### Method 3: Debug Bar
If you have `WP_DEBUG` enabled, look for object cache stats in the debug panel.
—
## When Object Cache Breaks Things
Object cache is not magic. It’s a trade-off.
**Cache Invalidation Problems**
You update a post. The cache still serves the old version. This happens when cache keys aren’t properly invalidated.
**Fix:** Clear the cache manually after major updates. Most hosts have a “Purge Cache” button.
**Stale Data During Development**
You’re editing code, but nothing changes. The cache is serving yesterday’s files.
**Fix:** Disable object cache in development.
“`php
// In wp-config.php for dev environments
if (defined(‘WP_DEBUG’) && WP_DEBUG) {
define(‘WP_CACHE’, false);
}
“`
**Plugin Conflicts**
Caching plugins often conflict. Don’t run Redis Object Cache + LiteSpeed Cache + WP Rocket object cache simultaneously.
**Fix:** Pick one. Prefer your host’s recommended solution.
—
## FAQ
**Q: Will object cache fix my slow site?**
**A:** If database queries are the bottleneck (check Query Monitor), yes. If it’s large images or render-blocking JS, no.
**Q: Do I need Redis if I use a caching plugin?**
**A:** Caching plugins (WP Rocket, etc.) create static HTML files. Object cache speeds up uncached requests (logged-in users, dynamic pages). They complement each other.
**Q: How much RAM do I need?**
**A:** 64MB is enough for most WordPress sites. High-traffic sites with 50+ plugins might need 128-256MB.
**Q: Does object cache work with WooCommerce?**
**A:** Yes, but carefully. Cart/checkout/account pages are dynamic and can’t be fully cached. Use host-level object cache, not page caching, for these.
**Q: Shared hosting has object cache?**
**A:** Rarely. Object cache needs RAM outside PHP processes. Shared hosts won’t give you that. Upgrade to managed WordPress hosting or VPS.
—
## Quick Wins Summary
1. **Check if enabled** — Query Monitor shows your query count
2. **Ask your host** — Most managed hosts offer one-click enable
3. **Install the plugin** — Redis Object Cache or Memcached if self-managing
4. **Monitor hits/misses** — WP-CLI shows cache effectiveness
5. **Clear after updates** — Purge cache when content changes
**Expected impact:** 50-80% reduction in database queries, 200-800ms faster page loads.