How CDNs Bring Websites Closer to You

Why a nearby server can answer for a distant one

A website's "real" server — its origin — usually lives in one location, or a small handful of them. Without help, every visitor worldwide would have to reach that one place, no matter how far away they are, adding the kind of distance-driven latency covered in why internet data is fast but never instant. A content delivery network (CDN) addresses this by placing copies of a site's content on servers — edge locations — spread across many cities and regions, so a visitor's request can often be answered by whichever edge location is closest, rather than the origin itself.

This matters more than it might sound. A site hosted on a single set of servers in one country can still feel fast to a visitor on another continent, precisely because that visitor's browser never has to cross that entire distance to get an answer. The CDN's network of edge locations effectively brings the site closer to everyone, all at once, without the site's owner having to build and operate servers in dozens of countries themselves.

It also reduces load on the origin itself, which is a real benefit even beyond what any individual visitor experiences. Without a CDN absorbing routine traffic, an origin server has to handle every single request from every visitor worldwide directly, which can turn an unexpected surge in popularity into an outage rather than just a busy day.

Cache hit vs. cache miss

When a request reaches a nearby edge location, one of two things happens. If that edge already has a valid, current copy of what's being requested, it's a cache hit — the edge answers directly, and the origin is never contacted at all for that request. If it doesn't, that's a cache miss: the edge fetches the content from the origin (or another edge location that has it), often caches a copy for next time, and passes the response back to the visitor. Either way, the visitor is still talking to a nearby server; the difference is only in what happens behind the scenes.

A single popular page can rack up an enormous number of cache hits from one cache miss: the first visitor to a given edge location after content changes triggers the fetch from the origin, and every subsequent visitor to that same edge location benefits from the copy it just stored — often thousands or millions of requests answered from that one fetch, depending on how popular the content is and how long it stays valid.

Freshness, revalidation, and purging

Cached content isn't kept forever. Cache-control settings, set by the website, tell edge locations how long a piece of content stays valid before it needs to be checked again — a process called revalidation, similar in spirit to how DNS records use a TTL. When content changes before its cached copy expires, sites can explicitly purge it from edge locations, forcing them to fetch a fresh copy on the next request. Getting these settings right is a balancing act: cache too aggressively and visitors might see stale content; cache too conservatively and the origin ends up handling far more traffic than necessary.

Some content also supports a middle ground called revalidation, where an edge location checks with the origin whether its cached copy is still current — often using a lightweight request that just confirms "nothing has changed" — rather than re-downloading the entire asset every time its cache lifetime expires. This keeps content reasonably fresh without giving up the bandwidth and latency savings of caching altogether.

Anycast and traffic steering

A visitor's request usually needs to reach the CDN before any of this caching logic can run, and that's often handled by anycast — the same technique introduced in how routers find a path across the internet, where many physical locations share one address and ordinary internet routing naturally sends each request toward a nearby one. It's not purely about geography, though: current network conditions, capacity at each location, and routing policy all influence which edge location actually answers a given request, alongside proximity.

Static assets, dynamic content, and the edge

Caching works best for content that's the same for every visitor — images, videos, stylesheets, scripts, and other static assets are ideal candidates, since one cached copy can serve countless requests. Content that's unique per visitor or that changes constantly is harder to cache usefully. Many CDNs now also run small pieces of application logic directly at edge locations, letting some personalization or processing happen close to the visitor even when the underlying data still needs to reach back to the origin.

A typical page load usually mixes both. The core HTML for a logged-in dashboard might come straight from the origin because it's different for every visitor, while the page's images, fonts, stylesheets, and scripts — often the bulk of a page's total size — are served from a nearby edge location because they're identical for everyone. Splitting a page this way lets a site cache aggressively where it safely can, without pretending that genuinely dynamic content can be cached the same way.

What a CDN can't fix

A CDN shortens network travel time and offloads traffic from the origin, but it can't rewrite a slow database query, compress an unnecessarily large image that was never optimized, or untangle an inefficient page that ships far more code than it needs. It also can't fully mask a slow origin for content that genuinely has to be fetched fresh every time. A CDN is one part of a fast site, not a substitute for a well-built one.

It's also worth noting a CDN can't overcome a genuinely poor path between the visitor and the nearest edge location itself. If that first stretch of network — your Wi-Fi, your ISP's link, or a congested route to the nearest edge — is the bottleneck, a CDN doesn't change any of the local or first-mile conditions covered in why Wi-Fi is only the first hop. It shortens the long-distance part of the trip, not the parts closest to you.

What this means for your connection

This site itself is delivered through Cloudflare's global network, and the speed test measures your connection against Cloudflare's own edge infrastructure — which is part of why results reflect your real connection quality rather than the distance to one single, faraway server. More broadly, when a page you visit loads quickly despite the company behind it being based somewhere else entirely, a CDN answering from nearby is very often a big part of why.

If a specific site consistently feels slower than everything else you visit, it can be worth considering whether that site relies less on a CDN — perhaps because more of its content is personalized, or because it simply hasn't been configured to cache as aggressively as it could. That's a difference in how the site is built, not a sign that your own connection is behaving inconsistently.

Taken together with the rest of this series, a CDN is a good example of how much of what makes the internet feel fast happens well before your request ever reaches its ultimate destination — nearby infrastructure quietly doing work that a distant origin server would otherwise have to handle alone.