What a CDN Is: Why It Speeds Up Sites Worldwide

Your site loads in 200ms here in Sao Paulo. You demo it to the boss, everyone claps, you ship on Friday. Monday morning an email lands from a customer in Lisbon complaining the page takes "about five seconds to open." You run the test again, 200ms, and stare at the screen like it owes you money. The problem isn't your code: it's the physical distance between your server and your user, and no amount of JavaScript micro-optimization will fix it. A CDN will.

This article explains what a CDN is, why it speeds up sites all over the world, and where it actually helps (and where it does nothing at all).

What a CDN is

CDN stands for Content Delivery Network. In practice it's a set of servers spread out geographically across the world - called edge servers or points of presence (PoPs) - that hold copies of your site's content close to where your users are.

Without a CDN, every visitor fetches content directly from your origin server: that single machine sitting in a data center somewhere specific. If the origin is in Virginia and the visitor is in Tokyo, every file travels half the planet and back. With a CDN, the Tokyo visitor pulls the file from an edge in Tokyo and the Lisbon visitor pulls from an edge in Lisbon. The origin only gets consulted when the edge doesn't have that copy yet.

The whole idea revolves around one word: cache. The edge caches content and serves copies. The more it can serve from its own cache, the less work the origin does and the faster the user gets a response.

Why it speeds things up: latency and physics

The number one reason a CDN speeds everything up isn't magic - it's physics. Information travels through fiber optic cables at a fraction of the speed of light, and even so, the speed of light has a ceiling. A single round trip (a packet going there and back) between Brazil and Europe costs tens of milliseconds on its own. Add the TLS handshake, which demands more round trips before a single useful byte is transmitted, and you've burned hundreds of milliseconds on negotiation alone.

A CDN attacks that problem in three ways:

• It shortens the distance: the edge sits near the user, so each round trip costs a few milliseconds instead of tens.
• It terminates TLS at the edge: the encrypted handshake happens on the nearby server, not on the origin across the world. Less latency per connection.
• It reduces round trips to the origin: cached content never touches the origin at all, eliminating the most expensive trip entirely.

Distance matters. No amount of lean code makes up for 12,000 kilometers of fiber. That's why moving content closer to the user is usually the single best price-to-performance optimization that exists.

Cache hit, cache miss and origin pull

When a user requests a file, the edge has two possible answers. If it already holds a valid copy in cache, that's a cache hit: it responds immediately, never bothering the origin. If it doesn't, that's a cache miss: the edge does an origin pull, fetching the file from your origin server, storing a copy, and only then handing it to the user.

Most CDNs tell you exactly what happened via a response header. On Cloudflare, for example:

cf-cache-status: HIT

HIT means it came from the edge cache. MISS means the edge had to go to the origin. EXPIRED means it had a copy but the TTL (time to live, the cache's lifespan) had already run out. Tracking that hit/miss ratio is the most direct way to know whether your CDN is actually working or just passing messages along.

The goal is simple: maximize hits, minimize misses. A well-configured site serves the overwhelming majority of asset requests straight from the edge, and the origin only breathes when something genuinely changes.

What to cache (and what to handle with care)

Not everything should go into cache the same way.

Static assets are the easy, mandatory case: images, CSS, JavaScript, fonts, videos. They don't change between one user and the next, so the edge can hold them for a long time without risk. For these, the advice is to be aggressive:

Cache-Control: public, max-age=31536000, immutable

This tells the edge (and the browser) to keep the file for a year and treat it as immutable. "But what about when I update the file?" - that's where the version in the filename comes in: app.4f2a9c.js. When the content changes, the hash changes, the URL changes, and the old cache simply stops being requested. You never invalidate anything; you just publish a new URL.

HTML and dynamic content require care. A store's homepage can be cached for a few seconds or minutes with a short TTL. But the user's shopping cart, the logged-in dashboard, anything personalized - that cannot go into the shared cache, or user A ends up seeing user B's data. For those cases use Cache-Control: private or no-store.

Cache-Control, ETag and that pesky invalidation

The browser and the edge decide what to do with a copy based on two main mechanisms. Cache-Control defines how long the copy is considered fresh. The ETag is a fingerprint of the content: when the TTL expires, the client can ask "is it still this version?" by sending the ETag, and the server answers 304 Not Modified if nothing changed - saving the transfer of the entire file.

There's a classic joke that there are only two hard things in computer science: cache invalidation and naming things. The first half is literal. Invalidating cache - making the edge forget an old copy and fetch the new one - is genuinely annoying, because you never quite know which edges around the world have already propagated the change. That's why I prefer to avoid invalidation whenever possible: versioning asset URLs and marking them immutable turns the invalidation problem into the non-problem of publishing new URLs. When invalidation is unavoidable (an HTML that changed, say), use the CDN's purge - the command that forces the edges to drop the cached copy.

When you debug CDN caching you'll run into 304 Not Modified, 200, 404 coming from the origin and friends; checking the exact meaning of each helps you tell whether the response came from the edge or the origin - the HTTP status codes reference settles that question fast.

A CDN is more than speed

It's worth undoing the idea that a CDN only makes sites fast. Since all traffic passes through the edge before reaching the origin, the CDN becomes a layer of defense and services:

• DDoS protection: the edge absorbs and filters volumetric attacks before they get anywhere near your origin.
• WAF (Web Application Firewall): rules that block injection, malicious bots and suspicious patterns at the edge.
• Managed TLS: certificates issued and renewed automatically, handshake terminated at the edge.
• Image optimization: on-the-fly conversion to WebP/AVIF, per-device resizing, compression - without touching the origin.

To understand where the CDN fits into your infrastructure as a whole - origin on public, private or hybrid cloud - it's worth reading public, private and hybrid cloud, because the CDN always sits in front of that origin, whatever it is.

When a CDN does not help

Honesty first: a CDN is no silver bullet. If the content is personalized per user and can't be cached, the edge has nothing to serve - it becomes a proxy that just forwards everything to the origin, adding a hop instead of saving one. An API that returns unique data per request, a dashboard heavy on database queries, a feed computed in real time: none of that gets faster just by having a CDN in front of it.

In those cases the bottleneck is at the origin (slow database, unoptimized query, expensive computation) and that's where you need to work. The CDN stays useful for the other reasons - TLS, WAF, DDoS protection, and caching the page's static assets - but don't expect it to magically speed up content that, by definition, can't be shared between users.

Frequently asked questions

What exactly is a CDN for?

It delivers content from a server close to the user, reducing latency and load time. Beyond speed, a modern CDN adds DDoS protection, WAF, managed TLS and image optimization. In short: it makes your site load fast everywhere and absorbs much of the traffic and attacks before they reach your server.

What's the difference between a CDN and the origin server?

The origin server is where your site actually runs and where the data lives - usually a single machine in a data center. The CDN is a network of edge servers spread around the world that hold copies of the origin's content and deliver it from points close to the user. The CDN serves cached copies; the origin is the source of truth.

What is a cache hit and a cache miss?

A cache hit happens when the edge already has the requested copy and responds without consulting the origin - fast and cheap. A cache miss happens when the edge doesn't have the copy and must fetch it from the origin (origin pull), store it, and only then deliver it. The higher the hit ratio, the better the performance and the lower the load on the origin.

How does cache invalidation work on a CDN?

There are two approaches. The preferable one is never to invalidate: you version the asset URL (e.g. app.4f2a9c.js) and mark it immutable, so a content change becomes a new URL and the old cache stops being requested. When you really must expire something (HTML, for example), use the CDN's purge, which forces the edges to drop the stored copy.

Takeaway

A CDN speeds up sites because it solves a physics problem: it brings content close to the user, shortens round trips and terminates TLS at the edge. The heart of it all is cache - maximize hits, minimize misses, and treat the origin as a last resort. For static assets, be aggressive: version the URLs, mark them immutable, cache for a year and forget the invalidation nightmare. For dynamic and personalized content, use your head: short cache where you can, private/no-store where you can't, and expect no miracle where the bottleneck is the origin. And remember a CDN delivers far more than speed - DDoS, WAF, TLS and image optimization come free at the edge.