Content Delivery Networks (CDN)
Updated June 8, 2026Speed of light is not a bottleneck you can engineer around. If your server is in Virginia and your user is in Tokyo, the round-trip time is physically constrained to around 150-200ms, even with perfect network conditions. For a single API call that's manageable. For loading a web page with dozens of assets, it compounds into a noticeably slow experience.
A Content Delivery Network (CDN) solves this by not making the user travel all the way to your origin server. Instead, it places copies of your content at dozens or hundreds of locations around the world — called Points of Presence (PoPs) or edge nodes — and serves users from whichever one is closest to them.
What CDNs Actually Do
At its core, a CDN is a geographically distributed caching layer. When a user requests a resource, the request goes to the nearest CDN edge node. If that node has the content cached, it serves it immediately — no round-trip to your origin server, dramatically lower latency. If it doesn't have the content, it fetches it from origin, caches it, and serves it.
Cache hit: the nearby CDN PoP serves the file from memory with no origin contact.
Cache miss: on the first request the edge PoP fetches from the distant origin, caches it, and all future requests resolve at the edge.
The result: a user in Sydney gets your assets from a CDN node in Sydney, not from a server in Frankfurt. Latency drops from 250ms to 15ms. Page load feels instant.
How CDN Caching Works
There are two fundamental models for getting content onto CDN nodes:
Origin Pull (Pull-Based CDN)
The CDN pulls content from your origin server on-demand. When a user requests a file that isn't cached at the edge yet, the CDN fetches it from your origin, caches it, and serves the user — all transparently.
The first user to request a file at any given edge node pays the origin round-trip. Every subsequent user gets it from the edge cache.
How long it stays cached: Controlled by your Cache-Control headers. A header like Cache-Control: max-age=31536000, immutable tells the CDN to cache this file for a year and never re-validate it.
This is the default model for most CDNs, including Cloudflare and CloudFront.
Origin Push (Push-Based CDN)
You proactively upload content to the CDN's edge nodes before any user requests it. You're pushing content out to the edge rather than waiting for the first request to pull it there.
When to use push: Large files (video, software downloads) where the first-user experience matters, or when you need predictable cache warming before a launch.
Tradeoff: You manage which content gets pushed and when. More control, more operational overhead.
What CDNs Cache
Static Assets
The CDN's home turf. JavaScript bundles, CSS files, images, fonts, videos — anything that doesn't change per-user is a perfect CDN candidate.
Best practice: content-hash your filenames (main.a3b4c5.js) so you can set infinite TTLs (Cache-Control: max-age=31536000, immutable). When the content changes, the filename changes, busting the cache automatically.
Video Streaming
Netflix, YouTube, Spotify — all use CDNs for media delivery. A 4K video file is multiple gigabytes; delivering it from a single origin to millions of simultaneous viewers would require absurd bandwidth. CDNs distribute that load across edge nodes globally.
Netflix actually takes this further with Open Connect — their own private CDN that they install directly inside ISP networks, getting latency as close to zero as physically possible.
Dynamic Content and API Acceleration
Modern CDNs have evolved beyond static assets. Cloudflare, Fastly, and AWS CloudFront can cache API responses, terminate TLS at the edge, handle DDoS protection, and run business logic at the edge.
Even for content that can't be cached, CDNs improve performance by:
- Terminating TCP connections close to the user (faster handshake)
- Maintaining persistent connections to the origin (no per-request TCP setup)
- Using optimized routing from edge to origin (CDN backbone vs public internet)
Real CDN Providers
| CDN | Known For |
|---|---|
| Cloudflare | Enormous network (300+ PoPs), DDoS protection, edge compute (Workers), free tier |
| AWS CloudFront | Deep AWS integration, Lambda@Edge, strong for AWS-hosted apps |
| Fastly | Highly programmable (VCL/Compute), popular with media companies, real-time purging |
| Akamai | Oldest and largest CDN, enterprise-focused, 4,000+ PoPs, strong for compliance |
| Vercel Edge Network | Developer-focused, tight Next.js integration, automatic edge caching |
Cache Invalidation at the Edge
CDN caching creates the same staleness problem as any cache — when your content changes, how do you update the edge nodes?
Option 1: TTL expiry. Set short TTLs so cached content naturally expires. Simple, but stale content can linger until the TTL runs out.
Option 2: Purge/Invalidate API. All major CDNs provide an API to explicitly purge cached content by URL or by tag. When you deploy new code, your deployment pipeline triggers a purge. This is the standard approach for content that changes.
Option 3: Versioned URLs. The best approach for immutable assets. Change the filename (via content hashing) when content changes. Old URL serves old cached content. New URL triggers a cache miss and fetches fresh content from origin. No invalidation needed at all.
Edge Computing: The Next Evolution
CDNs started as dumb caches — store a file, serve a file. The evolution over the last decade has been pushing compute to the edge, not just storage.
Cloudflare Workers, AWS Lambda@Edge, and Fastly Compute let you run JavaScript (or WASM) at CDN edge nodes. This means:
- Personalize responses at the edge without hitting your origin
- A/B testing logic at the edge with zero latency overhead
- Authentication and authorization checks at the edge before the request reaches your server
- Server-side rendering at the edge (Vercel, Cloudflare Pages)
The mental model shift: the edge is no longer just a cache layer. It's becoming a globally distributed compute platform.
Next.js's Middleware runs at the edge by default on Vercel. Authentication redirects, locale detection, and feature flags all execute within milliseconds of the user — because the compute is physically near them.
When to Use a CDN
You should almost always be using a CDN. The question is more about how much you lean on it:
- Always: Static assets (JS, CSS, images, fonts) — no reason not to
- Almost always: Video and large file delivery
- Often: Cacheable API responses (public data, no auth required)
- Situational: Dynamic, authenticated API responses — benefit from TCP termination/acceleration even without caching
Summary
A CDN is a globally distributed caching layer that serves content from locations close to your users, dramatically reducing latency and offloading traffic from your origin servers.
- Origin pull: CDN fetches content on first request and caches it
- Origin push: You proactively distribute content to edge nodes
- Static assets: Perfect CDN use case — infinite TTLs with versioned filenames
- Video streaming: CDNs are essential at scale; bandwidth would be unmanageable without them
- Edge compute: Modern CDNs run your code at the edge, not just cache your files
- Real providers: Cloudflare, CloudFront, Fastly, Akamai — pick based on your stack and requirements
The speed of light is fixed. CDNs are how you work around it.
How helpful was this content?
Comments
Sign in to join the discussion
Saved on this device only
Sign in to sync progress across devices