You can optimize a handler until it executes in a millisecond and still deliver a slow page.
The missing cost is often outside your code: the request must travel from the user to the server and the response must travel back.
A content delivery network reduces that distance when it can. To see why this works, we need to follow the network path before discussing cache settings.
The physical cost of distance
Internet traffic moves through fiber, copper, radio links, routers, and switches. None of them move data instantly.
Fiber routes also do not follow a perfect straight line. Cables follow geography, connect through network facilities, and may take paths chosen for policy or reliability.
Every protocol exchange pays that travel time.
Establishing a new TCP connection normally costs about one network round trip. TLS and the HTTP request can add more exchanges, depending on the protocol and whether a connection can be reused.
Faster application code cannot remove those round trips. If the server is far away, the network can dominate the response time.
The practical lever is simple: place reusable data closer to the user.
One origin, many distant users
The origin is the authoritative server or storage system behind a website.
It might be an application server, an object-storage bucket, a load balancer, or another service that can produce the original response.
Without a CDN, every user contacts that origin directly.
A nearby user may see a fast response. A distant user pays a longer route on every request, even when asking for the same logo, stylesheet, or article as everyone else.
The origin also repeats work. It sends identical bytes across long paths and handles demand that did not require fresh application logic.
A CDN sits between users and the origin as a distributed reverse proxy.
What a CDN stores
A CDN operates servers across many locations. These servers can store reusable HTTP responses and return them without contacting the origin each time.
Common candidates include images, fonts, CSS, JavaScript bundles, downloads, and pages whose content can be shared safely.
The cache does not merely map a filename to bytes. It stores a response under a cache key.
That key usually begins with the host and URL path. A CDN may also include selected query strings, headers, cookies, or other values.
Two requests match only when the values used by the cache key match. A cached response must also remain valid under the configured cache policy.
This is why “put a CDN in front” does not mean every response becomes cached. The request, response headers, cache rules, and method all influence reuse.
The next article will cover those HTTP rules. For now, remember that a CDN stores eligible responses for matching future requests.
Points of Presence and IXPs
A CDN location is commonly called a Point of Presence, or PoP. It contains network and compute resources through which nearby traffic can enter the provider's network.
“Nearby” means close in network terms, not simply inside the same country. The useful location is one with short, well-connected paths to user networks.
An Internet Exchange Point, or IXP, is infrastructure where independent networks connect and exchange traffic.
Internet service providers, mobile networks, cloud networks, and CDNs can meet at an IXP instead of sending local traffic through a distant intermediary.
CDN operators often connect to other networks at IXPs and private interconnection facilities. A PoP may be in or near such a facility, but the terms are not synonyms.
An IXP is a meeting place for networks. A CDN PoP is part of one provider's delivery network.
Together, broad geographic presence and strong interconnection shorten the path between users and cached content.
Anycast routing, intuitively
The CDN still needs to steer a user toward a suitable location.
Some CDNs use DNS-based request routing. The provider returns an address chosen from information available during DNS resolution.
Others use anycast. Multiple locations announce the same IP address through the Border Gateway Protocol, or BGP.
Internet routers then choose a route using their routing policies. In a healthy design, traffic usually enters a nearby available CDN location, though “nearest” is a network decision rather than a geographic guarantee.
Think of several stores sharing one public phone number. The phone network connects each caller to an appropriate branch without the caller choosing a branch address.
Anycast can also improve resilience. If one route is withdrawn, routing can move new traffic toward another location announcing the address.
Anycast is one CDN design, not the definition of a CDN. Providers can combine anycast, DNS steering, load balancing, and private routing.
Cache hits and cache misses
Once a request reaches the CDN, the edge cache derives a cache key and looks for a valid matching response.
If it finds one, the request is a cache hit.
The PoP returns the stored response. The user avoids a trip to the origin, and the origin performs no work for that request.
If no valid entry matches, the request is a cache miss.
The CDN forwards the request toward the origin, receives the response, and returns it to the user. If the response is cacheable, the CDN can store it for later requests.
The first request can still pay the origin distance. The benefit appears when later matching requests reuse the stored response.
Some CDNs add regional or upper-tier caches between edge PoPs and the origin.
On a local miss, the PoP may find the response in that shared tier. This can prevent many edge locations from requesting the same object from the origin.
The ratio of hits to cacheable requests matters. More useful hits generally mean less user latency, less origin traffic, and lower origin load.
When the origin is still needed
A CDN does not make the origin disappear.
The origin is needed when content is missing, stale, invalidated, uncacheable, or specific to the request.
An account page, shopping cart, or permission-dependent API response usually requires more care than a public image. Caching the wrong personalized response can expose one user's data to another.
Even when a response cannot be shared, the CDN can still act as a reverse proxy. It may terminate connections, apply security rules, compress content, or route traffic across the provider's network.
Those features can help, but they are separate from the largest caching win: answering near the user without contacting the origin.
The origin must remain correct and available for every request the cache cannot satisfy. It also controls the freshness and cacheability of its responses through HTTP semantics and CDN configuration.
The complete request path
We can now describe the flow without treating the CDN as magic:
- The browser resolves the site's hostname.
- Routing carries the connection to a suitable CDN PoP.
- The CDN constructs a cache key from the request and its policy.
- A valid match produces a cache hit and a nearby response.
- A miss moves through another cache tier or reaches the origin.
- An eligible origin response is stored for future matching requests.
The CDN improves performance by changing where repeated work happens.
The origin creates or stores the authoritative response. Distributed caches reuse it closer to the people requesting it.
Key takeaways
- Network distance creates latency that faster handler code cannot remove.
- A CDN places reusable responses in PoPs closer to users.
- IXPs connect independent networks; CDN PoPs are delivery locations operated by a provider.
- Anycast lets several locations announce one address, but not every CDN routes the same way.
- A cache hit avoids the origin; a miss fetches from another tier or the origin.
- Cache keys and freshness rules decide whether a response can be reused.
- Personalized and dynamic responses still require careful origin and cache design.
What comes next
We have deliberately treated cache policy as a black box.
The next article opens that box. It explains freshness, Cache-Control, validators, revalidation, and how to prevent shared caches from leaking private data.