- Article
- Beginner
- 2 minutes read
- Reviewed August 4, 2026
- WordPress performance
Page caching stores a generated HTML response and serves it again for later compatible requests.
It can bypass much of WordPress, PHP and database processing for public pages.
Cache Hit and Cache Miss
A cache hit serves an existing response.
A miss requires WordPress to generate the page and can then populate the cache.
Compare both states. A fast cached homepage can hide a very slow origin.
Cache Layers
Full-page caching can operate through:
- A WordPress plugin.
- Web server.
- Reverse proxy.
- Managed host.
- CDN edge.
- Several coordinated layers.
Avoid overlapping systems with inconsistent purge behavior.
Cache Keys
A cache must distinguish requests that produce different output.
Variations can include:
- URL.
- query parameters.
- language.
- device or format.
- selected cookies.
- logged-in state.
- currency.
- geographic region.
Poor cache keys can serve one user's content to another or fragment the cache unnecessarily.
Invalidation
Cached pages need purging when relevant content changes.
Define how publishing, menus, widgets, products, prices and templates invalidate related URLs.
Clearing the entire cache for every small change can create repeated cold-cache load.
Exclusions
Account, cart, checkout, preview and personalized pages often require exclusion or specialized handling.
The objective is not to cache everything. Separate public reusable pages from user-specific responses.
Verify the Cache
Check response headers, repeated TTFB, cookies and logged-in behavior.
Confirm that updates appear promptly and that private content is never cached publicly.
Frequently Asked Questions
Does a page-cache plugin work for logged-in users?
Many systems bypass logged-in users by default. Specialized configurations can differ.
Can page caching fix a slow checkout?
Not usually, because checkout is dynamic and personalized.
Continue Learning
Previous: Hosting and Server Performance