Updated 9 hours ago
A Content Delivery Network is a system of strategic waiting. Servers positioned around the world hold copies of your content, anticipating requests. When someone in Tokyo wants your image, they don't wait for it to travel from California—a server in Tokyo already has it, ready to respond in milliseconds.
This seems simple. It is not.
The Speed of Light Is the Problem
When you load a website, every resource—HTML, images, videos, CSS, JavaScript—must travel from server to browser. Light is fast, but the Internet is not a straight line. Data packets hop between routers, cross oceans through undersea cables, and accumulate delay at every step.
California to Tokyo: 100-200 milliseconds round-trip, minimum. That's before the server processes anything. A page with fifty resources, each requiring a round trip? Several seconds, easily.
CDNs solve this by putting copies of your content everywhere. When Tokyo requests your image, a server in Tokyo responds. The Pacific Ocean is no longer in the way.
How It Actually Works
You configure your site so content requests go to the CDN instead of your server. Your HTML references cdn.example.com/image.jpg instead of www.example.com/image.jpg.
When a browser requests that image, DNS routes it to the CDN's network. The CDN's routing system picks the best server based on geography, current load, and network conditions.
If that server has the image cached—a cache hit—it responds immediately. The content might be cached because someone nearby requested it recently, because the CDN pre-loaded popular content, or because of rules you specified.
If the server doesn't have it—a cache miss—it fetches from your origin server, caches the response, and forwards it to the user. The next request from that region hits the cache.
This is where it gets interesting: a CDN is a bet that your content won't change before someone asks for it again.
The Caching Bet
Every cache configuration is a trade-off between speed and freshness.
Set a long TTL (time-to-live), and your origin server barely gets touched. Content flies from edge servers worldwide. But if you update your logo, users see the old one until the cache expires.
Set a short TTL, and changes propagate quickly. But your origin server handles more requests, and you lose some of the CDN's benefit.
HTTP headers control this bet. Cache-Control: max-age=86400 means "cache this for 24 hours." The CDN obeys. If you change the content after hour one, twenty-three hours of users see stale data.
This is why cache invalidation is one of the two hard problems in computer science (the other is naming things). When content changes before its TTL expires, you need to actively purge it from every edge server worldwide. Most CDNs provide APIs for this. Some support tag-based purging—tag related content, purge all items with that tag at once.
The clever workaround: versioned URLs. Instead of purging logo.png, you deploy logo-v2.png. Different URL, different resource, no invalidation needed. The old version expires naturally while everyone immediately gets the new one.
What Caches Well
Static content is the sweet spot. Images, videos, CSS, JavaScript, fonts, downloadable files—anything identical for all users that doesn't change often. These are perfect CDN candidates.
Dynamic content is trickier. Personalized pages can't be cached and shared. But even dynamic sites have cacheable pieces. Product listings might be dynamic; product images are not. Some CDNs can cache dynamic content briefly, serve stale content while revalidating, or use edge computing to generate responses at the edge.
Why This Matters
Speed is the obvious win. Nearby servers mean lower latency, more bandwidth per user, and often better network paths. Users perceive this as a faster site. Faster sites convert better.
Origin offload means your servers handle only cache misses and truly dynamic requests. The CDN absorbs the majority of traffic. You serve more users with less infrastructure.
Reliability improves because content exists in many places. One edge server fails? Requests route elsewhere. Your origin goes down? The CDN keeps serving cached content—your site stays partially alive.
DDoS resistance comes from distributed capacity. Attackers try to overwhelm servers with traffic. CDNs have massive bandwidth spread across many locations. Overwhelming the whole network is much harder than overwhelming one server.
Global reach without global infrastructure. A startup in San Francisco can serve users in Singapore as fast as users in San Jose. The CDN provides the worldwide presence.
The Complications
Debugging gets harder. Is this response cached or fresh? Which edge server served it? Why is this user seeing old content? Caching adds a layer of indirection that can obscure problems.
Configuration matters. Misconfigured caching serves stale content to users or fails to cache at all. Understanding cache behavior takes effort.
Cost scales with traffic. Free tiers work for small sites. High-traffic sites can incur significant CDN expenses, and pricing varies dramatically between providers and regions.
Your origin still matters. If your origin dies completely, cached content eventually expires or users request uncached resources. The CDN buys you time, not immortality.
Cache poisoning is a security concern—an attacker tricks the CDN into caching malicious content served to other users. Proper configuration and security headers mitigate this.
Beyond Caching
Modern CDNs do more than hold static files.
Edge computing runs code at edge locations. Personalize content close to users. Authenticate at the edge. Implement routing logic without touching origin servers.
Image optimization automatically resizes, compresses, and converts images based on device and browser. Serve WebP to Chrome, JPEG to older browsers, smaller images to mobile.
SSL termination at the edge handles encryption near users, reducing handshake latency and offloading work from origin servers.
Web Application Firewalls block malicious requests before they reach your infrastructure.
Bot management distinguishes humans from bots, allowing search crawlers while blocking scrapers and attackers.
Choosing a Provider
Cloudflare offers a generous free tier with CDN, DDoS protection, and WAF. Popular with small sites and startups.
Amazon CloudFront integrates tightly with AWS. Pay-as-you-go pricing. Natural choice if you're already on AWS.
Fastly emphasizes real-time delivery and instant purging. Popular with media companies needing frequent cache invalidation.
Akamai is one of the oldest and largest CDNs. Enterprise-focused, comprehensive features, premium pricing.
Bunny CDN offers straightforward, cost-effective pricing. Popular among cost-conscious developers.
Google Cloud CDN and Azure CDN integrate with their respective cloud platforms.
The Core Insight
A CDN works because most content doesn't change most of the time. Servers wait near your users, holding copies, ready to respond instantly. The entire system is a bet on temporal locality—if someone asked for this recently, someone will ask again soon.
When you configure a CDN, you're deciding how to place that bet. How long before content expires? What happens when it changes? How do you balance freshness against speed?
Get it right, and your site feels instant worldwide. Get it wrong, and users see stale content or your origin server groans under load you thought you'd offloaded.
The distance problem is real. CDNs are the elegant solution. But elegance, as always, requires understanding the trade-offs.
Was this page helpful?