CDNs Explained: What Happens Between Your Browser and a Website

You open a concert venue’s event page and the photo of the stage loads. Later, you sign in to download your ticket receipt from the same site. Both requests can travel through a content delivery network, but the venue has good reason to handle them differently. Every visitor can use the same photo. Each receipt belongs to one customer.

A content delivery network, or CDN, uses servers in multiple locations to deliver web content. One of its main jobs is to keep reusable copies closer to visitors, so the system that supplies the original content does less work. To see how that helps, follow the photo through three places that might supply it.

The browser, the edge, and the origin

Your browser can keep a local copy of the photo. If you go from the event listing to a page that uses the same photo, the browser may reuse its copy without making another network request. A visitor on a different device has a separate browser cache.

On your first visit, the browser usually needs to request the photo. For a site using a CDN, that request can go to a CDN location selected for your connection. These locations are called edge locations or points of presence. Serving content from them applies a principle also used in edge computing: put some of the work closer to the people who need it.

Behind the CDN is the origin, the system that supplies the content when the CDN needs it. The venue might keep its photos in a storage service and use an application to generate event pages and receipts. Those can be separate origins. The application might run on cloud computing infrastructure. If the team uses containers to package the application, that choice affects how it runs at the origin. The CDN separately decides which responses it can reuse.

Why one visitor gets a miss and another gets a hit

Suppose your request arrives at an edge location that has no copy of the photo. That is a cache miss at that location. The CDN can look for the photo in another cache in its network or ask the origin for it. If the response is eligible for caching, the edge can store it while delivering the photo to your browser.

A second visitor may reach the same edge with an empty browser cache. If the edge has a usable copy, it can serve the photo without fetching it from the origin again. That is a cache hit at the edge, even though the second visitor has never seen the photo before.

Another visitor may reach an edge that has yet to store the photo. A cache can also remove a copy early to make room for other files, an action called eviction. A freshness policy tells a cache how long it may normally reuse a response without checking it. The cache can evict the response before that time runs out.

Hits and misses are measured at a particular cache. An edge miss can still be served by a regional cache, and a browser hit can mean the CDN sees no request at all.

How a cache checks whether a copy is current

The origin can send a Cache-Control response header. For example, max-age=600 gives an eligible response a freshness lifetime of 600 seconds. That measures the age of the response, so a copy already five minutes old when it reaches your browser does not get a fresh ten-minute window. A site can use s-maxage to give shared caches a separate freshness lifetime.

When a stored copy becomes stale, the cache can often check it without downloading the whole file. If the photo came with an ETag, an identifier for that version of the response, the cache can send it back in If-None-Match. A 304 Not Modified response carries no body and tells the cache it can reuse the stored photo. If the photo changed, the request can return the new file.

A response marked no-cache can still be stored, but it needs validation before each reuse. That is useful for a page whose schedule changes and can be checked cheaply. no-store tells HTTP caches to avoid storing the response at all.

What can be shared safely?

A cache key is the information a cache uses to look up a stored response. The request URL is part of the usual lookup. Other details can matter if the same URL serves different versions. For example, an origin may send Vary: Accept-Encoding when it serves different compressed representations according to what a browser can accept. The cache needs to choose a compatible version.

A public stage photo can be shared if the site marks it as eligible. The receipt contains customer information, so the site should configure its CDN to bypass shared caching for that route and verify the customer’s authorization whenever it serves a receipt. Cache-Control: private excludes a response from shared HTTP caches while allowing a private cache to store it. For a receipt that should stay out of the browser’s HTTP cache as well, the site can send no-store.

A single site can use both policies. The public photo can come from the edge while an account request goes to the venue’s application.

Why replacing a file may leave the old one visible

Imagine the venue updates the stage photo but leaves its URL unchanged. An edge or browser may still have a fresh copy of the old response. The venue can purge the relevant CDN entries so a subsequent request through the CDN can retrieve the updated file. Copies already stored in visitors’ browsers follow their own cache rules.

A versioned filename gives each revision a distinct address. The venue can publish stage-v2.jpg and update the page to request it. Teams often put a hash of the file contents in the name so it changes when the bytes change. Each version can stay cacheable for a long time if its contents remain fixed at that URL. The page that points to the photo needs a freshness policy of its own, because an old page can keep requesting the old filename.

How to tell where an old copy came from

For a public page you maintain, open the browser’s Network panel and find the request for the file that looks wrong. Start with the request URL. If the page still asks for the previous filename, inspect the page response before investigating the image.

If the panel reports that the browser used its memory or disk cache, temporarily disable the browser cache through developer tools and reload. That helps separate browser reuse from what the CDN sends. Compare the response’s Cache-Control, any Age header, and any cache status header your provider supplies. A single request shows what happened for that visitor at that moment. To understand why visitors see different versions, compare the same URL and headers from each connection before changing the site’s policy.

The illustrations for this article were generated with AI.