Cloudflare reduces your bandwidth in two separate ways: it shrinks the data your origin server sends (origin offload) and it cuts the egress fees you pay your host (via caching and the Bandwidth Alliance). The core mechanics are edge caching, request coalescing, and on-the-fly compression. But here’s the catch—your Cloudflare dashboard only shows a fraction of those savings because it measures cache hits against an estimated origin transfer, ignoring compression and tiered cache synergies. In this guide I’ll break down the exact byte-by-byte flow, show a real sample blog calculation, and explain why the free tier isn’t a magic trick.
The Origin-to-Edge Flow: Where Bytes Actually Get Saved
When a user in Sydney requests your page, the DNS response points them to the nearest Cloudflare point of presence (PoP). That edge node checks its cache. If the asset is stale or missing, it does not immediately hammer your origin.
Instead, Cloudflare uses a technique called request coalescing (sometimes called single-flight). The first request triggers an origin fetch; simultaneous duplicates wait for that single response. I learned this the hard way in 2018 when a flash traffic spike on a news site looked like it would melt our origin—instead, origin logs showed only 40 concurrent connections for 9,000 edge requests.
If the response is cacheable, the edge stores it with the returned TTL. Subsequent requests are served from the PoP. The bytes never travel from your origin, and they may not even travel from the parent cache tier if tiered caching is on.
The thing nobody tells you about this flow: misconfigured Cache-Control headers can silently disable it. I once audited a Laravel API that sent private, no-store on static JSON; Cloudflare obeyed, and bandwidth savings dropped to near zero despite “orange-cloud” being active.
Consider the TCP and TLS overhead. Even a cache miss carries less weight than you think because Cloudflare terminates TLS at the edge. Your origin sees one shared connection reused across many visitors, not thousands of individual handshakes. That connection multiplexing is a hidden bandwidth saver: fewer TLS sessions means fewer duplicated certificate exchanges and reduced protocol overhead.
In practice, I map the flow for clients using a whiteboard: user → edge PoP → (cache hit) serve; or → (miss) coalesce → parent tier → origin. The parent tier step is where tiered caching quietly cuts cross-continent backhaul. According to Cloudflare’s developer docs, enabling Tiered Cache can reduce origin requests by up to 60% beyond standard edge caching alone.
When I first tried to load-test a client’s site with Loader.io, I noticed the origin CPU stayed flat while edge served 5,000 requests per second. That’s the moment the flow clicked: Cloudflare isn’t just a cache; it’s a request funnel.
Three Distinct Mechanisms of Bandwidth Savings
1. Edge Caching and Cache Hit Ratio
The most obvious lever is serving static assets from 300+ locations. But cache hit ratio (CHR) is not a vanity metric—it directly determines origin offload. A blog with 90% CHR on images and CSS saves 90% of those bytes at origin. The mistake I see: people cache HTML for zero seconds because they fear stale content, then wonder why savings are low.
2. Request Coalescing (Single-Flight)
When 500 users hit a new article simultaneously, Cloudflare sends perhaps one request to origin. This is request coalescing. It saves origin bandwidth and CPU. Trade-off: the unlucky first user waits for origin; if origin is slow, edge may even timeout. I’ve seen coalescing backfire when a 10-second origin response caused a pile-up of 2,000 queued requests at the edge—still better than 2,000 origin hits, but latency suffered.
3. Edge Compression and Payload Minimization
Cloudflare applies Brotli or Gzip at the edge if the client supports it. The bytes leaving your origin might be uncompressed, but the bytes delivered to users are shrunk. This doesn’t reduce origin bandwidth unless you also disable origin compression, but it slashes the egress bandwidth your users consume—important for mobile. For image-heavy sites, enabling Polish or Image Resizing can cut megabytes per page. If you want to quantify image-specific gains before enabling Polish, our Image Compression Savings Calculator gives a quick estimate.
| Mechanism | Where Savings Accrue | Typical Reduction | Best For |
|---|---|---|---|
| Edge Caching | Origin + egress | 50–95% of static bytes | CMS assets, JS, CSS |
| Request Coalescing | Origin only | Up to 99% on spikes | Flash crowds, new posts |
| Edge Compression | Egress only | 20–70% text, 30–80% images | HTML, JSON, photos |
| Tiered Caching | Origin + inter-PoP | Additional 30–60% origin cut | Global audiences |
This matrix is the mental model I use when auditing accounts. Most competitors lump all of this under “CDN caching,” which hides the fact that compression savings never show up as “bandwidth saved” in analytics.
Bandwidth Alliance: The Egress Discount That Isn’t Cache
The Bandwidth Alliance is a partnership where participating cloud providers (Backblaze B2, DigitalOcean, Vultr, and others) agree to waive or heavily discount egress fees for traffic routed through Cloudflare. This is separate from caching. Even if every request hits your origin, you could pay $0 egress to your host because the bytes travel over Cloudflare’s backbone and the host bills nothing for that exit.
I migrated a video platform from AWS S3 to Backblaze B2 specifically for this reason. Their egress was $0.01/GB normally; with Cloudflare in front, the bill line item for bandwidth vanished. However, the Alliance does not cover compute ingress or request counts. The thing nobody tells you: if your origin is not a participating provider, you still pay standard egress to them, and Cloudflare’s free tier does not magically reimburse you.
Realistic quantification: for a 1 TB/month egress site on a non-partner host, Cloudflare saves $0 in egress fees but still cuts origin load via caching. On a partner host, that same 1 TB could mean $10–$20 saved. Always check the current partner list before assuming savings. Backblaze’s own alliance page confirms that transfers to Cloudflare are free of egress charges.
Why Your Cloudflare Dashboard Lies About Savings
Open your analytics panel and you’ll see “Bandwidth Saved” as a neat blue number. That metric is calculated as (requests served from cache) × (average origin response size). It ignores three real savings sources: compression, request coalescing, and tiered cache hits that never touched origin but also never matched a “cache hit” in the simplistic model.
When I first tried to report ROI to a CFO, I used the dashboard figure of 120 GB saved and the actual origin log showed 210 GB reduction. The gap was Brotli compression on HTML and JSON. Cloudflare’s UI simply doesn’t attribute bytes shrunk at the edge to “savings” because it compares like-for-like cached vs uncached sizes, not wire bytes.
Most people don’t realize that enabling Brotli on a text-heavy site can double the dashboard’s reported savings if you instead measure at the network interface.
Another dashboard blind spot: the “Requests” chart shows cached vs uncached, but coalesced requests are counted as a single uncached request plus many “cached” hits only if the object is stored. During a thundering herd, you may see 1 uncached and 999 cached, which looks like 99.9% CHR—but the origin still only delivered one payload. That’s good, yet the dashboard’s bandwidth formula may underweight it because it assumes the cached responses would have been the same size as origin, ignoring that your origin might have sent uncompressed data.
The fix: export origin bandwidth from your server logs before and after. That’s the only ground truth. I now benchmark with vnstat on the origin and compare to Cloudflare’s “origin bandwidth” submetric, which is buried under Caching → Analytics → Cache Performance, not the top-line card. Free plans also sample analytics, so the dashboard number is an estimate, not a ledger.
Realistic Quantification: A Sample Blog Breakdown
Let’s model a real-world blog: 100,000 monthly page views, average HTML 80 KB, CSS/JS 200 KB, images 1.2 MB per page. Total per visit ≈ 1.48 MB. Without any CDN, origin egress = 148 GB/month.
- Static assets (images, CSS, JS) = 1.4 MB of that, dynamic HTML = 80 KB.
- Assume 85% of static requests are cacheable with 95% CHR after tuning.
- HTML is dynamically generated but coalesced; origin sends 80 KB per unique URL, not per visitor.
With Cloudflare free tier, default edge caching plus Brotli on HTML (saved ~60% on 80 KB → 32 KB wire) and images served from cache: origin bandwidth drops to roughly 28 GB (HTML coalesced to ~5 GB, static cache misses ~3 GB, image optimization overhead ~20 GB). That’s an 81% origin reduction. If the host is in the Bandwidth Alliance, egress bill goes near zero.
For a tailored projection, plug your numbers into our Cloudflare Bandwidth Savings Calculator. In my experience, small blogs underestimate static ratio; a photography blog with 3 MB images will see even higher percentages because images dominate and cache well.
Trade-off: if you use Cloudflare’s proxy for dynamic API calls, those bytes still go to origin. Don’t expect 90% savings on a single-page app that fetches fresh JSON every second. The sample above assumes mostly cacheable content. I once consulted for a weather API where only 2% of traffic was cacheable; Cloudflare saved them nothing on bandwidth, though it improved latency.
How Cloudflare Sustains Free Unlimited Bandwidth (The Economics)
The frequent question: “How can CloudFlare offer a free CDN with unlimited bandwidth?” The answer isn’t charity. Cloudflare operates one of the largest anycast networks, with massive peering agreements. They sell paid plans (Pro, Business, Enterprise) with margin, and they arbitrage bandwidth: transit is cheap at scale, especially with settlement-free peering. The free tier is customer acquisition and DDoS shield data.
As Cloudflare notes in its network overview, they have 300+ locations and direct interconnects with ISPs. This lets them deliver bytes at low marginal cost. The “unlimited” caveat is in the ToS: excessive abuse or non-HTML content (e.g., video streaming) may trigger plan limits. I’ve seen a free-tier user serving 50 TB of video get throttled; the dashboard didn’t warn until throughput dipped.
So the free model is sustainable because most free sites use modest bandwidth, and the heavy users either upgrade or get constrained. It’s not a loophole; it’s freemium done right. The economies of scale mean the cost per GB delivered across their backbone is fractions of a cent, which they monetize via security add-ons and enterprise contracts.
Advanced Edge Cases and Trade-offs
Not everything benefits. Here are four scenarios where savings shrink or vanish:
- Strictly dynamic, per-user responses: If every byte is unique (personalized dashboards), cache hit ratio is ~0%. Coalescing only helps for identical concurrent requests.
- Cookie-heavy sessions: Cloudflare ignores cache for requests with cookies unless you configure Cache Everything with origin override. I once debugged a Magento store where session cookies blocked 99% of caching.
- Large file downloads with range requests: Partial content can bypass cache tiers, causing repeated origin fetches for different byte ranges.
- TLS 1.3 0-RTT abuse: While great for latency, it can increase edge compute, not bandwidth, but misconfigured origin can send duplicate payloads.
Another trade-off: enabling maximum compression (Brotli level 11) at edge increases CPU time and may slightly raise latency. Cloudflare uses a balanced level; don’t assume “more compression = free speed” without testing TTFB. I benchmarked a client’s site where forcing highest compression added 15 ms to first byte—acceptable, but not free.
Also note: if you use Cloudflare Workers to transform responses, you may inadvertently disable caching because the worker fetches from origin each time unless you explicitly use the Cache API. That’s a silent bandwidth leak I’ve tripped over in serverless setups.
A Practical Checklist to Maximize Your Savings
Use this audit flow on any new Cloudflare zone:
- Set
Cache-Control: public, max-age=86400on static assets at origin; don’t rely on Page Rules alone. - Enable Tiered Cache and Argo (if budget allows) to cut inter-PoP trips.
- Turn on Brotli in Speed → Optimization; verify with
curl -I --accept-encoding br. - Create a Cache Rule to override cookies for static paths (e.g.,
/wp-content/*). - Check origin logs weekly; compare to Cloudflare “Origin Bandwidth” metric, not the top-line “Bandwidth Saved”.
Following this on a client’s WooCommerce site lifted CHR from 22% to 78% in two weeks, cutting their DigitalOcean egress from $40 to $9. The key was stripping cookies on static paths—a step the dashboard never suggests.
The Savings Allocation Framework (Mini Calculator)
I call this the Origin-Edge Savings Split. Write down your monthly origin egress without CDN (O). Then estimate:
- Static ratio (S) = bytes of static assets / total bytes.
- Cache hit target (C) = expected CHR on static (e.g., 0.9).
- Compression factor (F) = 1 – compression ratio (e.g., 0.6 for Brotli on text).
Origin savings ≈ O × [S × C + (1-S) × coalesce_factor]. Egress savings with Bandwidth Alliance = O × (1 – origin_savings_ratio) if partner, else just the cached portion’s egress. This framework forces you to separate the two levers. For a quick automated version, the Cloudflare Bandwidth Savings Calculator applies similar math with your traffic profile.
That’s the real story: Cloudflare bandwidth savings work through layered mechanisms, not a single switch. Understand each, measure at the origin, and you’ll know exactly why your dashboard whispers while your server sighs in relief.