A CDN is supposed to serve cached copies of your pages from edge servers close to your visitors. That's the pitch. In practice, many sites route through a CDN that caches almost nothing.
The symptoms are subtle. Your site loads fine. Your hosting bill seems normal. But every request is hitting your origin server because the CDN can't cache your responses. Maybe your Cache-Control headers are missing. Maybe they say no-cache or private. Maybe your application sets cookies on every response, which most CDNs treat as a signal not to cache.
How to tell if your CDN is actually working
Response headers don't lie. Every major CDN adds headers that tell you exactly what happened:
Cache-Status (the standardized header, RFC 9211) tells you whether the response was a hit, miss, or bypass, and why. Cloudflare, Fastly, and Akamai all use some version of this.
CF-Cache-Status is Cloudflare's proprietary version. HIT means the edge served it. MISS means the edge fetched from origin. DYNAMIC means Cloudflare decided not to cache it at all.
X-Cache is what AWS CloudFront and Varnish use. Hit from cloudfront vs Miss from cloudfront.
Age tells you how many seconds ago the edge cached this response. An Age of 0 on every request means you're getting constant cache misses.
If you're seeing MISS or DYNAMIC on pages that should be cacheable, your CDN is functioning as an expensive reverse proxy. You're paying for edge distribution and getting none of the speed benefit.
Common reasons caches miss
Missing Cache-Control. If your server doesn't send a Cache-Control header, most CDNs won't cache the response. They need explicit permission.
Set-Cookie on cacheable pages. If your application framework sends a session cookie on every response, most CDNs skip caching entirely. This is the most common accidental cache-buster.
Vary: * or overly broad Vary. A Vary: * header tells caches that every request is unique. Nothing gets cached. Even Vary: Cookie effectively disables caching for logged-in traffic.
Query string variations. If your analytics adds a ?utm_source=... to every URL, each combination gets cached separately. Your CDN cache fills up with thousands of nearly identical copies.
What the tool does
The Edge Cache Effectiveness Probe sends requests to your URLs and reads the cache-related response headers. It tells you the cache status, the TTL, the age of the cached copy, and whether your origin is being hit when it shouldn't be.
For a list of URLs, it calculates your aggregate cache hit ratio, which is the number that actually matters for performance and cost.
If you're standing up CDN-backed sites for clients and want to make sure the caching layer is doing its job, The $20 Dollar Agency covers the headers to get right before launch.
Fact-check notes and sources
- RFC 9211 "The Cache-Status HTTP Response Header Field": IETF RFC 9211
- Cloudflare CF-Cache-Status values: Cloudflare docs
- Set-Cookie preventing CDN caching: documented in Cloudflare, Fastly, and Akamai documentation as default behavior
- Chrome cache partitioning (2020) means CDN cross-site caching no longer helps end users: Chromium blog
Related reading
- Compression codecs: Brotli vs gzip vs zstd
- Response size budget and performance limits
- Early Hints for parallel fetching
- CrUX field data: the metrics Google ranks on
This post is informational, not hosting or CDN-consulting advice. Mentions of Cloudflare, AWS CloudFront, Fastly, and Akamai are nominative fair use. No affiliation is implied.
