CDN Explained: Why a Site Feels Faster From Bangalore Than Boise

Quick Answer

A CDN is a network of caching servers spread across many physical locations that store copies of your website's content close to your visitors, so a request gets answered by a nearby server instead of crossing oceans to reach a single origin. It doesn't make your server faster — it makes the distance shorter. A visitor in Bangalore and one in Boise can both get fast first-byte times if there's an edge server near each of them, even though the origin might sit thousands of kilometers from both.

The Real Bottleneck Is Distance, Not Your Server

When a site feels slow for a visitor far from your server, the instinct is to blame the server: upgrade the hosting plan, add more RAM, optimize the database query. Sometimes that is the right fix. But a huge chunk of "slow" has nothing to do with your code and everything to do with physics: a signal traveling through fiber-optic cable takes a fixed minimum amount of time to cover a given distance, and no amount of clever code changes that floor.

Here is the actual math, not a rounded-off rule of thumb. The great-circle distance between Bangalore and Boise, Idaho works out to about 13,569 km. Light in a vacuum moves at just under 300,000 km/s, but light traveling inside glass fiber is slower — the fiber's refractive index (around 1.5 for typical telecom fiber) slows it to roughly 200,000 km/s. Dividing distance by speed gives a theoretical one-way latency floor of about 68 milliseconds, or 136 milliseconds round trip, assuming a perfectly straight cable with zero switching delay and zero protocol overhead.

That number is a lower bound, not a real observed measurement for that specific route — actual undersea and terrestrial cable paths are never straight lines, and every router hop along the way adds queuing and processing delay on top. So 136ms is the best case a request between those two cities could ever hope for, and real-world numbers run higher. Compare that to a request served from an edge server 200 km away: the physics floor drops to roughly 2 milliseconds round trip. A full page load typically needs several sequential round trips before the first byte of content even arrives — DNS resolution, a TCP handshake, a TLS handshake, then the actual HTTP request — so a per-round-trip difference of over 100 milliseconds compounds into a very noticeable stall before anything renders.

Bandwidth is a red herring for this particular problem. A gigabit connection does not shrink propagation delay by a single millisecond — it only lets more bytes arrive per second once bytes start arriving. That is why throwing a bigger server or a fatter pipe at a geographically distant visitor does nothing: the server was never the bottleneck. The distance was.

What a CDN Actually Is: Caches Standing In Front of Your Origin

A CDN (content delivery network) is a set of servers, operated by a provider like Cloudflare, Akamai, Fastly, AWS CloudFront, or Bunny, spread across many physical data centers worldwide. Your own server — the one that actually holds your application and database — is called the origin. The CDN sits between visitors and your origin, holding cached copies of your content at each of its locations, called edge servers or points of presence (PoPs).

Once you put a site behind a CDN, your domain's DNS record no longer points at your origin's IP address. It points at an IP address owned by the CDN. Depending on which edge location answers a given visitor, the exact same hostname can resolve to a physically different machine, with no application code involved in that decision at all.

This is not theoretical. Here is a real response captured with curl against a live Cloudflare-fronted site:

$ curl -sD - -o /dev/null https://www.cloudflare.com

HTTP/1.1 200 OK
CF-Ray: a3fadd355c1ffc34-DEL
CF-Cache-Status: HIT
Age: 3
Cache-Control: max-age=10
Server: cloudflare

The CF-Ray header ends in -DEL. Cloudflare appends the IATA airport code of the data center that actually served the request — DEL is Delhi. That single header line is direct, observable proof that "the same URL" was answered by a specific physical machine chosen for its proximity to wherever that request originated, not by the one server the domain owner actually manages.

Most large sites you visit daily already sit behind a CDN, whether or not you've ever noticed a difference. It is one of the few pieces of infrastructure that gets more valuable the more geographically spread out your audience is.

How One IP Address Can 'Be' Hundreds of Servers: Anycast

The mechanism that makes "nearest edge server, automatically" work without any geolocation lookup or client-side logic is called anycast. In a normal (unicast) setup, one IP address belongs to exactly one physical machine, anywhere in the world. In an anycast setup, the same IP address is simultaneously announced from dozens or hundreds of physical locations, using the internet's normal routing protocol, BGP (Border Gateway Protocol).

Routers across the internet don't know or care that an anycast address is duplicated in many places — they just do what BGP routers always do: pick the shortest, cheapest available path toward that address, based on standard path-selection rules (fewest network hops, lowest configured cost, and so on). Because a visitor in Mumbai and a visitor in Toronto are, topologically, closest to different physical announcements of that same IP, their packets naturally arrive at different servers — without a single line of DNS geo-steering logic, redirect, or client-side configuration involved. The internet's own routing tables solve the "nearest copy" problem the same way they solve every other packet-delivery problem.

Anycast also buys resilience almost as a side effect. If one data center goes dark, its routers simply stop announcing that IP address via BGP. Traffic that used to converge there re-converges to the next-nearest surviving location within the network's normal BGP convergence time — typically seconds, not the minutes or hours a manual DNS failover would take. A CDN's speed benefit and its availability benefit come from the exact same mechanism.

What a CDN Can Cache — and What It Genuinely Cannot

CDNs are extremely good at caching content that is the same for every visitor and changes on a predictable schedule: HTML for static pages, JS and CSS bundles, images, fonts, and video. They are a poor fit, without deliberate extra engineering, for content that is personalized per user — an account dashboard, a shopping cart, anything behind a login. Caching one user's authenticated response and serving it to the next visitor who hits the same URL is not a hypothetical risk; it's a real, well-documented class of bug called cache poisoning or cross-user data leakage, usually caused by a cache key that ignores a cookie or auth header the origin actually varies its response on.

Whether a response is cacheable, and for how long, is controlled by the Cache-Control header the origin sends. Two numbers matter here: max-age (how long a cached copy is considered fresh) and, for shared caches specifically, s-maxage (a separate, CDN-specific max age that can differ from the browser's own cache lifetime). Here is a real, captured example from the same Cloudflare response used above:

Cache-Control: max-age=10
Age: 3
CF-Cache-Status: HIT

Age: 3 means this exact cached response has already been sitting at that edge location for 3 seconds. CF-Cache-Status: HIT confirms the request never touched the origin at all — it was answered entirely from cache. A MISS would mean the edge had to fetch fresh content from origin (or from a shield layer, covered next) before it could reply.

Because content does eventually need to change before its TTL naturally expires, CDNs also support explicit invalidation — a purge API call that evicts a specific URL (or, with surrogate keys/cache tags, a whole group of related URLs) immediately, rather than waiting out the TTL. A related pattern worth knowing is stale-while-revalidate: the edge serves the last-known cached copy instantly to the current visitor while quietly fetching a fresh copy in the background for the next one, trading a small amount of staleness for never making any single visitor wait on a cache refresh.

What Happens on a Cache Miss (and the Thundering Herd Problem)

A cache miss follows a simple path: the edge server checks its local cache, doesn't find a fresh copy, and asks upstream for one. "Upstream" is sometimes the origin directly, but larger CDN deployments usually insert a middle layer called an origin shield — one regional cache that every nearby edge location goes through on a miss, before that regional cache itself asks the origin.

The reason a shield exists is a specific failure mode called the thundering herd. Imagine a page goes viral the instant its cache expires, and a CDN has, say, 300 edge locations worldwide with cold caches for that URL. Without a shield, all 300 locations could each send a request to the origin within the same second — 300x the load the origin was ever sized for, arriving all at once, for a page that was working perfectly fine a moment earlier. A shield collapses that into one request per shielded region instead of one per edge, so the origin only ever sees a small, bounded number of requests even when every edge misses simultaneously.

A related, complementary technique is request coalescing (also called request collapsing): if many concurrent visitors hit the same edge server for the same not-yet-cached URL at the same instant, a well-built CDN holds all but the first request, waits for that first one to come back from upstream, then serves the identical response to every request that was waiting — instead of firing N identical requests upstream for what is, from the origin's point of view, the same question asked N times in the same second.

This combination — shielding plus coalescing — is exactly what makes flash sales, product launches, and sudden traffic spikes survivable behind a CDN, and a genuine cliff-edge risk for a site that only has a single origin server standing alone.

What This Looks Like on the Wire

Rather than trusting a benchmark number in a blog post, here is a real timing breakdown, measured from wherever this was actually written (not from Bangalore or Boise specifically — this is one vantage point, not a controlled geographic comparison), using curl's built-in timing variables:

$ curl -s -o /dev/null -w "dns_lookup: %{time_namelookup}s\ntcp_connect: %{time_connect}s\ntls_handshake: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://www.cloudflare.com

dns_lookup: 0.004557s
tcp_connect: 0.031917s
tls_handshake: 0.050689s
ttfb: 0.338023s
total: 0.492688s

The tcp_connect figure — about 32 milliseconds — is a rough proxy for the round-trip time to whichever anycast edge location happened to answer this connection. That is a small number, consistent with an edge server that is genuinely nearby, and it would look similarly small from almost any location with reasonable connectivity, because that is the entire point of anycast: it routes each visitor to a nearby copy, not to one fixed, possibly-distant server. Compare that to the theoretical 136-millisecond round-trip floor computed earlier for a request that had to cross an actual ocean and continent to reach a single non-CDN origin — over four times higher, before a single byte of the actual page is even considered.

The most convincing version of this isn't a number in an article — it's the same command run against your own domain and, separately, against a plain non-CDN'd origin (a small VPS with no CDN in front of it works fine for the comparison). Run curl -s -o /dev/null -w with the format string above against both and look at the tcp_connect and ttfb lines yourself.

Frequently Asked Questions