What is a CDN and why do most websites use one?

When you visit a large news site from California, or Mumbai, or Lagos, the page loads at roughly the same speed. That's surprising if you sit with it for a moment. Data has to physically travel to you — as electrical signals through fibre-optic cables, ultimately constrained by the speed of light. Mumbai is 13,000 miles from CNN's offices in Atlanta. Lagos is 6,000 miles from London. If your request had to go all the way to the origin server and back, the latency would be noticeable.

The answer is a CDN — a content delivery network. CDNs are the reason the modern web feels consistently fast regardless of where you are, and they're now so pervasive that almost every website you visit uses one, whether the site owner consciously chose one or it came bundled into their hosting.

The core trick

A CDN takes the static parts of a website — the HTML pages, images, JavaScript files, CSS, fonts, and videos — and copies them to servers in dozens or hundreds of locations around the world. Each location is called a point of presence, or PoP. Instead of every visitor's request travelling to the one "real" server in Atlanta or Frankfurt, it goes to the PoP nearest to them.

A visitor in Mumbai reaches a PoP in Singapore or Mumbai itself — a few milliseconds away, not thousands. A visitor in Lagos reaches a PoP in Johannesburg or Lagos. A visitor in São Paulo reaches a PoP in São Paulo. The page loads fast because the data didn't travel far.

The origin server — the actual server where the site lives — mostly handles dynamic requests: logins, personalised feeds, checkout flows, anything that changes per user or per moment. The CDN handles everything that's the same for everyone. For a typical content site, that's the majority of the bytes sent.

How requests reach the right PoP

The routing happens at the DNS layer, which is why looking up a website's IP often tells you more about its CDN than its actual location. When your browser looks up cnn.com, the request goes to a DNS server. If CNN's DNS is managed by a CDN, that CDN's nameserver looks at where the query is coming from — the IP address of your DNS resolver — and returns the IP address of the nearest PoP, not a central server.

Two users on opposite sides of the world asking for the same domain name get back two different IP addresses. Both answers are correct. They each point to a different edge location serving identical cached content. This is why, as we noted in the guide to finding a website's IP address, looking up cnn.com or twitter.com returns a CDN edge address rather than the actual origin — the IP you find is determined partly by where you're asking from.

The mechanics of how that DNS resolution works — what A records and CNAME records are doing — are covered in the DNS record types explainer.

Who runs the major CDNs

A handful of companies operate the networks that carry most of the web's traffic. The names you'll encounter most often:

• Cloudflare — the most widely deployed CDN by site count, with a network spanning over 300 cities. As of recent measurements, Cloudflare sits in front of roughly one in five websites on the internet. When Cloudflare has an outage, large swaths of the web go offline with it — a fact that's been demonstrated several times in public incidents.
• Akamai — one of the oldest CDNs, founded in 1998. Dominant in enterprise and media, particularly for high-stakes delivery like live video and financial services.
• Fastly — popular with media companies and developer tools for its configurability and very fast cache-clearing ("purge") capability.
• Amazon CloudFront — Amazon's CDN, tightly integrated with the rest of AWS infrastructure. Widely used by companies already in the AWS ecosystem.
• Google Cloud CDN and Azure CDN — similar positions within their respective cloud ecosystems.

These companies collectively handle a majority of internet traffic, which creates its own set of concerns we'll get to shortly.

What CDNs do beyond caching

Modern CDNs have expanded well beyond serving static files quickly. For most websites using one, the performance improvement is just the entry point. The more consequential value is often elsewhere.

DDoS protection. A distributed denial-of-service attack tries to overwhelm your server with so many requests that it can't respond to legitimate ones. Because a CDN sits between the public internet and your origin server, it can absorb enormous amounts of bad traffic at the edge — spread across hundreds of PoPs with far more bandwidth capacity than any single server. The attack traffic gets filtered or rate-limited before it ever reaches the actual application.

TLS termination. When a visitor connects to your site over HTTPS, the TLS handshake and encryption happen at the CDN's edge, not at your origin server. This means the CDN manages SSL certificates for you, handles the computationally expensive encryption work, and your origin can receive already-decrypted requests over a private channel. One less thing to configure, one less certificate to renew.

Image optimisation. Many CDNs automatically detect what kind of device is requesting an image — a phone with a small screen versus a large desktop monitor — and serve an appropriately sized and compressed version. A 4-megapixel photograph doesn't need to be sent in full resolution to a mobile device reading it at thumbnail size.

Bot management. CDNs see enormous amounts of traffic and can identify patterns that distinguish real human browsers from automated scanners, scrapers, and credential-stuffing bots. The signals include request timing, header patterns, and known IP reputation. Filtering at the CDN layer keeps the load off your application servers.

Web application firewall rules. A WAF inspects incoming requests for known attack patterns — SQL injection attempts, cross-site scripting payloads, path traversal strings — and blocks them before they reach your application. Running this at the CDN edge means the attack is stopped without your server ever seeing it.

The concentration problem

All of this is genuinely useful. But there's an uncomfortable side to CDN ubiquity that's worth being clear-eyed about.

When one provider sits in front of 20% of the web, it sees 20% of the web's traffic. CDNs have to be able to read your requests in order to cache responses and route intelligently — they can't do their job blind. Most of them log significant metadata about every request: source IP, URL, timestamp, user agent, response code. The privacy story is more complicated than the performance story.

There's also the failure concentration. A single large CDN experiencing an outage takes down not just one website but thousands simultaneously, across every industry and geography that depended on it. This has happened, publicly and dramatically, multiple times. The tradeoff for reliability at scale is fragility at scale — a single point of failure behind a very large fraction of the internet.

None of this means CDNs are a bad idea. They provide real value. It's just worth understanding the actual architecture of what you're using.

How to tell if a site uses a CDN

The fastest way is a DNS lookup followed by an ASN check. Look up the site's IP address, then look up who owns that IP block. CDN providers own recognisable ASNs: AS13335 is Cloudflare, AS16509 is Amazon AWS (CloudFront), AS54113 is Fastly, AS20940 is Akamai. If the IP you find belongs to one of those ASNs, the site is running behind that CDN.

The ASN explainer covers how those numbers work and how they map to organisations. In practice, the ASN field in any IP lookup result is often the quickest way to identify the underlying infrastructure — CDN, cloud provider, or otherwise.

You can also check HTTP response headers. CDNs typically add headers that identify themselves: Cloudflare adds cf-ray, Fastly adds x-served-by, and so on. If you inspect the headers on any large site, you'll usually see one of these fingerprints.

When you don't need one

CDNs are almost universal for sites with any real traffic or geographic reach, but they're not universally necessary. A personal blog, an internal company tool, or a small regional service may have no meaningful benefit from CDN distribution. All your users are nearby, your traffic fits comfortably on one server, and the complexity and third-party dependency aren't worth the marginal gain.

There are also cases where CDNs make architecture harder: sites with heavily personalised content (where caching doesn't help much because every response is different), strict data residency requirements (where you can't send requests through a CDN operating in multiple jurisdictions), or situations where adding a third party to the request path introduces compliance concerns.

For everything else — anything public-facing, anything with users across multiple regions, anything that would be embarrassed to go offline during a traffic spike — a CDN is one of the higher-return infrastructure decisions available.

The server is everywhere now

CDNs are one of those internet inventions that are simultaneously everywhere and invisible. Most users have never heard the term. Most websites couldn't serve a global audience without one. The reason a large site loads fast from any continent isn't magic — it's that copies of the content are physically positioned close to wherever you happen to be.

The IP you get when you look up twitter.com or github.com isn't where those companies' servers are. It's the edge node nearest to you, part of a network that exists to make geography matter less. That's the trick. Now you've seen how it works.