What Is a CDN, and Why Does the Internet Need Them?

Or: Why the Website You're Visiting Might Be Coming From a Server Much Closer Than You Think

You type a website address into your browser. DNS helps figure out where to send you. Your browser connects to a server, and the server sends the website. Simple enough — except there's a problem hiding in that simplicity.

Imagine a popular website has its main server in California. You're visiting from South Carolina. Someone else is connecting from London, another person from Tokyo, another from Sydney. If every visitor has to retrieve every image, video, script, and stylesheet directly from that one server in California, you're creating an enormous amount of unnecessary traffic and forcing data to travel much farther than it needs to. Now imagine ten million people show up at once. That poor California server is about to have a very bad day.

Modern websites solve much of this problem using a CDN — a Content Delivery Network.

The Basic Idea Is Surprisingly Simple

Instead of keeping all of a website's content in one place, a CDN distributes copies of it across servers in many locations. When you request something, the network tries to serve it from a nearby location rather than routing every single request back to the website's original server. So instead of your request traveling all the way to California and back, it might effectively travel to a server in Atlanta. Someone in England retrieves the same content from London. Someone in Japan retrieves it from Tokyo. The website hasn't moved. Copies of its content have moved closer to the people asking for it.

Think of an online store with one warehouse in Seattle. Shipping a package from Seattle to South Carolina takes longer and uses more transportation infrastructure than shipping it from Atlanta. As the company grows, it opens distribution centers around the country, and popular products get stored closer to customers. When someone in South Carolina orders something, the company ships from the nearby warehouse instead of across the continent. A CDN applies the same idea to digital content — it's just delivering bytes instead of boxes.

Origins, Edges, and Points of Presence

The website still needs an authoritative place where its content actually lives. That's the origin server — it holds the application, the files, the databases, everything real. Without a CDN, users talk directly to that origin. With a CDN in front of it, many requests get handled somewhere else entirely, and the CDN becomes an intermediary that can improve speed, reduce load on the origin, and add security and reliability along the way.

CDN providers run infrastructure across dozens or hundreds of cities, connecting directly with major internet providers and backbone networks. You'll hear this called an edge location or a Point of Presence (PoP) — essentially a spot where the network has equipment capable of serving traffic. Instead of asking "where is the website's server?" the more useful question becomes "which part of the network is serving me right now?" That's what people mean by "the edge": infrastructure positioned closer to the people actually using a service, rather than everything running out of one distant data center.

Distance Matters Because Physics Does

Light travels extraordinarily fast, but not infinitely fast. Data moving through fiber-optic cable travels as pulses of light, and those pulses still take time to cross long distances — plus they pass through routers, switches, and interconnection points along the way. A request that travels across the country and back takes longer than one that travels to a nearby city, even if the difference is only a matter of milliseconds. Websites make many requests per page load, and those milliseconds add up.

This is the same distinction between bandwidth and latency that shows up elsewhere in networking: bandwidth is how much data can move over a connection in a given amount of time, while latency is how long it takes information to travel between two points. A blazing-fast connection doesn't teleport data — if the server is far away, the round trip still takes time. A CDN reduces latency not by making your connection faster, but by making the destination nearer.

It's worth noting that "nearer" isn't purely geographic. Internet traffic follows network routes shaped by the relationships between ISPs, backbone providers, and data centers — a server 200 miles away might sit behind an awkward network path, while one 300 miles away might have excellent connectivity straight to your ISP. When a CDN picks a server "close" to you, it often means close in network terms, not fewest miles on a map.

One of the key techniques behind this routing is Anycast — multiple servers or network locations advertising the exact same IP address, with internet routing itself deciding which one is actually best positioned to answer a given request. From your perspective, you're connecting to a single address. Underneath, that address can exist in dozens of places around the world simultaneously, and the routing system quietly sorts out which one responds.

Caching Is the Real Engine

Moving requests closer to users doesn't help much if every edge server still has to ask the origin for every file. That's where caching comes in — a CDN applies the same fundamental idea your browser and operating system already use, just at massive network scale. When the first visitor requests an image the edge server doesn't have yet, it retrieves that image from the origin and keeps a copy. The next visitor requesting the same file gets it straight from the edge. That's a cache hit — no trip back to the origin required, faster for the visitor, less work for the origin, fewer long-distance network resources used. A request for something the edge doesn't have yet is a cache miss, which takes longer the first time but means the content is cached and faster for everyone who asks after.

Content can't stay cached forever, though. If you update an image on your origin server, the CDN might still be quietly handing out yesterday's version. That's why caches rely on a TTL — Time to Live — telling an edge server how long it can keep serving a stored copy before checking for something newer. Static files might stay cached a long time; frequently changing information might barely be cached at all. When a website owner needs an update to take effect immediately, they can purge or invalidate the cached copy, forcing the next request to fetch a fresh version — distributing that instruction across a huge global network quickly is a much harder engineering problem than the little "Purge Cache" button suggests.

Smart sites sidestep some of this entirely with cache-busting: instead of reusing a filename like app.js forever, they embed a hash in it, so app.a7f93c.js becomes app.d821be.js the moment the code changes. The new file has an entirely different address, so the CDN never has to guess whether the old one is stale — it can stay cached indefinitely without causing confusion.

None of this applies evenly, either. A public company logo is an excellent caching candidate. A page showing your bank balance is not — caching decisions depend heavily on what the content actually is, and servers send explicit instructions describing whether something may be stored, for how long, and under what conditions.

Static Content Is Easy. Dynamic Content Isn't.

CDNs made their name serving images, stylesheets, scripts, fonts, downloads, and video — content that's often identical for millions of users, which makes it ideal for caching. But a page that says "Welcome back, Joe" or "your cart has three items" depends entirely on who's asking, and that response can change constantly. Traditional caching gets complicated fast when nearly every response is different. Modern CDNs still accelerate dynamic sites through smarter routing, connection reuse, selective caching, and increasingly, edge computing — running actual code at the edge instead of sending every request back to a central application server. An edge server running code can redirect a visitor, modify a response, authenticate a request, resize an image on the fly, or run an A/B test, all without the round trip to a distant data center. If every request needs a one-millisecond calculation, running that calculation near the user rather than shipping the request across an ocean and back can matter far more than the calculation itself.

Absorbing the Internet's Biggest Moments

The payoff at scale is enormous. If a million people request the same 2 MB image and 99% of those requests get served from cache, the origin never sees most of that traffic — a massive reduction in bandwidth, server load, and infrastructure cost. That's how a website can survive going from a thousand daily visitors to a million overnight without its origin server buckling. It's also how the internet handles enormous simultaneous events — a live sports broadcast, a game launch, a major software update — by spreading the load across enormous numbers of machines and network locations instead of funneling everyone through one building. Some streaming providers push this further by placing caching appliances directly inside ISP networks, so popular video barely has to leave your own internet provider's infrastructure to reach you.

Security Rides Along for Free

Because a CDN sits directly in the traffic path between visitors and the origin, it's positioned to inspect and filter requests before they ever reach the website's actual infrastructure. That matters most during a DDoS attack — a Distributed Denial of Service attack, which tries to overwhelm a service with so much unwanted traffic that real users can't get through, like ten million fake customers crowding a store's doorway. A large CDN's distributed capacity can absorb or filter that flood across many locations at once, rather than leaving one origin server to face it alone. Many CDNs also offer a Web Application Firewall (WAF), which inspects web traffic for malicious patterns and blocks harmful requests before they reach the application — not a guarantee of safety, but a meaningful extra layer.

The Tradeoff: Shared Infrastructure, Shared Failure

This convenience comes with a catch. The internet was designed as a distributed network, but modern websites increasingly depend on a small number of enormous infrastructure providers. When one of those providers has a bad day — a bad configuration deployed to a major CDN, say — the underlying internet is fine, the affected websites' origin servers are fine, but requests passing through that CDN start failing anyway. Suddenly, seemingly unrelated news sites, shopping platforms, and games all appear broken at once, and the actual failure is invisible until someone traces it back to the shared provider underneath all of them. It's also why a CDN error page doesn't necessarily mean the website itself is down — the origin might be running perfectly while the CDN can't reach it, or the CDN itself is the thing having trouble.

Worth remembering too: a CDN is not a backup. Cached copies exist for delivery speed, not preservation — they expire, get evicted, and get replaced. If the origin loses its only authoritative copy of something important, there's no guarantee the CDN preserved it. Delivery infrastructure and recovery infrastructure are different jobs.

The Bard's Take

When you visit a website, you might assume you're connecting directly to that company's server. Often you aren't. You're connecting to a server operated by a content delivery network, sitting relatively close to you, which may already hold the images, scripts, or entire pages you're asking for. The origin server could be hundreds or thousands of miles away and never hear about your visit at all.

That's the core trick of a CDN: instead of building one enormous server and making the entire planet travel to it, spread the work out. Put copies of popular content near the people who need it. Cache what doesn't need to be fetched twice. Route visitors toward whichever infrastructure can reach them fastest. Absorb traffic spikes and attacks across many locations instead of one. Increasingly, do some of the actual computing at the edge instead of shipping every request back to a distant data center.

The tradeoff is that the more of the web depends on the same handful of giant infrastructure providers, the more spectacular things get when one of them stumbles. That's why a single CDN outage can make dozens of unrelated websites appear to break simultaneously — the internet is distributed, but a lot of what's built on top of it shares the same highways and warehouses.

Most days you never notice any of it. You click a link, the page appears, and somewhere — often only a few milliseconds away — an edge server quietly says: don't bother the origin, I've already got a copy.

Sources

• What Is a CDN? — Cloudflare
• HTTP Caching — MDN Web Docs
• Anycast — Wikipedia — Wikipedia
• DDoS Attacks Explained — Imperva