Cloudflare vs CloudFront Cache Hit Ratios for Static Sites

For a static site, the cache hit ratio is the number that decides most of what the CDN is worth. Every hit is served from an edge location close to the reader in tens of milliseconds; every miss goes back to the origin, adds latency and costs origin requests and transfer. Cloudflare and CloudFront are the two CDNs static sites most often sit behind, and each has defaults that help or hurt the ratio in different ways.

This comparison served the same 3,800-page documentation site, with the same build and an S3 origin in eu-west-1, through both CDNs at once for four weeks — traffic split 50/50 by DNS — and measured hit ratio, origin requests, TTFB by region and cost, first with defaults and then tuned. It belongs to CDN Caching Rules for SSGs; related setup is in Tiered Caching and Origin Shield.

Method

• Site: 3,800 HTML pages, 1,900 hashed assets, about 3.2 million requests a week, readers 46% Europe, 31% North America, 23% Asia-Pacific.
• Origin: one S3 bucket. Both CDNs pointed at it; Cloudflare through a custom hostname, CloudFront with an origin access control.
• Headers from origin: HTML max-age=0, s-maxage=86400; hashed assets max-age=31536000, immutable.
• Purge on deploy: both CDNs purged after each deploy (about 6 per week).
• Measurement: CDN analytics for hit ratio and requests; S3 request metrics for origin load; RUM TTFB from the web-vitals library tagged by CDN.

Hit Ratio With Defaults

Assets hit well on both, as long-lived immutable files should. HTML was where they differed, and the reason was topology: Cloudflare had Tiered Cache enabled (on by default for this plan), so edge locations that missed asked an upper-tier data centre near the origin before going to S3. CloudFront, without Origin Shield, sent each regional edge cache's misses straight to S3. With HTML purged six times a week, every purge meant one origin request per edge cache per page, and CloudFront has more independent caches between reader and origin.

Tuning Each One

Four changes were applied to whichever CDN needed them, one per week:

1. Origin Shield on CloudFront in eu-west-1, the origin's region. All regional edge caches now fetch through one shield cache.
2. Strip query strings from the cache key for HTML and assets. Marketing links added utm_* parameters, and a docs widget appended ?ref=sidebar; each variation was a separate cache entry. On CloudFront, a cache policy with query strings set to none; on Cloudflare, a Cache Rule ignoring the query string for these paths. Cache Keys and Query Strings on CDNs covers both.
3. Targeted purges. Both had purged everything on each deploy. Purging only changed HTML paths — the deploy computed them from a manifest diff — left most cached pages valid.
4. Longer edge TTL for HTML with stale-while-revalidate. s-maxage=86400, stale-while-revalidate=600 on both, as in Stale-While-Revalidate for Static HTML.

Hit Ratio After Tuning

After tuning, the two were within a point of each other. Origin Shield alone recovered most of CloudFront's gap; query-string stripping helped both, and targeted purges were the largest single change for HTML.

TTFB by Region

Differences on hits were small and within run-to-run variation in Europe and North America. Asia-Pacific favoured Cloudflare slightly, mostly through more edge locations in the region for this audience. On misses, Cloudflare's upper tier was a little closer to the origin than CloudFront's shield path for Asian readers. Raising the hit ratio mattered far more than the choice of CDN: tuning cut median TTFB by 40–90 ms on both.

Cost

Cloudflare's free plan covers this traffic; CloudFront's free tier covers the first terabyte and 10 million requests a month. At much larger volumes, or with requirements such as AWS-native access control or specific compliance, the comparison changes — Static Site Bandwidth Pricing: Netlify, Vercel, Cloudflare models other hosts.

What Changed for Operations

Beyond the numbers, the two differed in day-to-day handling. Cloudflare's purge-by-URL API accepted the deploy's list of changed paths in batches of 30 and took effect globally in about two seconds in these tests. CloudFront invalidations accepted wildcards and up to 3,000 paths per request, took 40–90 seconds to complete, and cost $0.005 per path beyond 1,000 free paths a month — irrelevant at six deploys a week with targeted purges, but noticeable for sites that invalidated /* many times a day. Cache analytics were more immediate on Cloudflare's dashboard; CloudFront's standard reports lagged by up to an hour, and the per-path detail needed real-time logs to Kinesis or standard logs to S3 queried with Athena.

Configuration as code was available for both: Terraform providers for each covered every setting used here, which made the split test reproducible and the tuning reviewable in pull requests. The team kept the tuned configurations in the same repository as the site, so a change to cache rules goes through the same review and preview process as a change to the content.

Verdict

• Both reach 97–98% hit ratios on a static site once the cache key is clean, purges are targeted and HTML uses stale-while-revalidate.
• CloudFront needs Origin Shield to match Cloudflare's default tiered caching; without it, HTML hit ratio was 51%.
• Cloudflare was cheaper by about $40 a month at this traffic and slightly faster in Asia-Pacific.
• Choose by infrastructure and cost, not by hit ratio: an AWS-centred team gives up little by staying on CloudFront.

Pitfalls

• Comparing defaults. CloudFront without Origin Shield is not a fair comparison.
• Purging everything on every deploy. It throws away the HTML cache six times a week.
• Query strings in the cache key. Tracking parameters fragment the cache.
• Measuring hit ratio without TTFB. The ratio is a means; reader latency is the goal.

Conclusion

Served side by side for four weeks, Cloudflare and CloudFront ended within a point of each other on cache hit ratio — 98.1% and 97.4% — once each was tuned. The gap with defaults came from topology, closed by Origin Shield, and both gained most from targeted purges and clean cache keys. The choice comes down to cost and where the rest of the infrastructure lives.

FAQ

Which CDN gets a higher cache hit ratio for a static site?

In the four-week measurement in this guide, both reached about 97 to 98 percent once configured well. Out of the box Cloudflare did better, at 91 percent against 84 percent for CloudFront, mainly because Cloudflare's tiered cache was on and CloudFront's Origin Shield was not. The configuration matters more than the provider.

Why is my CDN cache hit ratio low on a static site?

Usually because of query strings in the cache key, short TTLs on HTML, cookies or headers varying the cache, or requests spread across many edge locations that each fetch from origin. Removing unneeded query strings from the cache key and adding a shield or tiered cache layer fix most of it.

Does cache hit ratio affect Core Web Vitals?

Through TTFB. A cache hit at the edge typically answers in tens of milliseconds, while a miss adds the round trip to the origin. In this measurement, TTFB at the 75th percentile was 40 to 90 milliseconds lower on configurations with higher hit ratios, which showed up as slightly lower LCP for readers far from the origin.

Is CloudFront or Cloudflare cheaper for a static site?

For the site measured here, Cloudflare's free plan served the traffic at no cost, while CloudFront cost about 41 dollars a month for 1.6 terabytes of transfer and 38 million requests after the free tier. At higher volumes, negotiated pricing and features change the comparison, so model it with your own traffic.

Related

• Parent: CDN Caching Rules for SSGs — caching policy for static sites.
• Tiered Caching and Origin Shield — the topology behind the gap.
• Purging the CDN Cache After a Static Deploy — targeted purges.
• Cache-Control Headers on S3 and CloudFront — the CloudFront header setup.
• Alerting on Cache Hit Ratio Drops — keeping the ratio high.