The page you loaded probably came from a building a few miles away

Everything here earned its place by changing an outcome. Nothing about content delivery networks is included to round the number up.

Origin and edge are different places

The origin is the server that actually generates a site's content, and it may sit in a single data centre anywhere in the world. Edge servers are copies of that content placed in many locations, chosen to be close to concentrations of users. When a request arrives at an edge server that already holds the file, it is answered immediately without contacting the origin.

This removes the long round trip to the origin, which is usually the largest single delay in loading a page. It also protects the origin from load, because a popular file is fetched once per edge rather than once per visitor.

Getting sent to a nearby copy

Two mechanisms dominate: returning a different address depending on where the request came from, or advertising one address from many locations. The second approach lets ordinary internet routing deliver each request to whichever location is closest in network terms.

The short version: network distance and geographic distance are not the same thing, so the nearest server is occasionally in a surprising place. Providers measure real performance continuously and adjust which locations serve which regions when a path degrades. None of this is visible from the address bar, which shows the site's name regardless of which machine actually answered.

What can be cached and what cannot

Images, scripts, stylesheets and video segments are identical for every visitor, so a single stored copy serves everybody. A page showing your account details is unique to you and cannot be stored at an edge and handed to the next person.

Sites therefore split content, delivering a cacheable shell quickly and filling in personalised parts through separate requests afterwards. Some edges also run code themselves, assembling a personalised response near the user rather than fetching it from far away. Deciding what is safe to cache is a security question as much as a performance one, and mistakes leak data between users.

Expiry is a promise, not a detection

A cached copy carries instructions saying how long it may be reused before the edge must check with the origin again. Nothing tells the edge that content changed; the copy simply continues being served until its stated lifetime runs out. This is why an updated page sometimes appears for some visitors and not others for a while after publishing.

Operators handle it by giving files names that change whenever their contents change, so a new name means a guaranteed fresh fetch. The alternative is an explicit purge instruction, which has to propagate to every location and takes a little time to complete.

Concentration is the hidden cost

A small number of operators now serve a very large share of web traffic, which makes their faults unusually visible. A configuration error at one provider can make many unrelated sites unreachable simultaneously, even though each site is running perfectly. Because the failure is at the delivery layer, the affected sites often cannot publish an explanation on their own pages.

At the protocol level, this concentration also places one company in a position to observe traffic to an enormous number of destinations. Traffic is normally encrypted between visitor and edge, but the edge itself holds the keys, so it sees the content in the clear.

Implementations differ, and vendors are not obliged to document the differences.

What you notice as a user

Content served from a nearby edge feels instant, while anything requiring the origin has a noticeably different response time. Sites sometimes serve different content by region, which is a deliberate configuration at the edge rather than an accident of routing.

Interstitial checks asking whether you are human are frequently generated by the delivery provider rather than the site you are visiting. Using a distant network path can send you to an edge far from your actual location, which slows things down noticeably. When a page loads quickly but its interactive parts lag, you are usually seeing cached assets arriving ahead of live requests.

Everything above, in order of what to do first

1. Origin and edge are different places. The origin is the server that actually generates a site's content, and it may sit in a single data centre anywhere in the world.
2. Getting sent to a nearby copy. Two mechanisms dominate: returning a different address depending on where the request came from, or advertising one address from many locations.
3. What can be cached and what cannot. Images, scripts, stylesheets and video segments are identical for every visitor, so a single stored copy serves everybody.
4. Expiry is a promise, not a detection. A cached copy carries instructions saying how long it may be reused before the edge must check with the origin again.
5. Concentration is the hidden cost. A small number of operators now serve a very large share of web traffic, which makes their faults unusually visible.
6. What you notice as a user. Content served from a nearby edge feels instant, while anything requiring the origin has a noticeably different response time.

The takeaway

The web feels fast because most of it was copied closer to you in advance.

Understanding the failure mode tells you more than the feature list does.