This glossary explains WordPress performance, caching, and site-maintenance terms in plain language. It is written for site owners who need to understand what a developer, host, plugin, or CDN is telling them during a speed or cache investigation.
Page cache
Page cache stores the final HTML of a public page so WordPress does not need to rebuild it for every visitor. It is one of the biggest performance wins for blogs, marketing sites, documentation sites, and other mostly public WordPress sites.
Object cache
Object cache stores repeated database results and expensive computed values. Persistent object cache systems such as Redis or Memcached can help busy WordPress sites, WooCommerce stores, membership sites, and admin-heavy sites, but they do not replace page cache.
Browser cache
Browser cache lets a visitor keep static files such as images, CSS, JavaScript, and fonts locally for a period of time. It reduces repeat downloads but does not normally cache the main WordPress HTML page in the same way a shared page cache does.
CDN
A content delivery network serves assets or pages from locations closer to visitors. For WordPress, a CDN may only serve static files, or it may also cache HTML at the edge if configured carefully. HTML edge caching needs strict exclusions for logged-in, cart, checkout, and account pages.
Varnish
Varnish is a reverse proxy cache often used in front of web servers. It can be extremely fast, but it must be told which responses are safe to store and when to purge them after WordPress content changes.
Nginx FastCGI cache
Nginx FastCGI cache stores PHP-generated responses at the web server layer. Many managed WordPress hosts use this kind of cache or a similar server-level approach. It can be faster and lighter than plugin-only caching when configured well.
LiteSpeed Cache
LiteSpeed Cache can refer to both the LiteSpeed server cache and the WordPress plugin used to control it. The server-level cache does the heavy lifting; the plugin often handles purge events, settings, and optimization features.
HIT
HIT usually means a cache layer served the response from storage instead of asking WordPress to build the page again. A HIT on a public page is often good. A HIT on a private account or checkout page can be dangerous.
MISS
MISS means the cache layer did not serve a stored response for that request. A first request after a purge may be a normal MISS. Repeated MISS responses on public pages may indicate a configuration issue.
BYPASS
BYPASS means the cache intentionally skipped storage or delivery. This can happen because of cookies, logged-in users, query strings, no-cache headers, excluded URLs, or commerce and membership rules.
STALE
STALE means a cache served an older response, often while it refreshed the content in the background or while the origin server was unavailable. Stale delivery can be useful, but stale pages after updates can confuse editors and customers.
Cache-Control
Cache-Control is an HTTP header that tells browsers and shared caches how a response should be treated. Directives such as public, private, no-cache, no-store, and max-age can change whether a page is cacheable.
TTL
TTL means time to live. It is the length of time a cached item can remain valid before the cache should refresh it. Short TTLs reduce stale risk. Longer TTLs reduce origin load.
Purge
Purge means deleting a cached copy before its TTL naturally expires. WordPress cache plugins often purge pages when posts are updated, comments change, products change, or theme files are modified.
Warm cache
A warm cache already has stored copies ready to serve. A cold cache has not built those copies yet. This is why the first request after a purge can be slower than the second request.
Set-Cookie
Set-Cookie is an HTTP header that asks the browser to store a cookie. Because cookies can indicate personalization, many cache layers avoid storing responses that set cookies.
WooCommerce exclusions
WooCommerce cart, checkout, account, and session-sensitive pages should usually be excluded from public page cache. Product pages can often be cached, but cart fragments, user sessions, and stock-sensitive flows need careful testing.
Cache key
A cache key is the unique identifier used to decide whether two requests can share the same cached response. URL, protocol, host, cookies, query strings, device type, currency, language, and login state can all affect the key.
Logged-out visitor
A logged-out visitor is the best baseline for public page-cache testing. WordPress admins usually see bypassed or personalized responses, so testing while logged in can make a healthy cache look broken.
Why these terms matter
Caching gets easier when everyone uses the same language. If a report says “homepage HIT, post MISS, checkout BYPASS, object cache not connected,” you can act on that. The purpose of WPColt is to turn that evidence into the next sensible step.