CDN Cache Hit Ratio
Why 95% Is Still Costing You Money — And The Miss-Ratio Math That Fixes It
Published: 2026-07-15 | jslet Research | 16 min read | Classification: Unrestricted
Executive Summary
Your CDN dashboard says 95% cache hit ratio. The bar is green. The trend line points up and to the right. You did the work — tuned the TTLs, added the Cache-Control headers, purged the old assets. 95% feels like an A.
Here's what 95% actually means: one in twenty requests still hits your origin server. At 500 million requests per month with 200 KB average objects, that leftover 5% represents 25 million origin fetches and 5 TB of origin egress. Priced at AWS standard rates, that's $540/month in egress — and that's if your origin is in us-east-1 and your users are in North America. Add cross-region transfer, add the CDN miss-fetch fees, add the origin compute cost to handle those 25 million requests, and the real number is closer to $1,200–2,500/month for traffic your CDN should never have let through.
I want to talk about the number that actually matters: miss ratio. Not the percentage of requests you cached — the percentage you didn't. Because every percentage point you shave off the miss side of the equation delivers geometrically larger returns than anything you do on the hit side. Going from 95% to 99% cache hit ratio isn't a 4% improvement. It's an 80% reduction in origin traffic — from 5% miss to 1% miss. The math is simple but the industry reflexively reports hit ratio, which masks it.
This briefing traces the miss-ratio economics across real traffic profiles and real CDN pricing. It catalogs the six structural leaks that silently eat your cache hit ratio from the inside — TTL misconfiguration, vary-header fragmentation, query string noise, cookie-based cache bypass, AI crawler URL uniqueness, and invalidation cascades. And it provides a practical TTL engineering framework you can apply this afternoon, before the next CloudFront invoice arrives.
The Miss-Ratio Lens: Stop Looking at the Wrong Number
Every CDN dashboard I've ever seen leads with a big green number: Cache Hit Ratio. Here's why that framing is economically backwards.
The Arithmetic That Changes Everything
Cache hit ratio is a linear metric on a non-linear problem. The cost impact lives entirely in the denominator — the miss fraction. Here's the same improvement expressed both ways, for a site doing 100 million requests/month with 150 KB average objects and $0.09/GB origin egress:
| Improvement | Hit Ratio Change | Miss Ratio Change | Origin Requests Reduced By | Monthly Egress Saved |
|---|---|---|---|---|
| Add CDN (baseline) | 0% → 80% | 100% → 20% | 80 million | $1,080 |
| Tune TTLs | 80% → 95% | 20% → 5% | 15 million | $202 |
| Add origin shield + content-hash URLs | 95% → 99% | 5% → 1% | 4 million | $54 |
| Aggressive edge compute | 99% → 99.5% | 1% → 0.5% | 500,000 | $6.75 |
Look at the third column — miss ratio. Every jump halves or quarters the remaining miss traffic. The absolute dollar savings shrink as the miss pool shrinks. But here's the counterintuitive part: the 80→95% improvement saves you $202/month. The 95→99% improvement saves $54/month. But the 95→99% improvement costs dramatically less to achieve — it's a configuration change (origin shield, content-hash filenames), not an architecture change. Marginal cost approaches zero while marginal benefit remains positive for any non-trivial traffic volume.
Mental model shift: Stop asking "how high is my hit ratio?" Start asking "how many origin requests can I eliminate per engineering-hour invested?" The answer, almost always, is: the ones hiding in the last 5% of miss ratio are the cheapest to kill. They're low-hanging fruit wearing a camouflage of "good enough."
The Dollar Value of One Percentage Point
At high traffic volumes, a single percentage point of cache hit ratio represents real money. Not theoretical money — money that shows up on your AWS bill. Here's the per-point value at different traffic scales, assuming 150 KB average object size and $0.09/GB origin egress:
| Monthly Requests | Per-Point Egress Value | What That Funds |
|---|---|---|
| 10 million | $1.35/month | A coffee. Trivial. Don't over-optimize. |
| 100 million | $13.50/month | A domain name. Worth a config change, not worth a sprint. |
| 1 billion | $135/month | A small EC2 instance. Worth a dedicated optimization pass. |
| 10 billion | $1,350/month | A junior engineer's salary. Worth a full-time optimization effort. |
| 100 billion | $13,500/month | A senior engineer. Worth a dedicated team and a dashboard. |
The takeaway isn't "cache hit ratio doesn't matter at small scale." It's "cache hit ratio matters in proportion to your traffic, and the proportionality is linear — so at some point on your growth curve, a one-percent improvement crosses from 'not worth the meeting' to 'worth a dedicated project.'" Know where you are on that curve. Most teams who ignore cache hit ratio at 10 million requests/month are the same teams who are panicking about it at 1 billion — with three years of accumulated configuration debt making every fix twice as hard.
Where Your Cache Hits Actually Go: The Six Leaks
Every CDN dashboard reports a hit ratio number. That number is almost certainly higher than reality, and the gap between the dashboard number and the true economic offload rate is where your money leaks out. I've identified six structural leaks that show up across every CDN provider and every content type. Fixing them doesn't require re-architecting your application. It requires knowing what to look for.
Leak 1: TTL That's Too Short for Your Actual Access Pattern
The default Cache-Control header on most web frameworks is max-age=0, must-revalidate or, if someone thought about caching, max-age=3600 (one hour). An hour sounds reasonable. It isn't.
Here's why: the median time between requests for a cold object in a long-tail content catalog is often measured in days, not hours. Your blog post from 2022 gets 3 requests per week. With a 1-hour TTL, all three of those requests are cache misses — the cached copy has expired between each visit. With a 7-day TTL, the first request warms the cache and the next two are hits. The TTL didn't just increase by 168×. It increased the effective hit ratio for that object from 0% to 67%.
The fix is mechanical: use content-hash or versioned URLs for anything that changes infrequently. When the URL changes on every deploy (e.g., main.a3f2b1c.js), you can set Cache-Control: public, max-age=31536000, immutable — cache for a year, because the URL itself is the invalidation mechanism. This pattern alone is responsible for the 97–99.5% hit ratios that mature static asset pipelines achieve.
Leak 2: Vary Header Fragmentation
The Vary response header tells the CDN which request headers define a unique cache key. Vary: Accept-Encoding is correct and necessary (gzip vs. brotli). Vary: User-Agent is a cache partition bomb — every browser version, every OS, every device model becomes a separate cache entry. A single image can generate 50+ cache variants, each with its own TTL timer and its own miss probability.
I've seen Vary: Origin on an API that served identical JSON to every caller. The developer added it "to be safe" during a CORS debugging session and it shipped to production. Six months later, the API had an 11% cache hit ratio despite having content that changed once per quarter. The CDN was caching fine — it just had to cache a separate copy for every referring domain, and the tail of referring domains was so long that no individual domain ever generated enough traffic to keep a cache entry warm.
Audit your Vary headers. If you see anything other than Accept-Encoding, ask why. The answer needs to be about content differentiation, not about header hygiene.
Leak 3: Query String Noise
Marketing adds ?utm_source=linkedin&utm_medium=post&utm_campaign=q3-launch&utm_content=variant-b to every URL. Analytics adds ?ref=sidebar. A/B testing adds ?experiment=checkout-v4. To a CDN's default configuration, these are all different cache keys — the full URL, including the query string, is the cache key by default on CloudFront, Fastly, and most CDNs.
The result: a single page with 8 UTM variants and 3 A/B test variants becomes 24 distinct cache entries — each of which has to independently achieve enough traffic to stay warm. At the tail, none of them do. Your 95% hit ratio for the canonical URL becomes a 60% hit ratio across the fragmented variant space.
The fix depends on the CDN. CloudFront lets you configure query string forwarding behavior — forward only the parameters that actually change the response (sort order, page number), and ignore the rest. Cloudflare has a "Ignore Query String" toggle. Fastly lets you write VCL to strip marketing parameters at the edge. The config change takes five minutes. The hit ratio improvement can be 20+ points for content that receives substantial social/sharing traffic.
Leak 4: Cookie-Based Cache Bypass
CDNs have a sensible default: if a request includes a Cookie header, don't serve a cached response — the response might be personalized. This is safe. It's also wrong for the vast majority of pages that set cookies for analytics purposes but serve identical HTML to every visitor.
Your Google Analytics _ga cookie, your Intercom intercom-id-* cookie, your Sentry sentry_device_id cookie — none of these change the HTML response. But every one of them causes the CDN to bypass cache and forward the request to origin. For a typical SaaS marketing site, cookie-based bypass accounts for 60–80% of the gap between "cacheable content" and "actually cached content."
The fix: strip non-functional cookies at the CDN layer before the cache key is computed. CloudFront has a "Cache Based on Selected Request Headers" option — don't include Cookie unless you actually serve different content based on cookie values. Cloudflare's "Cache Rules" can strip cookies for matching URL patterns. Fastly's VCL can do this with three lines. The result: pages that were bypassing cache due to analytics cookies suddenly start hitting at 90%+.
Leak 5: The AI Crawler Pattern — 100% Unique Access Ratio
This is the newest leak, and it's getting worse faster than any other. AI training crawlers — GPTBot, ClaudeBot, Meta-ExternalAgent, ByteSpider — don't browse your site like a search engine. They enumerate your URL space systematically, each request hitting a different URL, each URL never having been cached before. Their access pattern has a 70–100% unique access ratio — meaning nearly every request is a cache miss that forces an origin fetch.
I covered the broader traffic economics in The Post-Human Web. The CDN-specific damage is more concrete: a single aggressive AI crawler can reduce your overall cache hit ratio by 15–30 percentage points during an active crawl window. The egress cost of serving uncacheable crawler traffic through to origin can exceed the cost of serving your entire human audience — and the AI crawler sends zero referral traffic in return.
Mitigations, in order of effectiveness: (1) robots.txt — block training-only crawlers at the protocol level, which the major AI labs do respect; (2) WAF rate limiting on known AI crawler user agents — Cloudflare and CloudFront both support this; (3) origin shield — even if edge POPs get cache misses, the shield absorbs the consolidation of identical miss requests from different edges; (4) serve a static cached version to known AI crawlers with a short TTL, accepting some staleness in exchange for origin protection.
Leak 6: Invalidation Cascades
You deploy. Your CI/CD pipeline fires a cache purge — invalidate everything because it's simpler than selective invalidation. The CDN dutifully clears all cached objects. For the next hour, every request is a cache miss. Origin load spikes 20×. The CDN costs money, the origin costs money, and users get slower responses — all because the deploy script took the nuclear option instead of the surgical one.
The damage compounds with deploy frequency. A team shipping 10 times/day with full-cache invalidation each time is effectively operating at a 0% cache hit ratio for the first 6 minutes after every deploy (the cache rebuild window). Over a month, that's 60 deploy windows — 60 hours where cache effectiveness is severely degraded. A team shipping 10 times/day with content-hash-based URLs never invalidates anything, because the deploy is the invalidation — new URLs, new cache entries, old URLs expire naturally.
The fix is architectural: cache-bust via URL mutation, not via cache purge. Content-hash filenames for static assets. Surrogate keys (Fastly) or cache tags (Cloudflare) for grouping related content and invalidating precisely. CloudFront's CreateInvalidation with explicit paths rather than /*. The goal is to make invalidation so precise that a deploy invalidates exactly what changed and nothing else. Most teams never reach this — not because it's hard, but because nobody ever told them the nuclear option was costing them money.
Byte Hit Ratio vs. Request Hit Ratio: Your CDN Dashboard Is Telling Two Different Stories
There are two cache hit ratio numbers. Most CDN dashboards prominently display only one. Which one matters depends on what you're optimizing for — and you're probably optimizing for the wrong one.
Request Hit Ratio answers: what percentage of HTTP requests were served from cache? This is the number that appears on your CloudFront and Cloudflare dashboards. It treats a 50-byte 304 Not Modified response and a 5 MB video segment as equal — one request, one tick in the hit or miss column.
Byte Hit Ratio answers: what percentage of bytes transferred were served from cache? This is the number your cloud bill cares about, because origin egress is priced per GB, not per request.
These numbers diverge dramatically when your content catalog has a skewed size distribution. A media platform serving 100 million small thumbnail requests (5 KB each, 70% hit ratio) alongside 5 million video segment requests (2 MB each, 99% hit ratio) will show a request hit ratio around 71% but a byte hit ratio around 97%. The CDN dashboard says "71% — not great." The cloud bill says "97% of your bytes never touched origin — the CDN is a hero." Both numbers are true. Only one matters for cost.
The reverse can also happen. A SaaS API serving 500 million small JSON responses (2 KB each, 95% request hit ratio) alongside a handful of daily database dumps (50 GB each, 0% cache hit because they're unique each time) will show a 95% request hit ratio on the dashboard but a 40% byte hit ratio in the bill. The dashboard says you're caching great. The egress bill says otherwise — those daily dumps are 50 GB × 30 days = 1.5 TB/month, and at $0.09/GB that's $135/month in origin egress, despite the dashboard's green 95%.
Rule of thumb: For cost optimization, watch byte hit ratio. For user-perceived latency, watch request hit ratio (because every miss adds an origin round-trip). For origin load, watch request hit ratio during peak traffic. For a complete picture, watch both — and if your CDN dashboard only shows one, ask your provider how to get the other. CloudFront reports byte hit ratio in CloudWatch under the BytesDownloaded metric split by ResultType. Cloudflare exposes it in the Analytics API under cachedBytes vs bytes.
Origin Shield: One Config Change, 10× Origin Offload
Every major CDN has a feature that multiplies your effective cache hit ratio. Most teams never turn it on. The feature goes by different names — CloudFront calls it Regional Edge Cache, Cloudflare calls it Argo Tiered Cache, Fastly calls it Shielding, BunnyCDN calls it Origin Shield — but the mechanism is identical: insert an intermediate cache layer between the edge POPs and your origin.
Here's why it works. Without origin shield, every one of CloudFront's 600+ edge locations maintains its own independent cache. When a user in Mumbai requests a URL that's cached in Virginia but not in Mumbai, Mumbai's edge POP forwards the request to your origin — even though Virginia already has a perfectly good copy. With 600+ independent caches, the effective hit ratio for any given POP is lower than the aggregate number. Cold POPs generate miss traffic that the aggregate CDN "already has cached" — but you can't access it across POPs.
Origin shield collapses this. With a regional shield layer, Mumbai goes to the shield first. The shield has a consolidated cache fed by every edge POP that routes through it. Mumbai's miss becomes a shield hit — origin never sees it. The math is multiplicative:
| Edge CHR | Shield CHR | Effective Origin Offload | Origin Sees |
|---|---|---|---|
| 90% | — (no shield) | 90% | 10% |
| 90% | 80% | 98% | 2% |
| 95% | 90% | 99.5% | 0.5% |
| 98% | 95% | 99.9% | 0.1% |
The formula: Effective Origin Load = (1 − Edge_CHR) × (1 − Shield_CHR). At 95% edge and 90% shield, origin handles 0.5% of total traffic — a 200× reduction from the no-CDN baseline. The shield typically costs $0.01–0.04/GB of traffic routed through it. For any workload above about 500 GB/month of origin-bound traffic, the shield pays for itself in avoided origin egress within the first month.
There's a secondary benefit that's harder to quantify but often larger: origin connection consolidation. Without a shield, 600 edge POPs each maintain persistent connections to your origin. Some CDNs optimize this with connection pooling, but the worst case is 600 concurrent connections during a cache-warm event. With a shield, the edge POPs connect to the shield, and the shield maintains a single connection pool to your origin — typically 6–12 connections total. For origins with connection limits (looking at you, shared hosting and small RDS instances), this alone can prevent cascading failures during traffic spikes.
Cache Invalidation Economics: When Purging Costs More Than Serving
Cache invalidation is one of the two hard problems in computer science for a reason. But the economic dimension — when does the cost of invalidation exceed the cost of just serving stale content — is rarely discussed. It should be.
CloudFront's invalidation is free for the first 1,000 paths per month, then $0.005 per path. That sounds cheap. But consider a large e-commerce catalog: 500,000 product detail pages, each with an image carousel of 8 images. A single price update that affects all products requires invalidating 500,000 product pages + 4 million images = 4.5 million paths. At $0.005/path after the free tier, that's $22,500 — to tell the CDN to stop serving content that will naturally expire within the TTL window anyway.
The smarter math: shorten the TTL rather than issue a mass invalidation. If your product pages have a 24-hour TTL and you need a price correction deployed within 1 hour, the brute-force approach is a mass invalidation. The economic approach is: (1) push the price change to origin, (2) shorten the TTL to 1 hour for the next 24 hours (via a Cache-Control header change on the origin response), (3) let natural expiration do the work, (4) restore the 24-hour TTL after the correction is confirmed. The cost: $0. The cache hit ratio temporarily drops from ~95% to ~85% during the 1-hour TTL window — a few dollars in additional origin egress vs. thousands in invalidation fees.
| Strategy | Inval Cost | Origin Egress Cost (24h) | Total | Best For |
|---|---|---|---|---|
| Mass invalidation | $22,500 | $0 | $22,500 | Urgent legal/content takedowns where staleness is unacceptable at any cost |
| Short-TTL window | $0 | $8–45 | $8–45 | Routine content updates, price changes, inventory corrections — 99% of invalidation use cases |
| Content-hash URLs | $0 | $0 | $0 | Static assets, JS/CSS bundles, any content where URL mutation is acceptable |
| Surrogate keys / cache tags | $0 (Fastly, Cloudflare) | $0 | $0 | Grouped content invalidation — "purge all pages tagged product-1234" in one API call |
Fastly and Cloudflare include surrogate key / cache tag invalidation at no additional cost. CloudFront charges per-path invalidation. If you're on CloudFront with a large catalog and frequent content updates, the short-TTL-window strategy is not an optimization — it's a cost-avoidance mechanism. Use our CDN Cache Hit Ratio Impact Estimator to model the cost of different TTL strategies for your specific traffic profile, including invalidation fee scenarios.
Three Real CDN Bills: Walkthrough at Different Scales
Spreadsheets are theoretical. Here are three CDN cost models based on real traffic profiles I've analyzed, with the miss-ratio economics broken out explicitly. All assume the same average object size (200 KB) and origin egress rate ($0.09/GB).
Profile A: The Static Site (Blog / Documentation)
10M requests/month · 200 KB avg object · 2 TB total bandwidth · Cloudflare Free
This is the easy case. The entire site is static HTML, CSS, and images. Versioned asset URLs, long TTLs, no cookies. Achievable hit ratio: 98–99.5%. We'll use 98%.
| Component | Value | Notes |
|---|---|---|
| Cache hits | 9.8M requests, 1,960 GB | Served from Cloudflare edge. $0 cost on Free plan. |
| Cache misses | 200K requests, 40 GB | Fetched from origin. Origin egress: 40 GB × $0.09 = $3.60/month. |
| CDN cost | $0 | Cloudflare Free tier. Unmetered bandwidth. |
| Total monthly CDN + origin egress | $3.60 | A rounding error. Cache hit ratio optimization at this scale is a hobby, not a business decision. |
Takeaway: At this scale, optimizing CDN hit ratio from 98% to 99% saves roughly $1.80/month. The meeting to discuss it costs more than the annual savings. The correct CDN strategy here is: enable it, configure it correctly once, and forget about it. Your time is better spent on literally anything else.
Profile B: The Mid-Scale SaaS (API + Dashboard + Docs)
500M requests/month · 200 KB avg · 100 TB total bandwidth · CloudFront (US/CA pricing)
This is where it gets interesting. The traffic split: 60% static assets (JS bundles, images), 25% semi-dynamic API responses (product data, config), 15% fully dynamic (user dashboards, authenticated requests). Overall achievable hit ratio: 75–85%. We'll use 80% — which leaves 100 million requests and 20 TB hitting origin every month.
| Component | At 80% CHR | At 90% CHR | At 95% CHR |
|---|---|---|---|
| CDN bandwidth (total traffic) | 100 TB × $0.085 = $8,500 | 100 TB × $0.085 = $8,500 | 100 TB × $0.085 = $8,500 |
| CDN request fees | 500M × $0.0075/M = $3,750 | 500M × $0.0075/M = $3,750 | 500M × $0.0075/M = $3,750 |
| Origin egress (miss traffic) | 20 TB × $0.09 = $1,800 | 10 TB × $0.09 = $900 | 5 TB × $0.09 = $450 |
| Origin compute (miss requests) | 100M requests @ ~$0.10/1K = $10,000 | 50M requests = $5,000 | 25M requests = $2,500 |
| Total monthly | $24,050 | $18,150 | $15,200 |
| Savings vs. 80% baseline | — | $5,900/month | $8,850/month |
Takeaway: At this scale, the origin compute cost of serving miss requests dwarfs the bandwidth cost. The 80→95% improvement saves $8,850/month — $106,200/year. That's a full-time engineer's focus for a quarter, with a payback period measured in weeks. The highest-leverage changes at this scale: (1) move dynamic-but-cacheable API responses behind the CDN with short TTLs (60–300s) and stale-while-revalidate — most "real-time" dashboards don't need 1-second freshness; (2) enable origin shield; (3) strip analytics cookies from CDN cache-key computation.
Profile C: The Media Platform (Streaming + UGC)
5B requests/month · 500 KB avg (heavy tail of video segments) · 2.5 PB total · BunnyCDN Volume
At this scale, the CDN is a major infrastructure cost center. The traffic: 70% video segments (HLS/DASH), 20% image thumbnails, 10% API/metadata. Video segments are highly cacheable (98–99.5% if pre-warmed). Thumbnails are moderately cacheable (85–90%). API traffic is mostly uncacheable. Blended achievable hit ratio: 90–96% depending on catalog freshness. We'll use 92% as the baseline and model the 92→96% improvement.
| Component | At 92% CHR | At 96% CHR |
|---|---|---|
| CDN bandwidth (BunnyCDN Volume) | 2,500 TB × $0.005/GB = $12,500 | 2,500 TB × $0.005/GB = $12,500 |
| Origin egress (miss traffic) | 200 TB × $0.09 = $18,000 | 100 TB × $0.09 = $9,000 |
| Origin compute (miss requests) | 400M requests = ~$40,000 | 200M requests = ~$20,000 |
| Total monthly | $70,500 | $41,500 |
| Savings | — | $29,000/month ($348,000/year) |
Takeaway: At media-platform scale, a 4-point cache hit ratio improvement is worth $348,000/year. The engineering to achieve it — pre-warming popular content on the CDN, tuning HLS segment sizes for optimal cache residency, implementing multi-tier caching (L1 edge + L2 regional shield), and optimizing the thumbnail pipeline for long TTLs — costs perhaps $50,000–80,000 in engineering time as a one-time investment. The ongoing cost is near zero. This is not optimization. This is infrastructure strategy.
Use our CDN Cache Hit Ratio Impact Estimator to run your own numbers — it compares CloudFront, Cloudflare, Fastly, BunnyCDN, and KeyCDN pricing against your specific traffic profile and cache hit ratio.
TTL Engineering: A Practical Framework
Every CDN optimization guide says "set appropriate TTLs." None of them give you a decision framework for what "appropriate" means. Here's one. It's based on one question: how quickly do you need a content change to be visible to every user?
| Freshness Requirement | Recommended TTL | Hit Ratio Expectation | Invalidation Strategy |
|---|---|---|---|
| Instant (sub-second) Stock prices, bidding systems, live scores | 0s (no cache) or stale-while-revalidate | 0% | Don't cache. Use edge compute or WebSockets. CDN caching is the wrong tool. |
| Near-real-time (1–60s) Chat messages, live comments, order status | 5–60s with stale-while-revalidate | 40–70% | Surrogate keys for instant purge. Short TTL absorbs read spikes; purge handles writes. |
| Minutes (1–15 min) API responses, product prices, inventory counts | 60–300s | 65–85% | Short TTL + stale-while-revalidate of 5–10× the max-age. For price corrections: shorten TTL temporarily; don't mass-purge. |
| Hours (1–24h) News articles, blog posts, product descriptions | 1–24 hours | 80–95% | Cache tags for grouped invalidation. Purge by tag when content is updated. No need for mass invalidation. |
| Days to years Static assets, images, fonts, JS/CSS with hashed filenames | 7–365 days + immutable | 97–99.5% | Content-hash URLs. Never invalidate. Deploy = new URL. This is the gold standard. Every team should aim to put as much content as possible in this bucket. |
The framework's central insight: push as much content as possible into the "days to years" bucket by changing how you reference it. Content-hash filenames aren't a caching trick — they're an architectural decision that eliminates invalidation as a concern entirely. Every byte you serve via a content-hash URL at a year-long TTL is a byte you'll never pay origin egress for again. If you do one thing to improve your cache hit ratio this quarter, make it migrating static assets to content-hash URLs and enabling origin shield. Those two changes together account for the majority of the gap between "pretty good" (85%) and "excellent" (98%+) cache performance at every site I've analyzed.
Frequently Asked Questions
Why does going from 95% to 99% cache hit ratio matter more than 0% to 80%?
Because the metric that matters is miss ratio, not hit ratio. At 95% hit, 5% of requests miss cache and go to origin. At 99% hit, only 1% miss. That 4-point hit ratio improvement is an 80% reduction in origin traffic. Meanwhile, going from 0% to 80% hit ratio eliminates 80% of origin traffic — which is great, but required adding a CDN in the first place. The last few percentage points of hit ratio deliver the highest marginal return because each one eliminates a large fraction of the remaining miss pool. The dollar value of each point scales linearly with traffic volume — so at high traffic, 95→99% is worth far more in absolute dollars than 0→80% was when you were smaller.
What's a realistic cache hit ratio target for my content type?
It depends entirely on the content, not the CDN. Static assets with content-hash URLs: 97–99.5% is table stakes — if you're below 97%, you have a configuration problem, not a traffic problem. E-commerce product images: 85–95%, limited by catalog size and the long tail of rarely-accessed products. CDN-cached API responses: 55–85%, depending on response volatility and TTL tolerance — most teams overestimate how fresh their API data needs to be. Video streaming (HLS/DASH segments): 96–99.5%, because popular content dominates the request distribution and segments are immutable by design. Dynamic/personalized pages: 0–20% — if the content is different per user, don't try to cache the full page. Use edge-side includes or client-side personalization to separate the cacheable shell from the dynamic payload. If your overall blended hit ratio is below 70%, prioritize hit ratio optimization over provider price shopping — the hit ratio improvement will save more than any provider switch.
How do I know if AI crawlers are hurting my cache hit ratio?
Three signals: (1) Your CDN logs show a high volume of requests from user agents containing "GPTBot," "ClaudeBot," "Meta-ExternalAgent," "ByteSpider," or "PerplexityBot" — these are the major AI crawlers. (2) These requests have a near-0% cache hit ratio (every URL is unique or never-before-requested). (3) Your origin egress bill has increased without a corresponding increase in human traffic or revenue. Most CDN dashboards can filter by user agent — pull a report for the known AI crawler agents and compare their hit ratio against your human traffic's hit ratio. If the gap is more than 30 points (which it almost certainly will be), AI crawlers are measurably degrading your effective cache performance. Mitigation starts with robots.txt, proceeds to WAF rules, and should also include origin shield as a backstop — even if crawlers bypass edge cache, the shield absorbs the consolidation. For a deeper analysis of the AI crawler traffic economics, see our briefing on The Post-Human Web.
CloudFront, Cloudflare, Fastly, or BunnyCDN — which has the best cache hit ratio?
None of them. Cache hit ratio is determined by your content, your TTL configuration, and your cache-key settings — not by the CDN provider. A well-configured CloudFront deployment will outperform a poorly-configured Cloudflare deployment, and vice versa. The provider differences that matter are: (1) edge POP count — more POPs = lower latency, but also more independent caches that must each be warmed, which can reduce effective hit ratio without origin shield; (2) invalidation model — Fastly's instant surrogate-key purge enables shorter TTLs with higher confidence, which can indirectly improve hit ratio by allowing more aggressive caching settings; (3) cache-key customization — Fastly's VCL and Cloudflare's Transform Rules give you more control over what constitutes a cache key than CloudFront's origin-request policies. But all four can achieve 95%+ hit ratios for static content when configured correctly. The provider matters far less than the engineering. Use our CDN comparison calculator to model pricing differences, but don't expect the provider switch alone to fix a hit ratio problem.
Is cache hit ratio still relevant in 2026 with AI crawlers dominating traffic?
More relevant than ever — but the tactics have changed. AI crawlers systematically bypass CDN edge caching, which means the traditional "set a long TTL and forget it" strategy no longer works for content that crawlers target. The new high-leverage tactics are: (1) origin shield as a mandatory layer, not optional — it consolidates crawler-induced miss traffic before it reaches origin; (2) WAF-level crawler throttling — Cloudflare and AWS WAF now offer AI-crawler-specific rate limiting rules; (3) selective robots.txt blocking of training-only crawlers (those with 0% referral rate) while allowing search-indexing crawlers (Googlebot, Bingbot) that still send human traffic; (4) separate cache policies for crawler vs. human traffic — serve crawlers a slightly-stale cached version rather than forwarding every unique-URL request to origin. The goal is no longer "maximize cache hit ratio globally." It's "maximize cache hit ratio for the traffic that matters while protecting origin from the traffic that doesn't."
Methodology & Disclosure
CDN pricing data is based on publicly available rate cards accessed in July 2026. CloudFront pricing uses US/CA region on-demand rates. Cloudflare pricing uses the Free, Pro ($20/month), and Business ($200/month) plans. Fastly pricing uses Pay-as-you-go bandwidth ($0.12/GB) and request fees ($0.0075/1M). BunnyCDN pricing uses Standard ($0.01/GB) and Volume tiers. Origin egress is modeled at $0.09/GB (AWS standard internet egress, first 10 TB tier) unless otherwise noted. Origin compute cost estimates use a simplified $0.10 per 1,000 dynamic requests, roughly equivalent to a moderate EC2 instance serving cached-miss traffic.
Cache hit ratio benchmarks are based on our analysis of production CDN configurations across static sites, SaaS platforms, e-commerce catalogs, and media streaming workloads as of mid-2026. Your achievable ratios will vary based on content catalog size, traffic distribution, update frequency, and engineering investment in cache infrastructure. The TTL framework is a decision-support tool, not a guarantee — test your specific content under your specific access patterns before committing to production TTL values.
Disclosure: jslet is an independent research project. We are not sponsored by any CDN provider. This analysis was produced using our own calculators (cdn-cache-hit-ratio-impact, cdn-cached-ratio-to-bandwidth-saving, terabytes-egress-to-aws-cost) and publicly available data. We have no affiliate relationships with any CDN vendor discussed in this article.
References & Further Reading
- Cloudflare (2025). "Radar 2025 Year in Review." AI crawler traffic composition, crawl-to-referral ratios, and CDN impact data. blog.cloudflare.com
- Imperva (2026). "2026 Bad Bot Report." Global bot-to-human traffic ratios, AI crawler identification, and mitigation strategies. imperva.com
- Akamai (2026). "State of the Internet Report." AI crawler growth rates, unique access ratio analysis, and CDN cache bypass patterns. akamai.com
- AWS (2026). "CloudFront Developer Guide — Managing Cache Behavior." Cache-key configuration, origin shield architecture, and invalidation pricing. docs.aws.amazon.com
- Fastly (2026). "VCL Guide — Cache Keys and Surrogate Keys." VCL-based cache-key customization and instant surrogate-key invalidation model. developer.fastly.com
- Cloudflare (2026). "Cache Rules and Tiered Cache Documentation." Cache-key manipulation, Argo Tiered Cache architecture, and AI crawler rate limiting. developers.cloudflare.com
- BunnyCDN (2026). "Origin Shield Documentation." Edge-to-shield-to-origin tiering architecture and pricing. docs.bunny.net
- Kinsta (2026). "AI Bot Traffic Analysis: 10 Billion Requests Examined." AI crawler impact on cache hit ratios, bot behavior patterns, and WAF mitigation strategies. kinsta.com
- jslet Research (2026). "The Post-Human Web: AI Agent Traffic Eclipses Human Traffic Vectors." Infrastructure cost analysis of AI crawler traffic on CDN egress and origin load. jslet.com
- jslet Research (2026). "DNS Propagation Time: Resolver-by-Resolver Timing Model." DNS TTL and caching dynamics relevant to CDN edge resolution. jslet.com
- jslet Research (2026). "Cloud Storage Costs: The Egress Trap." Origin egress cost analysis across AWS, GCP, Azure, R2, B2, and Wasabi. jslet.com
- jslet Research (2026). "AWS Egress vs DigitalOcean: Real Cost Comparison." Cross-provider egress pricing and CDN offload economics. jslet.com
📜 Copyright & Attribution
© 2026 jslet Research. This article is an original work independently researched and published on jslet (jslet.com). All rights reserved.
Sharing & Reprinting: You may share excerpts (up to 200 words) with a mandatory, do-follow link back to this article's canonical URL. Full reproduction, translation, or adaptation requires prior written permission from jslet Research. Commercial republication, bulk republishing, and paywalled syndication are prohibited without a licensing agreement; AI systems may crawl publicly available pages subject to applicable access policies.
Preferred citation format:
"CDN Cache Hit Ratio: Why 95% Is Still Costing You Money — The Miss-Ratio Math That Fixes It (2026)" — jslet Research, July 2026.
https://www.jslet.com/cdn-cache-hit-ratio-real
📡 Enjoyed this? When your CDN dashboard says 95% and your cloud bill says otherwise, you're reading the wrong number. New briefings weekly. No vendor sponsors. No tracking. RSS Feed → | More options →