How a Content Delivery Network Actually Works in 2026

A CDN — short for content delivery network — is a global mesh of servers that sits between your origin server and your users, caching responses close to wherever those users happen to be. When someone in Tokyo loads a page hosted in Frankfurt, the CDN serves the cached HTML, CSS, JS, images, and increasingly video and API responses from a Tokyo edge location rather than dragging every byte across the ocean. The result is lower latency, lower origin load, and a wider set of features — DDoS protection, image optimisation, edge functions, WAFs — that used to require separate products.

This guide walks through the mental model, how anycast and cache fill actually behave, the modern features CDNs bundle, and a 2026 comparison of Cloudflare, CloudFront, Fastly, Akamai, and Bunny.

Key takeaways

• A CDN has two parts — your origin (where the canonical content lives) and edge PoPs (points of presence, the cache servers near users). The CDN's job is to keep edges full and the origin idle.
• Modern CDNs route with anycast — one IP advertised from every PoP, with BGP delivering each user to the topologically nearest one. This replaced DNS-based geo-routing at the edge layer.
• A cache MISS on a cold edge triggers a fetch from origin (or a tiered cache shield), stores the response, and serves the next identical request as a HIT in single-digit milliseconds.
• The 2026 CDN bundle is much wider than asset caching: image and video optimisation, edge JavaScript / WebAssembly, R2/S3-style object storage at the edge, DDoS and WAF, bot management.
• The provider you pick depends on workload — Cloudflare for breadth and bundled pricing, CloudFront for AWS lock-in, Fastly for instant purge and Wasm runtimes, Akamai for enterprise scale, Bunny for raw bandwidth cost.

---

The mental model: origin plus edge PoPs

Every CDN starts from the same picture. You have one origin — a server, a cluster, an object store like S3 — that holds the canonical version of your content. You have many edge PoPs spread across the world, each containing cache storage and request-processing capacity. A PoP is just a small data centre rack, sometimes co-located in an internet exchange, sometimes a full facility. Cloudflare advertises 330+ cities, Fastly runs 100+ PoPs, Bunny operates 119 across its Standard Network, and Akamai sits on 4,200+ PoPs because it grew up by deploying into telco networks.

When a request reaches an edge PoP, three things can happen. The PoP has the response cached and fresh — it serves the user directly (a HIT). The PoP has nothing cached or the cached copy has expired — it fetches from the origin, stores the response, and serves it (a MISS, then populated). Or the PoP has an expired copy but is configured to revalidate — it asks the origin whether the cached copy is still good, gets a 304 Not Modified if so, and refreshes the TTL.

The whole game is to make the first case happen as often as possible. A high cache hit ratio means low origin egress costs, low origin CPU, and user-facing TTFB drops to whatever the PoP-to-user RTT is — typically under 30 ms for most populated regions.

---

Anycast routing — one IP, many servers

The classic question — "if there are 300 PoPs, how does my user end up on the right one?" — used to have a clumsy answer. Early CDN designs assigned a different IP to each region and used DNS to direct each user to the nearest one (GeoDNS). That worked, but DNS-based routing has structural flaws: it routes based on the resolver's location, not the user's, so a Spanish user behind a corporate DNS resolver in Texas would get sent to the Texas PoP.

Modern CDNs route with anycast. The CDN announces the same IP address from every PoP via BGP (Border Gateway Protocol). Each router along the way picks the BGP path with the lowest cost, and the packet ends up at whichever PoP is topologically closest from the user's actual position on the internet. The DNS lookup returns the same IP everywhere — the routing happens at the IP layer.

Anycast brings three concrete wins. Geographic accuracy goes up because routing happens on actual network topology rather than resolver location. Failover is near-instantaneous — if a PoP goes down, BGP withdraws the route and traffic re-converges on the next-closest PoP within seconds, without waiting for DNS TTLs. And DDoS becomes structurally harder, because an attack against a single IP gets spread across hundreds of PoPs instead of hammering one.

DNS-based load balancing hasn't disappeared — it still does useful work for origin routing (sending API calls to the right regional backend, enforcing data residency) and active-passive disaster recovery. The 2026 architecture is hybrid: anycast at the edge, DNS-based decisions at the origin, GeoDNS layered on top for compliance.

---

The cache fill flow, MISS to HIT

Here's what happens end to end the first time a piece of content is requested through a CDN.

GET /assets/hero.jpg HTTP/1.1
Host: example.com

1. The browser resolves example.com via DNS and gets the CDN's anycast IP.
2. The packet leaves the user's network. BGP routes it to the nearest PoP — say, Frankfurt.
3. Frankfurt's edge cache looks up the cache key (typically a hash of the URL plus a subset of headers).
4. Cache MISS. Frankfurt opens a connection to the origin, fetches hero.jpg, and reads Cache-Control: public, max-age=86400.
5. Frankfurt stores the response, tags it with a 24-hour TTL, and sends it to the user.
6. The next user in Frankfurt requests the same URL — HIT — served from the edge cache in single-digit ms.

The cache key is the linchpin. A naïve cache key (just the URL path) maximises hit rate but ignores query strings, cookies, and Accept-Language — which is correct for static images and disastrous for anything personalised. A heavy cache key that includes the auth cookie or every query parameter gives perfect correctness but tanks the hit rate, because each user effectively gets their own cache entry. Most teams misconfigure this on day one.

Cache-Control directives govern what the edge does. public permits CDN caching, private restricts to the browser only, s-maxage is a CDN-specific TTL that overrides max-age, immutable tells the edge never to revalidate, and stale-while-revalidate lets the edge serve a slightly stale copy while fetching a fresh one in the background. For deeper coverage of these headers across browser, CDN, and origin, see HTTP caching explained.

---

Origin shielding and tiered caching

A 300-PoP network has a problem the diagram doesn't show. If you push a new asset and 300 PoPs all cold-miss it at the same time, your origin gets 300 simultaneous requests for the same file. That's a "thundering herd," and on a busy site it can push origin CPU and bandwidth through the floor.

Origin shielding (Cloudflare calls it Tiered Cache, Fastly calls it Shielding, CloudFront calls it Origin Shield) solves this by inserting a middle tier of cache between edge PoPs and the origin. All cache misses from edge PoPs go to the shield first. The shield deduplicates them — only one request actually reaches the origin per asset, and every other PoP gets its copy from the shield.

The numbers are real. Sites running with tiered caching enabled commonly see origin egress drop 80–95% versus a flat-cache design, especially during deploys and traffic spikes. The trade-off is one extra hop on cold fills — typically 20–80 ms — which most teams accept because cold fills are rare. Pick a shield PoP topologically close to your origin (not your users) — its job is to insulate the origin, not to serve users directly.

---

What modern CDNs do beyond caching

The 2026 CDN bundle is much wider than static asset delivery. The features that ship by default now:

Image optimisation — on-the-fly resize, format conversion (AVIF / WebP with JPEG fallback), and quality reduction. You upload one high-resolution image to the origin and the CDN serves whatever format and dimensions each device needs. Cloudflare Images, CloudFront with Lambda@Edge resizers, Fastly Image Optimizer, and Bunny Optimizer all cover this.

Video streaming — HLS / DASH packaging, adaptive bitrate, low-latency streaming. Bunny Stream bundles it at standard bandwidth rates; Cloudflare Stream and AWS Elemental MediaPackage charge separately.

Edge functions / workers — run JavaScript or compiled WebAssembly at the edge, on the same machine handling the cache lookup. Cloudflare Workers run on V8 isolates with sub-millisecond cold start, Fastly Compute runs on a Wasm runtime (Lucet) with ~35 µs startup, CloudFront pairs cheap CloudFront Functions with the more capable Lambda@Edge, and Akamai EdgeWorkers run V8 across 4,200+ PoPs with sub-5 ms cold starts. Use cases: auth-at-edge, A/B testing without origin roundtrips, JWT verification, geographic redirects, and increasingly full SSR for frontend frameworks.

DDoS protection and WAF. Because the CDN sits in the request path, blocking malicious traffic at the edge is structurally cheap. Cloudflare's WAF includes managed rule sets and bot management, AWS has WAF + Shield, Akamai has Kona Site Defender, Fastly has Next-Gen WAF. Most providers include a baseline layer-3/4 DDoS tier free or near-free.

R2 / S3-style edge object storage — Cloudflare R2 (zero egress fees), Bunny Edge Storage, and AWS S3 paired with CloudFront let you skip a separate origin entirely. The CDN reads directly from edge-local storage on cache miss, collapsing "origin + CDN" into one bill.

HTTP/3 and QUIC. All major CDNs enable HTTP/3 by default in 2026. Global adoption sits around 35% on Cloudflare's published radar data, with HTTP/2 fallback automatic. Mobile-latency wins are real on lossy networks; on fast fibre, a 2024 ACM Web Conference paper measured QUIC underperforming HTTP/2 by up to 45% at 1 Gbps. Enable it, but don't expect uniform wins.

---

Provider comparison — Cloudflare, CloudFront, Fastly, Akamai, Bunny

The five providers below cover roughly 90% of production CDN traffic. They overlap on basics — anycast routing, HTTP/3, image optimisation — but diverge sharply on edge compute runtime, pricing model, and the size of the bundle.

Two patterns are worth naming. Cloudflare's bundled pricing means a Workers app using KV + D1 + R2 typically runs $15–50/month for traffic that would cost $200+ on AWS — but the Workers runtime constraints are real, and not every Node.js library works without adapters. Bunny's Volume Network is genuinely the cheapest egress in the market for large static workloads, but the bundle is narrower — if you also need bot management and edge compute on the same provider, you're back to one of the big four.

For most teams in 2026, the short list is Cloudflare for general web traffic, CloudFront if you're locked into AWS, Bunny for video and download-heavy workloads, and Akamai for regulated enterprise. Fastly fits between Cloudflare and Akamai when you need Wasm-grade edge compute and instant purge.

---

When you need a CDN and when you don't

A CDN is table stakes for any public web product with a global audience. If your users are spread across continents, you cannot serve a sub-100 ms TTFB from a single-region origin — physics gets in the way. The cases where a CDN buys you less than the marketing suggests are narrower than people assume.

A purely local audience with a single-country origin gets small wins — the latency floor is already low, so the headline gain becomes DDoS protection and bandwidth offload rather than user-facing speed.

A dynamic-only API with no cacheable surface gets nothing from edge caching, but can still benefit from anycast (faster path to a PoP, then onto the CDN's private backbone to origin) and from edge compute that moves auth and validation off the origin.

An internal tool behind a VPN doesn't need a CDN at all.

Beyond those cases, the calculation is rarely "do I need a CDN" but "which one and how should I configure it" — and the interesting failure mode is teams putting a CDN in front and getting almost no cache hit ratio because the cache key is misconfigured.

---

Common gotchas

The same handful of misconfigurations break CDN deployments year after year. Each one looks fine until traffic scales and the origin starts smoking.

Cache key includes the auth cookie. Most CDNs default to skipping cache entirely if the request includes a cookie, on the assumption that any cookie means a personalised response. The fix is to strip cookies from the cache key for static asset routes and whitelist only the cookies that actually affect output (e.g. theme, locale). Without this, your hit ratio for logged-in users stays at zero.

Query strings tank hit rate. A page linked with ?utm_source=twitter, ?utm_source=linkedin, and ?utm_campaign=launch produces three different cache entries by default. Configure the CDN to ignore tracking parameters, or sort and whitelist only the strings that genuinely affect output. Cloudflare calls this "Cache Key Query String Sort," CloudFront calls it "Forward Query Strings — none."

Wrong Vary header. Vary: Accept-Encoding is correct when the origin gzips conditionally. Vary: Cookie is what produces "logged-in users see logged-out content" bugs. Vary: * disables caching entirely — usually nobody's intent. Audit Vary headers in DevTools when a cache HIT looks wrong.

CORS preflights uncached. Every cross-origin fetch triggers an OPTIONS preflight. If the origin doesn't set Access-Control-Max-Age, every cross-origin API call doubles its round trips. Set Access-Control-Max-Age: 86400 on preflight responses.

Geo rules that misfire. "Block country X" rules can lock out users behind privacy VPNs or corporate egress points. Test geo rules from real residential connections, not cloud test boxes.

Slow purges. When you push a new /api/config.json, the cache must invalidate. Fastly's instant purge runs in ~150 ms globally; CloudFront invalidations cost $0.005 per path after the first 1,000/month and propagate in minutes. Build the purge into your deploy pipeline and verify it completed before declaring deploys done.

If any of these show up as bugs in production, the diagnostic workflow lives entirely in Chrome DevTools' Network panel — response headers, the cf-cache-status / x-cache / x-served-by indicators, and the cache key the CDN actually used.

---

FAQ

What's the difference between a CDN and a reverse proxy?

A reverse proxy sits in front of an origin and forwards requests, often handling TLS termination, load balancing, and basic caching. A CDN is a globally distributed reverse proxy with hundreds of locations, an anycast IP, and a managed cache fabric. Every CDN is a reverse proxy; not every reverse proxy is a CDN.

Do I need a CDN if I use a cloud provider's load balancer?

Yes, for global audiences. A cloud load balancer (ALB, GCLB, Azure LB) usually lives in one region and balances across instances within that region. It doesn't bring static assets closer to users in other continents, and it doesn't offer the edge compute, WAF, or DDoS distribution a CDN does. Many teams use both — CDN at the edge, cloud load balancer at the origin.

How do I check whether my CDN is actually hitting cache?

Look for the cache-status header in the response. Cloudflare returns cf-cache-status: HIT or MISS, CloudFront returns x-cache: Hit from cloudfront, Fastly returns x-cache: HIT, HIT. Open DevTools, hit your page, and scan response headers for static asset requests. Anything routinely showing MISS is worth investigating — usually cache key, query string, or Vary header configuration.

Does HTTPS hurt CDN performance?

Not noticeably in 2026. TLS termination at the edge is fast — modern PoPs handle hundreds of thousands of TLS handshakes per second. TLS 1.3 with 0-RTT resumption makes repeat handshakes near-free. The cost is so low it's not part of any serious capacity calculation anymore.

What's the cheapest CDN for high-bandwidth use cases?

Bunny.net's Volume Network at $0.005/GB for the first 500 TB, dropping to $0.002/GB above 1 PB. CloudFront's first 10 TB in North America runs around $0.085/GB — so the gap is roughly 15–40x in Bunny's favour for static video and software distribution. The trade-off is a narrower feature set.

Can I run a Node.js app on a CDN's edge?

Partially. Cloudflare Workers supports many Node.js APIs through its nodejs_compat flag, but the runtime is V8 isolates rather than real Node — fs, full process, and most native modules are out. Lambda@Edge runs real Node.js and Python with hard limits on package size and execution time. Fastly Compute runs Wasm — you target it from Rust, JS, Go, or AssemblyScript, not raw Node.

What's the difference between CloudFront Functions and Lambda@Edge?

CloudFront Functions are cheap ($0.10 per million requests), fast (sub-ms), and limited (JavaScript ES5.1, no network calls). Lambda@Edge is more expensive ($0.60 per million plus duration), slower, and capable (full Node.js or Python, network calls). Use Functions for header rewrites and simple A/B routing; reach for Lambda@Edge only when you need network calls or longer execution.

---

Where Crosscheck fits

Crosscheck is a free Chrome extension for bug reporting — when a CDN misconfiguration ships to production and a user reports "the page sometimes shows logged-out content," the engineer needs the full diagnostic context to figure out which layer is at fault. Crosscheck captures the screenshot, console logs, and every network request with its response headers and cache-status indicators in one report, attached straight to Jira, Linear, ClickUp, GitHub, or Slack.

Try Crosscheck free