CDN (Content Delivery Network) is a distributed network of servers located around the world that delivers web content to users with minimal latency.
The Problem CDN Solves
Imagine your favorite website is physically hosted on a server in San Francisco. You open it from Kyiv, and your request travels ~9,000 km each way. Even at the speed of light, that’s ~60–90 ms just for the physical signal propagation, and real-world latency, including routing and processing, easily reaches 200–300 ms.
Now multiply that across dozens of resources (images, fonts, scripts) — and the page takes seconds to load.
CDN solves this simply: it stores copies of content closer to the user.
How It Works
Edge Nodes and PoPs
A CDN consists of hundreds (and for large players, thousands) of Points of Presence (PoPs) located in data centers around the world. Each PoP contains edge servers — cache nodes that store copies of popular content.
When you open a website:
- The DNS query resolves to the nearest edge node (via anycast or GeoDNS).
- The edge server checks its cache.
- If the content is there, it returns it immediately (cache hit).
- If not, it fetches from the origin server, caches the content, and returns it to you (cache miss).
Anycast: One IP, Many Servers
Most large CDNs use anycast routing: the same IP address is announced from dozens of locations simultaneously. The BGP network automatically routes your packet to the geographically nearest node — with no additional logic required on the client side.
What Gets Cached
| Content Type | Cached | TTL |
|---|---|---|
| Images (jpg, png, webp) | Yes | Days–weeks |
| Video and audio | Yes | Long-term |
| CSS, JavaScript | Yes | Hours–days |
| HTML pages | Partially | Minutes–hours |
| API responses | Rarely | Seconds |
| Personalized content | No | — |
Cache Invalidation: The Hardest Problem
“There are only two hard things in computer science: cache invalidation and naming things” — Phil Karlton
When you update a file on the origin server, edge nodes around the world continue serving the old version for some time. There are several strategies to deal with this:
TTL (Time To Live) — the simplest approach. Each object has a lifetime, after which the node requests a fresh version. The downside: between the update and TTL expiration, users see stale content.
URL versioning — instead of styles.css, you use styles.v3.css or styles.css?v=a3f8b2. A new URL means a new cache entry. This is the most reliable approach and is widely used in front-end development.
Purge API — CDN providers offer an API for forcefully evicting objects from all edge nodes. Cloudflare, for example, does this in ~150 ms globally.
Stale-while-revalidate — the edge node returns stale content immediately but refreshes the cache in the background. A compromise between speed and freshness.
More Than a Cache: The Modern CDN Is a Platform
Modern CDNs have long outgrown simple caching. Here’s what else they do:
TLS Termination
HTTPS encryption is handled at the nearest edge node, not the origin server. This reduces TLS handshake latency and offloads work from the backend.
DDoS Protection
A CDN absorbs attack traffic thanks to its enormous aggregate bandwidth. Cloudflare, for example, handles over 3 Tbps during large-scale attacks — most origin servers simply wouldn’t survive that load.
Edge Computing
Cloudflare Workers, AWS Lambda@Edge, and Fastly Compute allow you to run code directly on edge nodes — without touching the origin. This enables:
- Network-level A/B testing
- Content personalization without an origin server
- Geolocation-based redirects
- On-the-fly image transformation
Image Optimization
Cloudflare Images, Imgix, and Fastly automatically convert images to WebP/AVIF, resize them for the device, and compress without quality loss — all on the fly, with no changes to your site’s code.
Popular CDN Providers
Cloudflare — the largest network (~330 PoPs), a free tier, and aggressive DDoS protection. Dominates among websites.
AWS CloudFront — deep integration with the Amazon ecosystem. The go-to choice for teams already on AWS.
Akamai — one of the oldest players (since 1998), enterprise-grade, complex pricing.
Fastly — popular among developers for its flexibility and edge computing capabilities. Used by GitHub, Spotify, and the NY Times.
Bunny CDN — an affordable and straightforward option, popular among smaller projects.
Metrics: How to Measure CDN Effectiveness
- Cache Hit Ratio — the percentage of requests served from cache. A good target: 85–95%+.
- TTFB (Time to First Byte) — time until the first byte of the response. A CDN can reduce this from 300 ms down to 20–30 ms.
- Origin offload — the share of traffic that never reaches the origin server. The higher, the cheaper and more stable.
- P95/P99 latency — tail latencies matter more than averages: they determine the experience of your slowest users.
Limitations and Caveats
A CDN is not a silver bullet. Here’s where it won’t help — or might even cause problems:
Dynamic content is hard to cache. Personal feeds, shopping carts, and user dashboards — all of this still hits the origin.
Cache poisoning — an attack where a malicious actor tricks the CDN into caching harmful content, which it then serves to all users. Requires correct response header configuration.
Regulatory compliance — certain categories of data (medical, financial) cannot be stored on servers in particular countries. CDNs must be configured with geographic restrictions in mind.
Vendor lock-in — provider-specific features (edge workers, caching rules) are often incompatible across vendors.
Conclusion
The CDN has evolved from a simple cache server into a full-fledged infrastructure platform. Today, it is responsible for load speed, security, availability, and even business logic for billions of web requests every day.
For most projects, adding a CDN is one of the easiest and most impactful performance improvements available: minimal effort, maximum result. And for large platforms like Netflix or YouTube, running without dedicated or leased CDN infrastructure simply isn’t an option.