A CDN doesn't make your server faster. It shortens the distance to it, then works hard to avoid making the trip at all.
Your origin server lives in one region. Your readers don't. Every request they make has to physically cross the network to wherever you deployed and come back, and no amount of server tuning shortens that trip.
A CDN's answer is unglamorous: put copies of your content in a lot of places, so the trip most people make is short.
Nothing in the request picks which copy to use. That happens before your code is involved — either DNS hands back a different address depending on where the lookup came from, or the same address is announced from every location at once and the internet's own routing delivers you to whichever one is closest.
Both globes show the same ten readers. On the left, every request travels to a single origin in Northern Virginia. On the right, a nearby edge server answers instead. The dots move at the same speed on both globes — nothing on the right is faster, the trips are just shorter. Arcs that run far enough disappear behind the globe; spin it to follow one. Ten edges keeps the picture readable — a real network has hundreds.
An edge server is only useful if it already holds what you asked for. When it does, it answers on the spot — a hit. When it doesn't, it forwards your request to the origin, waits for the response, keeps a copy on the way back, and hands it to you. That's a miss.
A miss is not a penalty for using a CDN. The edge sits roughly on the path your request would have taken anyway, so a miss lands about where a request with no CDN in front of it would have landed. What it buys you is that it only has to happen once at each edge: the copy left behind is what every later reader of that edge gets instantly.
Not everything is a candidate. A logo, a stylesheet, a product photo — the same bytes for everyone — can sit at an edge for months. A page carrying someone's name and cart total can't be handed to the next reader at all, and comes from the origin every time. Most of the work of putting a site behind a CDN is deciding which of your paths is which.
Illustrative timings for one asset on one route — a reader in Accra, an origin in Northern Virginia, an edge in Lagos. The first request costs about eight milliseconds more than having no CDN at all. Every request after it costs a seventh. The exact numbers move with geography and payload size; that ratio is the durable part.
Whether a request hits or misses isn't luck. It's a header. Cache-Control: max-age tells every edge how many seconds it may keep serving its copy before it has to check with the origin again.
That single number is a trade. Set it low and your content is always current, but the edges keep phoning home. Set it high and the origin barely gets touched, but there's now a window in which someone can be served something you already changed.
Phoning home is cheaper than it sounds. The edge asks with its copy's fingerprint attached, and if nothing has changed the origin answers 304 Not Modified — a round trip, but no bytes. Over an hour of a file you published once, every check but one costs a header exchange and nothing more.
max-age=300
One hour of a single asset being requested continuously. The top row marks every time an edge checks with the origin — only the check after you publish downloads anything; the rest are revalidations that come back empty. The bottom row is the window in which readers are still handed the old copy, drawn at its worst case: you published just after a check.
Which means the real question is never how fast the content can be served. It's how much staleness each path can tolerate — which is why cache rules get written per path rather than per site, and why anything that truly never changes gets a fingerprinted filename and a lifetime measured in months. Change the file, change its name, and there is no stale window left to reason about.