An object cache is a store, usually held in the server’s memory, that keeps the results of database queries and other expensive calculations so a site can reuse them. Instead of asking the database the same question on every page view, the site checks the cache first and only goes to the database when the answer is missing or out of date.
How an object cache works
A dynamic site such as WordPress builds each page by running dozens or hundreds of database queries: site settings, menus, the post itself, related products, user details. WordPress already has a built-in object cache, but by default it only lasts for a single page request and is thrown away afterwards.
A persistent object cache keeps those results between requests. It is usually provided by Redis or Memcached, two memory-based stores that run alongside the web server. A small drop-in file, object-cache.php, sits in the wp-content folder and tells WordPress to read and write through that store. When content changes, the relevant entries are cleared and rebuilt on the next request.
This is different from page caching, which saves whole finished pages and hands them to anonymous visitors, and from the browser cache, which stores files on the visitor’s device. The three work together: page caching makes most public pages fast, while the object cache speeds up everything page caching cannot store.
Why it matters
Page caching cannot help with pages that are different for every visitor: shop baskets, checkouts, account areas, the WordPress admin, search results and anything behind a login. On a WooCommerce shop or a membership site, those are exactly the pages that make money, and they hit the database every time. A persistent object cache can cut the time the server takes to build them.
It also reduces load during busy periods. A UK retailer running a Black Friday email or a business featured on a regional news site gets a burst of visitors who add to basket, log in and search, and a database under strain is a common reason sites slow down at those moments. WordPress’s Site Health screen flags the absence of a persistent object cache on larger sites for this reason.
For a small brochure site with good page caching, the gain is often small. It is worth knowing about, but not worth paying more for on its own.
Common mistakes
- Expecting an object cache to improve Core Web Vitals scores that are driven by images, fonts and scripts.
- Moving a site to a new host and copying object-cache.php along with it when the new server has no Redis, which can take the site down.
- Several sites sharing one Redis server without a unique key prefix, so one site reads another’s cached data.
- Not clearing the cache after a migration or a direct database edit, so old URLs or settings keep appearing.
- Giving Redis too little memory, so entries are evicted constantly and the cache rarely helps.
How to act on it
Open Tools, then Site Health in WordPress and see whether it recommends a persistent object cache. Ask your host whether Redis or Memcached is available on your plan; many managed hosts include it and switch it on from their dashboard. Measure server response time on a basket or account page before and after, using Query Monitor or your browser’s developer tools.
Choosing the right caching layers for a WordPress site, and checking they are not serving stale content to visitors or search engines, is part of my WordPress SEO service.