core

Object Cache

Object cache intercepts repeated database calls and serves the stored result instead. On a standard WordPress install with no persistent cache configured, WordPress runs these queries fresh on ev...

This entry is for WordPress users who want to understand what object cache means before configuring it on their site or asking their host about it.

An object cache is a temporary storage layer that holds the results of database queries in memory so WordPress can retrieve them instantly instead of running the same query again. Every time a page loads, WordPress queries the database repeatedly—for menus, widgets, user roles, post metadata, and dozens of other pieces of data. Without caching, every one of those queries hits the database from scratch.

What does object cache do in WordPress?

Object cache intercepts repeated database calls and serves the stored result instead. On a standard WordPress install with no persistent cache configured, WordPress runs these queries fresh on every single request. On a site with a persistent object cache—such as Redis or Memcached—results stay in memory between page loads. We’ve seen TTFB drop by 200–400 ms on moderately active sites after enabling Redis on the same shared hosting plan, with no other changes.

Persistent vs. non-persistent object cache

WordPress includes a built-in non-persistent object cache by default (via the WP_Object_Cache class, present since WordPress 2.0). It stores query results in PHP memory for the duration of a single request, then discards them. When the next request arrives, every lookup runs again.

A persistent object cache keeps those results in a dedicated in-memory store—typically Redis or Memcached—between requests. The cache survives page loads. WordPress checks the cache first; only on a cache miss does it query the database.

The difference matters most on:

  • WooCommerce stores with many concurrent sessions
  • Membership sites where logged-in users bypass page cache
  • Sites with heavy custom queries or large menus

We see this often on client WooCommerce installs: page cache handles anonymous traffic just fine, but logged-in customers—whose pages can’t be statically cached—still hammer the database until a persistent object cache is in place.

How to enable a persistent object cache in WordPress

Most managed WordPress hosts (WP Engine, Kinsta, Cloudways) include Redis object caching as a built-in option you enable in the hosting dashboard. On shared hosting or VPS setups where Redis isn’t pre-configured, the typical path is:

  1. Install the Redis Object Cache plugin from WordPress.org
  2. Confirm Redis is available on the server (phpinfo() or ask your host)
  3. Enable the cache from the plugin’s Settings → Redis screen

The plugin drops a object-cache.php file into /wp-content/—WordPress automatically uses it as a cache drop-in once it’s present. Per the WordPress developer documentation, any file at that path takes over object caching behavior.

One thing most articles skip: if your Redis instance isn’t protected with a password and is exposed beyond 127.0.0.1, you have a security problem, not a performance win. Confirm the Redis bind address before enabling.

  • Transients — database-stored temporary data with expiration times; related but distinct from object cache
  • Page cache — stores full HTML output; complements object cache rather than replacing it
  • TTFB — the latency metric object cache most directly improves
  • Redis — the most common persistent store used to back WordPress object cache
  • WP_Object_Cache — the WordPress class that manages all object caching behavior

Additional reading

Last verified: April 2026

Back to Glossary