Edge Page Cache
Cache full HTML at CDN edge nodes — eliminating both PHP execution time and geographic network latency in one step.
Metrics
This technique can move up to 100% of LCP's share of the Lighthouse score.
This technique can move up to 67% of TBT's share of the Lighthouse score.
This technique does not move CLS.
This technique can move up to 100% of FCP's share of the Lighthouse score.
This technique can move up to 100% of SI's share of the Lighthouse score.
This technique can move up to 100% of TTFB's share of the Lighthouse score.
Overview
Edge page caching (also called CDN page caching) stores the full rendered HTML of your WordPress pages directly on CDN edge servers. When a visitor requests a page, the edge node serves the complete HTML without contacting your origin server at all — cutting TTFB from hundreds of milliseconds to single digits.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: CLS.
The Problem
Even with server-side page caching (a plugin like WP Super Cache), the HTML still travels from your origin server to the visitor over the full network distance. For visitors geographically distant from your server, TTFB remains high regardless of how fast the origin generates the page. Edge page cache eliminates that distance entirely.
Performance Impact
LCP
400–1000ms
LCP image and CSS are discovered and fetched 300–800ms earlier than with origin-only page cache
TBT
100–400ms
scripts complete downloading earlier when HTML arrives 300–800ms sooner, reducing main-thread blocking window
FCP
300–900ms
HTML arrives in 5–25ms vs 300–800ms for uncached origin — browser starts rendering immediately
SI
300–800ms
all above-fold content composited sooner across every geographic region
TTFB
pre-rendered HTML served from an edge node milliseconds away; origin server roundtrip eliminated entirely
Risk: High
logged-in users, cart, and checkout must be bypassed — misconfiguration can expose private data
How it works
01
First request triggers origin render and edge storage
The first visitor triggers a cache miss. The CDN forwards the request to the origin, which generates the full HTML. The CDN delivers the HTML to the visitor and stores a copy at the edge node.
02
All subsequent requests are served from the edge
Every subsequent visitor requesting the same URL from near that edge node receives the cached HTML directly — typically in under 20ms. The origin server receives zero requests for that page until the cache expires or is purged.
03
Cache invalidation ensures content stays fresh
When a post is published, a page is updated, or a theme changes, the CDN cache must be purged so visitors receive the updated HTML. WordPress integrations hook into post-publish events to trigger automatic URL-specific purges.
04
Dynamic content is excluded via bypass rules
Logged-in users, cart pages, checkout flows, and search results pages are identified by URL patterns or cookies (like
wordpress_logged_in_*) and bypassed — the edge fetches fresh HTML from the origin for those requests.
Limitations
- Pages displaying per-user content (account dashboards, cart, checkout) must be excluded from edge page caching. Without correct bypass rules, one user’s HTML could be served to another — a serious data privacy risk.
- Overly aggressive purging (clearing the entire CDN cache on every post update) reduces cache hit ratio and increases origin load. Overly conservative purging leads to stale content. Granular URL-level purges tied to content updates are the right approach.
- Getting bypass rules, cache headers, and purge triggers right requires careful setup. Misconfiguration — especially around logged-in users — can cause serious UX or security issues. Test thoroughly with and without cookies.
Common Mistakes
Caching pages for logged-in users
This is the most critical mistake in edge page caching. If a logged-in user’s personalised page gets cached and served to an anonymous visitor, private information is exposed. Always bypass cache for requests containing wordpress_logged_in_* cookies.
Using “Cache Everything” rules without exclusions
Cloudflare’s “Cache Everything” page rule caches all URLs by default, including dynamic pages like cart, checkout, account, and admin. This breaks functionality and can expose private data. Always pair it with exclusion rules for dynamic URLs.
Not testing cache purge on content update
After publishing a post or updating a page, verify that visitors see the updated content immediately. If the CDN is not purging correctly, users see stale HTML indefinitely. Test purge triggers as part of go-live validation.
Need help applying this to your site?
Targeted fixes, not guesswork. We identify which techniques move the needle for your specific WordPress stack.
Start an Engagement