--- title: What Is an Object Cache? How It Differs from Page Cache description: "An object cache keeps database query results in memory so the same query doesn't run over and over. Here's how it works and when WordPress needs one." canonical: https://penasihathosting.com/en/hosting-wiki/object-cache type: wiki locale: en updated: 2026-09-29 author: Willya Randika --- # What Is an Object Cache? How It Differs from Page Cache ## Overview - **Summary:** An object cache keeps database query results in memory so the same query doesn't run over and over. Here's how it works and when WordPress needs one. - **Author:** Willya Randika ([profile](/penulis/willya-randika)) ## Article ## What Is an Object Cache? An object cache is a temporary in-memory store (RAM) that holds **database query results** so the same query doesn't have to run again every time that data is requested. On dynamic sites like WordPress, nearly every page triggers many [MySQL](/en/hosting-wiki/mysql) queries: post titles, theme options, plugin data, user info. Without an object cache, identical queries get executed over and over — per page render, even per menu click. 💡 A Simple Analogy: Think of a restaurant cook. Without an object cache, every single order sends him downstairs to the storage room to fetch the same eggs, again and again. An object cache is the mise en place on his counter: already measured, ready to grab. The storage room (your database) remains the source of truth — it just gets visited far less often. ## How an Object Cache Works The flow is straightforward: 1. The application (say, WordPress) needs some data and builds a cache key. 2. It first asks the object cache: is the result already in memory? 3. On a cache *hit*, the data is used immediately — the database query is skipped. On a *miss*, the app queries the database and stores the result for next time. In WordPress this is exposed through the `wp_cache` API. By default the cache lives only for one request — gone once the page finishes rendering. The real benefit appears with a *persistent object cache* backed by Redis or Memcached, which survives between requests. ## Object Cache vs Page Cache: Don't Mix Them Up This is the most common confusion, and worth resolving because the two solve different problems. * **Page cache** stores **finished HTML pages**. Visitors get a ready-made file without the application running at all. This is the first layer of [web cache](/en/hosting-wiki/web-cache). * **Object cache** stores **query results**, used when a page genuinely must be built — for logged-in users, shopping carts, personalized content. For a blog where everyone sees the same thing, page cache alone is already fast. For WooCommerce or membership sites — every visitor sees something different — page caching must not serve one person's cart to another, and that's where the object cache earns its place. ## Why It Matters When Choosing Hosting The practical question: does your plan support Redis or Memcached? Modern [WordPress hosting](/en/wordpress-hosting) and cloud plans usually do — sometimes with a one-click toggle. Budget shared hosting sometimes doesn't, leaving you with plugin-level caching only. On a [VPS](/en/vps-hosting) you can run Redis yourself, but remember: the object cache lives in RAM. Adding Redis means carving out memory PHP also wants. If RAM is already tight, enabling it can backfire — don't turn everything on at once without counting capacity. ## Common Mistakes and Tips **Enabling an object cache on a static-ish blog.** Hit rates stay low, the effect is nil, and you've added another service to babysit. Turn it on when repeated queries actually hurt. **Expecting it to magically fix TTFB.** It speeds up the database side of rendering; network issues and heavy browser-side themes are untouched. **Forgetting to flush after a migration.** Moving servers or restoring a backup while Redis holds stale data produces bizarre content. Clear the cache after any major change. **Thinking it replaces [OPcache](/en/hosting-wiki/opcache).** Both are memory caches, but OPcache stores compiled PHP bytecode, the object cache stores query data. For a healthy WordPress, they complement each other. ## FAQs ### Does WordPress need Redis? "Need" in the sense of "benefits": on query-heavy sites — stores, memberships, lots of logged-in users. A small blog with good page caching rarely sees a meaningful difference. ### Doesn't an object cache eat RAM? Yes. Its contents occupy server memory, so its size should be limited and watched. On shared hosting, the provider usually caps this per account for you. ### Which plugin should I use? For WordPress, common choices are Redis Object Cache, or W3TC/LiteSpeed with their object-cache modules. The plugin is only a bridge; the actual work happens in Redis/Memcached on the server — so confirm your hosting offers it. ### How do I know the cache is working? Check the hit rate in the plugin dashboard, or query Redis directly. A hit rate that climbs after a few hours of traffic means it works. All misses usually mean the connection isn't set up right.