WordPress
Object cache
Object cache is WordPress's key-value store for the results of expensive work, such as database query results and computed options. Without a plugin it lasts for one request. With a drop-in it persists between requests.
How it is measured
The API is wp_cache_get(), wp_cache_set(), and wp_cache_delete(), with an optional group name. Persistence requires a wp-content/object-cache.php drop-in that connects to Redis or Memcached. In Query Monitor, the Overview tab shows object cache hits, misses, and the hit ratio, and flags whether an external cache is in use.
Hit ratio above 90 percent on a warm site is a healthy sign. A ratio far below that after warm-up often points to a cache key salt that changes on every request or to flushing too often.
Worked example
A news site's wp-admin Posts list takes 4.6 seconds and runs 310 queries. Query Monitor shows no external object cache. After installing a Redis drop-in, the same page does 74 queries and finishes in 1.3 seconds.
The public home page does not improve, because it was already served from the page cache. The object cache helped the logged-in views that skip it.
How it differs
An object cache stores the pieces PHP computes while building a page, while a page cache stores the finished HTML. Redis is one backend you can plug under the object cache API, and it is not the cache itself. The object cache helps dynamic and logged-in requests; the page cache helps anonymous ones.
Common errors
Installing Redis without the drop-in. Flushing the whole cache from a deploy script and causing a stampede. Letting several sites share a Redis database with no prefix. Expecting an object cache to speed up a cached page. Storing huge arrays under one key and slowing the cache itself.
In practice
Open Query Monitor on a slow wp-admin page and note the query count and hit ratio. If no persistent cache is active and your host offers Redis, enable it on staging and compare. Set a site-specific key salt in wp-config.php.