This glossary explains the WordPress performance terms that show up in cache reports, hosting support replies, plugin settings, and CDN dashboards. It is written for site owners who need enough technical vocabulary to make safe decisions.
Core cache terms
Page cache
Page cache stores the final HTML of a public page. Instead of asking WordPress, PHP, and the database to rebuild a post for every visitor, the cache serves a stored copy. This is usually the biggest performance win for blogs, documentation sites, marketing sites, and other public content.
Object cache
Object cache stores repeated database query results and computed values. Redis and Memcached are common persistent object-cache systems. Object cache helps dynamic workloads, admin screens, ecommerce, and logged-in experiences, but it does not replace public page cache.
Browser cache
Browser cache stores files on the visitor’s device, usually images, CSS, JavaScript, and fonts. It reduces repeat downloads but does not prove that the main WordPress HTML page is cached by a shared layer.
CDN
A content delivery network serves assets or pages closer to visitors. Some CDNs only cache static files. Others can cache HTML at the edge when rules are configured safely.
Infrastructure terms
| Term | Plain-English meaning | What to verify |
|---|---|---|
| Varnish | A reverse proxy cache often placed in front of the web server. | Public pages HIT; private pages bypass; purges work after updates. |
| Nginx FastCGI cache | Server-level cache for PHP-generated responses. | Cache keys, cookies, bypass rules, and purge behavior. |
| LiteSpeed Cache | A server cache plus WordPress plugin ecosystem when running LiteSpeed. | Whether the server cache is active, not only the plugin settings screen. |
| Redis | An in-memory data store commonly used for persistent object cache. | The WordPress drop-in is connected to a running service. |
| Memcached | An object-cache service used by some hosts and WordPress stacks. | Connection health and whether the site benefits from it. |
Report status terms
HIT
A cache layer served the stored response. Good for public pages. Risky for personalized pages.
MISS
The cache did not serve a stored response. A first MISS can warm the cache. Repeated MISS responses on public pages may mean something is preventing storage.
BYPASS
The cache intentionally skipped the request. Common causes include cookies, login state, query strings, private headers, excluded paths, POST requests, carts, and account pages.
STALE
The cache served an older response, often while refreshing in the background or protecting the site during origin trouble.
Unknown
The report cannot prove the state from exposed evidence. Unknown is a call for manual verification, not a verdict of failure.
Headers and rules
- Cache-Control: tells caches whether a response can be stored and for how long.
- TTL: time to live; the period cached content can remain valid.
- Purge: deleting cached content before normal expiration.
- Warm cache: a cache that already has stored responses ready.
- Cold cache: a cache with no stored copy yet.
- Set-Cookie: a response header that can make caches treat a page as personalized.
- Cache key: the identity used to decide whether two requests can share the same cached response.
- s-maxage: Cache-Control directive for shared caches such as CDNs and proxies.
WordPress safety terms
Logged-out visitor means a normal public visitor with no admin cookie. That is the baseline for page-cache testing. Private page means a URL that may contain user state, account information, checkout behavior, cart contents, previews, or admin-only content. A healthy cache stack should treat public and private pages differently.
Why the glossary matters
WordPress performance gets easier when the vocabulary is clear. If a report says the homepage is HIT, a post is BYPASS because Set-Cookie appears, Redis is installed but not connected, and checkout is safely excluded, a site owner can act. WPColt exists to turn that kind of evidence into the next sensible step.