A content delivery network places a delivery layer between visitors and your origin. For responses that can be reused safely, an edge cache can answer without fetching the same content from the application again. The useful question is not simply whether you need a CDN. It is which requests should take which path.

Start with the origin

The origin is the source of a response: an application server, storage bucket, or another upstream service. Without an edge cache, repeated requests for the same public image may all travel to that source. For a distant audience, that can add network time and origin load.

A CDN provides distributed endpoints that can terminate client connections and deliver content. Routing chooses a serving location based on network and provider policy; it is not guaranteed to be the geographically closest site.

Follow a hit and a miss

The edge receives the request and applies its access and cache rules. A usable stored response can be served as a hit. Otherwise, the edge may fetch or revalidate through the configured upstream path. An optional shield adds another cache layer before the origin.

A miss is normal when content is new or not stored at that location. It is also why origin health still matters. A CDN does not make an application independent of its source.

How it works

The edge decides whether the origin is needed

  1. 01BrowserRequests a resource using the public hostname.
  2. 02Edge cacheChecks access rules, freshness, and the cache key.
  3. 03OriginSupplies content when the edge cannot reuse a response.
Simplified delivery path. A cache hit returns from the edge; an eligible miss continues upstream and may fill the cache.

Decide what can be shared

A public image and a shopping cart may live on the same hostname but require different policies. Reuse depends on whether two requests are allowed to receive the same representation, not on whether the URL ends in a file extension.

Start with an inventory of content classes. Set explicit cache lifetimes for public content, preserve the dimensions that affect the response, and bypass user-specific paths.

A starting point for cache policy
ContentTypical approachCheck before enabling
Hashed CSS or JavaScriptLong-lived immutable cacheThe path changes when bytes change
Public product imagesShared cache with update policyVariants and invalidation are correct
Anonymous HTMLShort shared TTL where safeCookies and personalization cannot leak
Account or checkoutBypass shared cacheSession boundaries remain intact

Keep delivery and DNS distinct

DNS provides the address a client uses to connect. The CDN handles requests after that connection reaches its endpoint. Many deployments use DNS records to point a hostname at a CDN, but DNS and HTTP caching have separate lifetimes and failure modes.

Prepare TLS and origin connectivity before changing the public hostname. Validate on a test hostname first, and keep a rollback path that accounts for existing DNS caches.

Measure the behavior you wanted

Test a confirmed hit, a confirmed miss, and an explicitly uncached request. Verify that the origin receives only the expected fetches and that an update reaches the browser after the intended invalidation or expiry.

Run regional browser tests and monitor real users. A smaller TTFB can help rendering begin sooner, but image loading, scripts, and layout still determine when the page becomes useful.

  • Check session isolation with two separate test accounts.
  • Confirm certificates and HTTPS on both client and origin connections.
  • Test error and stale-content behavior deliberately.
  • Record cache status with latency rather than reporting one blended average.

Sources & further reading