Is CloudFront actually caching your site?
Check it from 6 locations.

How to check if CloudFront is caching correctly

CloudFront adds an x-cache header to every response it serves. That header is the ground truth: not your distribution settings, not what a plugin claims, but what actually happened to this request at this edge location. You can read it with the checker above, in your browser's DevTools (Network tab → select the request → Response Headers), or with curl:

curl -sI https://example.com/ | grep -i -E 'x-cache|x-amz-cf-pop|age|cache-control'

A healthy cached response looks like this:

x-cache: Hit from cloudfront
x-amz-cf-pop: FRA56-P8
age: 1742
cache-control: public, max-age=86400

x-amz-cf-pop tells you which of CloudFront's 600+ points of presence answered, and age how many seconds the object has been sitting in that cache. Here is what each x-cache value means:

"X-Cache: Miss from cloudfront" on every request? The three usual causes

1. Your origin forbids caching

CloudFront respects the Cache-Control header your origin sends. If your server (or your framework, or a WordPress plugin) sends no-store, private or max-age=0, CloudFront won't keep the object, and every request stays a Miss. Check the response headers in the tool above: the fix is sending Cache-Control: public, max-age=… from the origin, or setting minimum/default TTLs in your cache policy. One CloudFront quirk to know: if the origin sends no caching headers at all, CloudFront caches for the default TTL (24 hours) anyway.

2. Your cache key is fragmented

CloudFront caches one copy per unique cache key. If your cache policy forwards all query strings, all cookies, or headers like User-Agent, then /page?utm_source=x and /page?utm_source=y are two separate cache entries, and a session cookie makes every visitor's request unique. The result is a cache that technically works but almost never hits. Forward only what actually changes the response; start from the managed CachingOptimized policy and add exceptions deliberately.

3. The cache is per location, and most locations are cold

This is the one that surprises people: a Hit in Frankfurt says nothing about Singapore. Each CloudFront point of presence keeps its own cache (with regional edge caches as a middle tier), and an object is only stored where someone has requested it. Low-traffic pages also get evicted long before their TTL runs out. In our measurement of 408,000 CDN requests, a miss was 3.5× slower than a hit at the median. That's exactly why the checker above tests from six locations at once.

Checking your CloudFront cache hit ratio

For the aggregate view, open the AWS console → CloudFront → your distribution → Reports & analytics → Cache statistics. The "percentage of viewer requests by result type" chart is your hit ratio over time. As a rule of thumb: static assets should sit at 95%+, and a well-configured site can reach 85–95% for HTML. If your ratio is much lower, work through the three causes above in order; cache-key fragmentation is the most common culprit on real-world distributions.

Clearing the CloudFront cache (invalidations)

To purge cached objects, create an invalidation on the distribution (console → Invalidations → Create, or aws cloudfront create-invalidation --distribution-id ID --paths "/*"). Two things worth knowing:

• Costs: the first 1,000 invalidation paths per month are free, after that $0.005 per path. A wildcard like /* counts as a single path.
• For assets, version instead of invalidating: content-hashed filenames (app.a1b2c3.js) with long TTLs never need invalidation. Reserve invalidations for HTML and other stable URLs.

And remember what an invalidation does globally: it empties the cache in every edge location at once. Right after a deploy plus invalidation, your whole edge is cold and every first visitor per location pays the full origin round trip.

From checking to fixing: keep the cache warm

Checking tells you where the cache is cold. Warming fixes it: requesting your pages through CloudFront from many regions on a schedule, so each edge location has already pulled and stored the object before a real visitor arrives. warmup.rocks does that from 42 countries, verifies the x-cache header of every response, and re-warms automatically after your deploy hook fires, which is the natural companion to an invalidation.

FAQ