CDN Basics
A content delivery network places caches and compute on the network edge — close to the user, far from your origin. The result: lower latency, less origin load, and better resilience.
What a CDN actually does
- Caches static assets (images, fonts, CSS, JavaScript, video segments) near the user.
- Terminates TLS at the edge so connections only need to traverse the cross-continent leg once per region.
- Routes via anycast — the same IP address is announced from many physical locations; BGP picks the closest one.
- Absorbs traffic spikes and DDoS attacks by spreading load across the network.
- Runs code at the edge (Workers, Lambda@Edge, edge functions) for low-latency transformations.
Cache mechanics
CDN caches obey the same HTTP caching rules as browsers: Cache-Control, ETag, Vary. The key difference is volume — a CDN serves many users from a single cached object, so cache invalidation strategy matters more.
- Long TTLs with versioned URLs. Cache assets for a year (
max-age=31536000, immutable), and bake content hashes into filenames so changing the file changes the URL. - Stale-while-revalidate. Serve a stale object from cache while fetching a fresh copy from origin — keeps p95 latency low.
- Purge on deploy. Push an invalidation API call after every release for HTML and other unhashed entry points.
What not to put behind a CDN
- Per-user content unless you carefully scope cache keys with cookies or session identifiers.
- POST endpoints — most CDNs don't cache writes and won't replay them.
- Anything that depends on accurate client IP unless you forward and trust the
X-Forwarded-Forheader.
!
Cache poisoning. If you treat any unauthenticated request header as part of the cache key, an attacker can craft a request that pollutes the cached response for everyone. Use Vary carefully and only on headers you control.