Distinguish the origin cache from the CDN cache
POM Cache and a CDN can both return a fast response, but they store different objects in different places and follow different invalidation rules.
Treat “the cache” as a stack, not a single switch.
The four observable states
| State | Where the response comes from | Does the request reach WordPress? |
|---|---|---|
| Dynamic origin render | PHP and WordPress | Yes |
| POM Cache early PHP hit | Origin index.html through the drop-in |
Only the early bootstrap |
| Apache static hit | Origin index.html through the web server |
No |
| CDN hit | Edge object | No origin request |
A CDN miss can still become a POM Cache hit at the origin. The CDN then stores the returned response according to its own behavior.
Evidence from POM Cache
An early PHP hit includes:
X-POM-Cache: Served static cache from PHP; phase=earlyApache does not add that header. Both origin paths can return a stored document containing POM Cache’s generation timestamp.
The static HTML count under POM Cache → General → Cache tools proves files exist for the current site. It does not prove the CDN contacted the origin for the viewer request being inspected.
Evidence from the CDN
CDNs can add cache-status, age, request-ID, or point-of-presence headers. Names and meanings are provider-specific.
For CloudFront, inspect its public response evidence and distribution logs rather than inferring an edge hit from low latency. An Age value, where present, describes edge storage time and is unrelated to the timestamp inside POM Cache HTML.
Do not use a vendor edge header as proof of Apache or PHP delivery.
Different lifetimes
POM Cache HTML has no age-based expiry. It remains until purged or replaced.
The CDN uses its cache behavior, response headers, TTL limits, revalidation, eviction, and invalidations. It can therefore:
- expire while the origin file remains;
- remain warm after the origin file is deleted;
- hold an older response after WordPress content changes;
- keep separate Brotli, Gzip, query, cookie, or header variants.
Origin correctness and edge freshness must be checked separately.
A layer-by-layer test
- Choose one public canonical URL.
- Use the deployment’s approved method to request the origin without a warm edge object.
- delete the current site HTML cache;
- request once and confirm WordPress generates the file;
- request again and identify PHP or Apache reuse;
- request through the public CDN and identify an edge miss;
- repeat until the provider reports an edge hit;
- change the origin only in a controlled test;
- compare origin and edge until the edge is invalidated.
Do not expose a private origin hostname or bypass credential in public diagnostics.
Diagnose stale content by layer
Origin is stale and edge matches it
Fix the content or setting, purge the appropriate POM Cache store, verify the origin, then invalidate the CDN.
Origin is current but public edge is stale
Leave the corrected origin intact and invalidate the affected public path.
HTML shell is current but progressive data is stale
Check the Progressive JSON origin file and its CDN behavior separately.
Only one encoding or image format is stale
Review the edge cache-key dimension and invalidate the public viewer path that represents all relevant variants.
Continue with Coordinate POM Cache clearing with CDN invalidation.