How CDNs Make the Web Fast

A request through a CDN

1. The user's request is directed to the nearest edge, using anycast or DNS (post 11).
2. The edge checks its cache. A cache is a place that keeps copies of files so they can be served again quickly.
   • Cache hit: the edge has the file, so it returns it immediately.
   • Cache miss: the edge does not have the file, so it fetches it from the origin, return it to the user, and keep a copy for next time.
3. Later users near that edge get the fast cached copy.

The key metric is the cache hit ratio: the share of requests answered from the cache. If it's 95%, only 5% of requests ever reach your servers.

Pull CDN vs push CDN

• Pull CDN (most common). You point the CDN at your origin. Edges fetch content on demand at the first request, then cache it.
  • ✅ Easy: no upload step.
  • ❌ The first user in each region gets a slower miss.
• Push CDN. You upload content to the CDN ahead of time.
  • ✅ No first-request miss, and you have full control over what's stored.
  • ❌ You must manage uploads and storage. It's good for large, planned content like software downloads or a video library.

For a site with millions of rarely-viewed images, pull is usually better, because you only store what's actually requested. For a big game update everyone downloads at launch, push (pre-warming) makes sense.

What to put on a CDN

• Static assets: JavaScript, CSS, fonts, icons.
• Images and video: product photos, thumbnails, video segments.
• Downloads: apps, installers, PDFs.
• Whole static pages: blogs, documentation, marketing sites.
• Some API responses: public, rarely-changing data like a product catalogue or exchange rates, cached for a short time.

Don't cache: personal pages (your cart, your account), anything with private data, or responses that must always be up to the second, unless you're very careful with cache rules.

How the CDN knows what to cache: HTTP headers

An HTTP header is a line of extra information sent with a request or response. CDNs follow the standard HTTP caching headers from your origin. max-age is the number of seconds a copy may be reused. immutable means the file will never change.

Cache-Control: public, max-age=31536000, immutable

means "anyone may cache this for a year; it will never change". It's perfect for versioned files like app.3f2a9c.js.

Cache-Control: public, max-age=60, stale-while-revalidate=300

means "cache for 60 seconds. After that, you may serve the old copy for up to 5 more minutes while fetching a fresh one in the background". The word "stale" means old. This is great for pages that change occasionally.

Cache-Control: private, no-store

means "do not store this at all, and only the user's own browser may use it". A shared cache is a cache used by many people, such as a CDN. Use this for account pages and anything personal.

Other headers you'll use:

• s-maxage: like max-age, but only for shared caches like CDNs.
• ETag / Last-Modified: let the CDN ask the origin "has this changed?" and get a small 304 Not Modified back. An ETag is a label (like a fingerprint) for one version of a file. Last-Modified is the time the file last changed.
• Vary: "cache different copies depending on this header", for example Vary: Accept-Encoding for gzip vs Brotli versions. Be careful: Vary: Cookie can destroy your hit ratio.

The cache key is what the CDN uses to decide whether two requests are "the same". By default it's the URL. A query parameter is the part of a URL after the ?. If your URLs include random tracking parameters (?utm_source=...), you may want the CDN to ignore them, or every link becomes a separate cache entry.

Invalidation: updating cached content

"There are only two hard things in computer science: cache invalidation and naming things." This saying is famous for a reason. Once a file is cached on hundreds of edges, how do you update it?

1. Versioned file names (best for static assets). Build tools like Vite, webpack and Next.js add a content hash: app.3f2a9c.js. A new deploy produces app.8b1d4e.js, a new URL, so there's nothing to invalidate. Cache the files forever, and keep the HTML itself on a short cache time.
2. Purge. Tell the CDN "delete /images/banner.jpg everywhere". Most CDNs purge within seconds, but it's an extra step, and frequent purges can hit limits.
3. Short TTLs. For content that changes regularly, just cache it for 30–60 seconds. Even a short cache absorbs huge traffic spikes.
4. Tags / surrogate keys. Some CDNs let you tag responses ("product-991") and purge everything with that tag in one call.

Origin shielding

With 300 edges, a cache miss could mean 300 separate requests to your origin for the same file. Origin shield (tiered caching) adds a middle layer. Edges ask a regional shield cache first, and only the shield talks to your origin. This protects your servers from "miss storms".

Video delivery

Streaming services cut videos into small segments (a few seconds each) at several quality levels, using formats like HLS or DASH (two standard ways to stream video over normal HTTP). Each segment is just a small static file, which is perfect for CDNs. The player picks the quality level that matches your connection, switching up or down as your network changes. That's why a video goes blurry for a moment and then sharpens.

CDNs do more than caching

Modern CDNs also provide:

• DDoS protection: a DDoS attack sends huge fake traffic to knock a site offline. A CDN absorbs this traffic across its global network.
• Web Application Firewall (WAF): a filter that blocks common attacks such as SQL injection.
• TLS at the edge: TLS is the encryption used by HTTPS. The handshake (the first exchange that sets up encryption) happens nearby, so HTTPS starts faster.
• Image optimisation: automatically resizing images and converting them to modern formats (WebP/AVIF).
• Edge compute: running small pieces of code at the edge for redirects, A/B tests (showing two versions to compare them), auth checks or personalisation (for example, Cloudflare Workers or Lambda@Edge).