What Is CDN?

How a CDN Works

Without a CDN, every request for a page hits a single origin server, no matter where the visitor is. Someone in Tokyo loading a site hosted in Virginia pays for every round trip across the Pacific. A CDN removes that distance tax by replicating the site’s content across a network of servers around the world and routing each user to the nearest one. As web.dev defines it, a CDN is “a network of servers that are optimized for quickly delivering content to users.”

web.dev breaks the speed benefit into three mechanisms. First, the servers serving a user are simply closer than the origin, shortening the physical round-trip. Second, the CDN’s own network is tuned for fast delivery, often using pre-warmed persistent connections to the origin so it avoids paying connection-setup costs on each request. Third, and most importantly, caching means many requests are answered at the edge and never reach the origin at all. The combined effect is a meaningfully faster Time to First Byte, which is why web.dev calls out CDNs as a lever for Largest Contentful Paint.

Origin, Edge, and Cache Hits

A few terms make the architecture concrete. The origin server is the machine the CDN retrieves content from — the authoritative source of truth. Points of Presence (PoPs) are the cache locations spread across the network: edge PoPs sit closest to users and serve them directly, while central PoPs handle overflow and misses. When a user’s request finds the resource already stored at the edge, that is a cache hit and the response is fast. When the edge lacks it, that is a cache miss, and the CDN fetches the resource from the origin, serves it, and stores it for the next visitor.

The metric that captures how well this is working is the Cache Hit Ratio (CHR) — the proportion of requests served from cache rather than forwarded to the origin. web.dev states plainly that “a CHR of 90% is a good goal for most sites.” A high ratio means the CDN is absorbing the traffic; a low one means requests are still stampeding to the origin and the CDN is adding little.

Example of a CDN

web.dev’s own caching guidance gives a documented rule of thumb for what to serve from a CDN and how long to cache it. Static resources — images, fonts, versioned CSS and JavaScript — should carry long time-to-live values, on the order of six months to a year, because they rarely change and benefit from staying at the edge. Dynamic content is trickier, but the guidance notes that even a very short cache window, as brief as 5 seconds, can shield an origin during a traffic spike by collapsing a flood of identical requests into a single origin fetch.

That contrast is the whole strategy in miniature. A CDN is not a single switch; it is a set of caching decisions applied per resource. Long-lived static assets ride the edge for months and push the cache hit ratio toward that 90% target, while a few seconds of caching on hot dynamic responses can be the difference between an origin that survives a surge and one that falls over. Used this way, a CDN both accelerates the median visit and hardens the site against its worst-traffic moments.

Frequently Asked Questions

The Bottom Line

A CDN moves your content to the doorstep of your audience: instead of every visitor reaching back to a single origin, they are answered by a nearby edge holding a cached copy. The result is a shorter round trip, a faster first byte, and an origin shielded from load — provided your cache hit ratio is high enough that the edge is actually doing the answering.