Page caching is worth testing when generating HTML repeatedly slows your server down and visitors can safely receive the same page. If your host already caches pages, or HTML responses are already fast enough, check what an additional caching plugin would actually improve before installing one.
Start with public pages viewed while logged out. Keep login, account, cart, and personal calendar pages out of the initial shared-cache test. Check that edits and access changes reach visitors correctly as well as measuring response time. The table below will help you choose a starting point for your setup.
Check your existing cache before adding another one
Your host or web server may already cache HTML. Adding a plugin can introduce another stored copy and another place to clear it when content changes. First, find out what the current cache covers and how it updates.
I'd start with one public article viewed while logged out and record the following.
| What you find | What it suggests | What to do next |
|---|---|---|
| Your host or web server already caches HTML | The existing cache may be sufficient | Keep it initially and check its coverage, exclusions, and update behavior |
| There's no page cache, and server processing is repeatedly slow | Page caching is a candidate for testing | Start with one type of public page in a test environment |
| The first response is still slow with caching enabled | The cache may be missing, or another delivery delay may be involved | Investigate cookies, URLs, redirects, connections, and server load separately |
| HTML arrives quickly, but a heading or image appears late | An HTML cache may not address the bottleneck | Investigate the relevant files and browser rendering work |
- Your host or web server already caches HTML
- What it suggestsThe existing cache may be sufficient
- What to do nextKeep it initially and check its coverage, exclusions, and update behavior
- There's no page cache, and server processing is repeatedly slow
- What it suggestsPage caching is a candidate for testing
- What to do nextStart with one type of public page in a test environment
- The first response is still slow with caching enabled
- What it suggestsThe cache may be missing, or another delivery delay may be involved
- What to do nextInvestigate cookies, URLs, redirects, connections, and server load separately
- HTML arrives quickly, but a heading or image appears late
- What it suggestsAn HTML cache may not address the bottleneck
- What to do nextInvestigate the relevant files and browser rendering work
As in the first article, Time to First Byte (TTFB) can include connection and network time. A slow initial response alone doesn't establish that PHP or the database is responsible. WordPress optimization overview
Cache pages that visitors can safely share
A public article and an account page need different caching rules. The article may look the same to many visitors, while names, shopping carts, and personal schedules vary by user. Check whether the HTML contains personal data, rather than relying on login status alone.
| Page or feature | Initial decision | What to check |
|---|---|---|
| Public article viewed while logged out | A reasonable first test | Content, menus, images, and update timing |
| Homepage or category listing | Can be cached, with the right invalidation rules | Listings after publication, edits, and changes to private status |
| Login, admin, or account page | Exclude from the initial shared HTML cache test | Authentication state and whether one visitor's information could reach another |
| Cart, checkout, or personal calendar | Exclude from shared caching until its behavior is understood | Sessions, permissions, live values, and the service's documented exclusions |
| Search results or URL parameters | Determine whether results can be shared safely | Whether search terms, language, and filters are included in the cache key |
| An app with shared HTML and private data fetched through JavaScript | Evaluate HTML and data requests separately | API authentication, response caching, and stale security tokens embedded in HTML |
- Public article viewed while logged out
- Initial decisionA reasonable first test
- What to checkContent, menus, images, and update timing
- Homepage or category listing
- Initial decisionCan be cached, with the right invalidation rules
- What to checkListings after publication, edits, and changes to private status
- Login, admin, or account page
- Initial decisionExclude from the initial shared HTML cache test
- What to checkAuthentication state and whether one visitor's information could reach another
- Cart, checkout, or personal calendar
- Initial decisionExclude from shared caching until its behavior is understood
- What to checkSessions, permissions, live values, and the service's documented exclusions
- Search results or URL parameters
- Initial decisionDetermine whether results can be shared safely
- What to checkWhether search terms, language, and filters are included in the cache key
- An app with shared HTML and private data fetched through JavaScript
- Initial decisionEvaluate HTML and data requests separately
- What to checkAPI authentication, response caching, and stale security tokens embedded in HTML
These are conservative starting rules, not a claim that logged-in pages can never be cached. FlyingPress, for example, supports separate caches by user role. A shared role doesn't by itself make personalized content safe to cache, so I'd evaluate that feature separately from ordinary public pages. FlyingPress caching by user role
Understand what reusing HTML saves
Without a page cache, WordPress runs PHP and retrieves information from the database to build HTML for a request. When the content hasn't changed and the visitor can receive the same page, some of that repeated work can be avoided.
A page cache stores finished HTML for reuse. Depending on the server and product, the response may be served before PHP and WordPress run, or after some code has already executed. Check how your host or caching product serves a cached page instead of assuming every cache follows the same path.
A cache hit, or HIT, means the cache found a usable copy for the request. A cache miss, or MISS, means it didn't.
HIT: a usable HTML copy is available
- BrowserRequests the page
- Cache handling layerFinds stored HTML
Response: Stored HTML returns to the browser. The serving path depends on the product and server settings.
MISS: no usable copy is available
- BrowserRequests the page
- Cache handling layerNo usable copy
- WordPress and databaseBuild the HTML
Response: Generated HTML returns to the browser. Storage and regeneration timing depend on the product.
This is a conceptual model. I didn't disable my production cache or run a new before-and-after test for this article. I also haven't used measurements from my existing site as a baseline for a server without a CDN.
WordPress documents page caching and object caching separately. An object cache reuses data used by WordPress; a page cache reuses a finished page. Having an object cache such as Redis doesn't establish that HTML page caching is enabled too. WordPress caching documentation
Confirm cache hits and check the returned content
On a miss, some products generate the page, respond, and store a copy. Others schedule cache generation in the background. One request immediately after clearing the cache isn't enough to decide that caching has failed.
FlyingPress, which I use on my site, documents a workflow in which an uncached page is served before optimization and cache generation follow. That is one product's behavior, not a configuration recipe for every cache. When and where FlyingPress caches pages
Response headers and cache dashboards provide useful clues, but they don't replace checking the page. An intermediate proxy may replay a stored header, and a cached HTML response can still contain old content.
- Open a public article while logged out. Save the HTML request's headers, content, and inspection time.
- Confirm that cache generation has finished according to the product's documentation, then repeat the request under the same conditions.
- Record the cache status and verify that the response contains the content you expect.
- Record browser and server cache states separately. DevTools' Disable cache option doesn't clear server-side copies.
Test updates as well as response time
A fast response isn't enough if readers keep receiving an old article. Purging removes or invalidates a cached copy. Preloading generates pages ahead of subsequent visits. They serve different purposes.
Use synthetic posts in a test environment and keep a way to restore the original content and settings. Decide which pages each change should update before running the test.
| Change to test | Expected result | What to inspect |
|---|---|---|
| Edit an article | The response contains the new text | The article's HTML and rendered page |
| Publish a post | Relevant homepage and category listings include it | Publication conditions, ordering, and exclusions |
| Make a post private | Logged-out access is blocked and listings no longer include it | The post, related listings, and intermediate caches |
| Change a menu or shared page element | Relevant pages show the change | Several representative articles on desktop and mobile |
| Simulate a failed update job | The failure is visible and recovery is possible | Job status, the previous settings, and returned content |
- Edit an article
- Expected resultThe response contains the new text
- What to inspectThe article's HTML and rendered page
- Publish a post
- Expected resultRelevant homepage and category listings include it
- What to inspectPublication conditions, ordering, and exclusions
- Make a post private
- Expected resultLogged-out access is blocked and listings no longer include it
- What to inspectThe post, related listings, and intermediate caches
- Change a menu or shared page element
- Expected resultRelevant pages show the change
- What to inspectSeveral representative articles on desktop and mobile
- Simulate a failed update job
- Expected resultThe failure is visible and recovery is possible
- What to inspectJob status, the previous settings, and returned content
FlyingPress documents automatic purging and preloading of related pages after content changes. A custom homepage or an additional cache layer still needs its own verification. A feature description doesn't prove that every update path on my site works. FlyingPress related-page updates
Keep the evidence needed for an adoption decision
Record uncached responses, responses after cache generation, and responses after an edit separately. Don't combine results that differ in device profile, login state, cache state, connection, or measurement tool. For repeated runs under matched conditions, record the median and range.
I'd adopt the change if HTML waiting time improves, the page and its features still work, and content and permission changes reach visitors correctly. If a cache hit doesn't reduce the delay, investigate further. Stop and roll back if a change breaks functionality or access controls.
This article contains no new before-and-after measurements. The tables describe a test procedure and decision criteria, not tests I reran on my site for this post. The historical font example in part one is not evidence of a page-caching improvement here.
The next article will cover pages whose HTML arrives quickly but whose content still appears late. I'll use the LCP element to decide whether images, fonts, CSS, or JavaScript deserve attention first.
Related reading
Part 1: Find the WordPress performance bottleneck before adding a CDN
