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.
Ten readers, one origin in Northern Virginia, and ten of the places a CDN would answer them from. The arcs are real great circles, so the ones that vanish mid‑flight are genuinely going around the back of the planet. Dots travel at the same speed on both globes — distance is the only thing that changes. A real network has hundreds of these edge locations, not ten.
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, and you pay the full distance for it.
Every asset starts its life as a miss somewhere. The job of a CDN is to make sure that only happens to one unlucky person.
Illustrative timings for one asset on one route. The exact numbers move with geography and payload size; the proportions are the durable part. Roughly seven eighths of the miss is spent on the round trip the hit never makes.
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.
max-age=300
One hour of a single asset being requested continuously. The top row marks each time an edge has to go back to the origin; the bottom row is the longest a reader can be served an out-of-date copy after you publish a change.
Which means the real question is never how fast the content can be served. It's how much staleness the content can tolerate. A product photo and a pricing page have very different answers, 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.