What Is a CDN? How the Web Stays Fast Across the Whole Planet

Imagine your website lives on a single server in Singapore. A visitor in Singapore opens it and the page snaps into view. But a visitor in Brazil opens the same page, and every image, every script, every byte has to travel halfway around the planet and back before they see anything. Same site, very different experience — and the only thing that changed was distance.

A CDN is the standard fix for that problem. The name stands for Content Delivery Network, and the idea behind it is wonderfully simple: instead of serving everyone from one faraway machine, you keep copies of your content on lots of machines scattered across the world, and hand each visitor the copy that’s nearest to them. Let’s unpack how that actually works and why it matters so much.

What a CDN actually is

A CDN is a network of servers placed in many locations around the world, whose job is to deliver content to visitors from whichever location is closest to them. Those servers are called edge servers, because they sit at the “edge” of the network — close to real users — rather than in one central spot.

Here’s the key shift in thinking. Without a CDN, there’s one place your site lives: your origin server (the machine where the real, original files actually sit). Everyone in the world fetches from that one place. With a CDN, your origin server still holds the master copy, but the CDN keeps cached copies of your content on its edge servers all over the globe. Visitors get served from the edge, not from the origin — and the origin only gets bothered when the edge doesn’t already have what’s needed.

So a CDN isn’t a replacement for your server. It’s a layer that sits in front of it, fanning your content out to be physically near everyone at once.

Why distance is the problem in the first place

To get why a CDN helps, you have to appreciate that data on the internet doesn’t move instantly. It travels as signals through cables — including long undersea fiber cables between continents — and that takes real time. The further the data has to go, the longer each round trip takes. This delay is called latency, usually measured in milliseconds.

It sounds tiny, but it stacks up fast. Loading a single web page isn’t one request — it’s often dozens: the HTML, then the CSS, then images, fonts, scripts, and more. Many of those happen in sequence, where the browser can’t ask for the next thing until it gets the last one. If each round trip to a distant server takes 250 milliseconds instead of 20, those delays pile on top of each other and the page crawls.

WITHOUT a CDN — everyone fetches from one origin in Singapore

   Visitor (Brazil)  ───── long trip ─────►  Origin (Singapore)
                     ◄──── long trip ──────
   (slow: data crosses the planet and back, many times)


WITH a CDN — content is cached at edges near each visitor

   Visitor (Brazil)  ──► Edge (São Paulo)   ◄── short trip, fast
   Visitor (Japan)   ──► Edge (Tokyo)        ◄── short trip, fast
   Visitor (Germany) ──► Edge (Frankfurt)    ◄── short trip, fast
                              │
                              │ (only on a cache miss)
                              ▼
                        Origin (Singapore)

Shortening the physical distance shortens the latency, and shortening the latency makes the page feel fast. That’s the whole magic trick. If you want a refresher on how data physically gets from one machine to another in the first place, the article on how the internet works lays the groundwork this builds on.

How a CDN actually serves a request

Let’s walk through what happens the moment someone visits a CDN-backed site. The sequence is the heart of the whole concept.

1. A visitor’s browser asks for, say, a logo image on your site.
2. Through DNS, that request is routed not to your origin, but to the nearest edge server in the CDN.
3. The edge server checks: do I already have a fresh copy of this image cached?
4. If yes — a “cache hit” — it sends the cached copy straight back. Fast, and your origin never even hears about it.
5. If no — a “cache miss” — the edge server fetches the file from your origin once, sends it to the visitor, and keeps a copy so the next person nearby gets a cache hit.

   Browser ──► Edge server: "give me /logo.png"
                   │
                   ├─ have it cached & fresh?  ──► YES ──► send it (cache HIT) ✓
                   │
                   └─ NO (cache MISS)
                         │
                         ├─► fetch once from Origin
                         ├─► store a copy at the edge
                         └─► send it to the browser

The beautiful part is that the first visitor in a region “warms up” the cache, and everyone after them in that region gets the fast cached version. The origin does a tiny fraction of the work it used to, because most requests never reach it.

Caching: how the edge knows what to keep, and for how long

Caching is the engine inside a CDN, so it’s worth understanding the controls. The big question for any piece of content is: how long is it safe to keep a copy before checking with the origin again? That duration is the content’s TTL (time to live).

The right TTL depends entirely on how often the content changes:

• Static assets that rarely change — your logo, fonts, a CSS file, a product photo — can be cached for a long time (hours, days, even longer). They’re the same for everyone and they don’t go stale.
• Content that changes often — a news homepage, a price, a stock count — needs a short TTL or careful handling, so visitors don’t see outdated information.
• Personalized or private content — a logged-in user’s dashboard, their cart — usually shouldn’t be cached on a shared edge at all, because it’s different for every person and may be sensitive.

The origin tells the CDN how to cache each file using HTTP response headers (most importantly Cache-Control). A typical instruction looks like this:

Cache-Control: public, max-age=86400

That says: this file is fine to cache publicly, and it stays fresh for 86,400 seconds — exactly one day. After that, the edge re-checks with the origin. Getting these headers right is most of the skill in running a CDN well.

The classic gotcha: stale content

The flip side of caching is that the edge might keep serving an old copy after you’ve updated the file. You push a fix to your CSS, but visitors keep getting the cached old version until its TTL expires. There are two standard ways to handle this:

• Purge (or “invalidate”) the cache — tell the CDN to drop a cached file immediately so the next request re-fetches the fresh one. Good for “I changed something, update it now.”
• Cache busting — give the file a new name or version each time it changes, like style.a1b2c3.css. Because the URL is new, the CDN treats it as a brand-new file with no cached copy, so visitors always get the latest. The old version simply ages out.

Cache busting is the more reliable habit for assets, because it sidesteps the staleness problem entirely instead of fighting it.

What a CDN gives you beyond speed

Speed is the headline, but a good CDN earns its keep in a few other ways too.

• It absorbs traffic spikes. Because the edge handles most requests, a sudden flood of visitors hits the CDN’s huge distributed capacity rather than slamming your single origin. A post that goes viral is far less likely to take your site down.
• It reduces load (and bandwidth cost) on your origin. Every request served from the edge is one your origin didn’t have to handle. For sites serving large files like images and video, that offload is enormous.
• It adds a layer of protection. Sitting in front of your origin, a CDN can soak up certain attacks — especially DDoS attacks, where attackers try to overwhelm a site with junk traffic. The CDN’s scale lets it absorb floods that would flatten a lone server, and it can hide your origin’s real address. This pairs naturally with the broader filtering you’d do at a firewall.
• It handles HTTPS at the edge. CDNs terminate secure connections close to the visitor, which keeps encrypted traffic fast. If the term is fuzzy, the piece on SSL, TLS, and HTTPS explains what’s happening under the hood.

It’s worth noting how this differs from load balancing. A load balancer spreads requests across multiple servers, usually within one data center, to share the work. A CDN spreads cached content across many locations worldwide to shorten distance. They solve related but different problems, and large sites happily use both.

How a CDN is set up (the short version)

You don’t have to rebuild anything to use a CDN. The two common ways to put one in front of an existing site are:

• Point your DNS at the CDN. You change your domain’s DNS records so traffic flows through the CDN’s edge first, which then talks to your origin behind the scenes. This routes your whole site through the CDN. If DNS records feel hazy, domains and DNS covers exactly what those records do.
• Serve specific assets from a CDN URL. You upload or reference particular files (images, scripts, fonts) through the CDN and link to them directly, leaving the rest of your site on the origin. This is common for heavy static assets.

Either way, the visitor never knows. They type your normal domain, and the routing quietly hands them the nearest, fastest copy.

Wrapping up

Here’s the whole idea in one place:

• A CDN (Content Delivery Network) is a worldwide network of edge servers that keep cached copies of your content close to your visitors.
• It exists to beat latency — the delay caused by physical distance — by serving each visitor from a nearby edge instead of one faraway origin.
• It works through caching: a cache hit is served fast from the edge; a cache miss fetches once from the origin and stores a copy for next time.
• TTL and Cache-Control headers decide how long content stays cached; purging and cache busting handle updates so visitors don’t get stale files.
• Beyond speed, a CDN absorbs traffic spikes, offloads your origin, helps fend off attacks like DDoS, and handles HTTPS at the edge.
• It sits in front of your origin, not in place of it — your origin still holds the master copy and runs your real logic.

Next, it’s worth looking at the machines that quietly sit between clients and servers to route, filter, and forward traffic — the world of proxies and gateways, which a CDN is, in a sense, one large and clever example of.