Guide · Hosting & CDN

CDN Explained: What It Does, When You Need One, and How Caching Works

Understand how a content delivery network works, which headers control caching, what origin shield does, when a CDN helps or hurts, and how to verify it is working.

By SiteDownCheck Editorial · Updated October 5, 2026 · 7 min read

A content delivery network (CDN) is a network of servers in many locations that sits between your visitors and your origin server. It answers requests from nearby copies where it can and only comes back to your server when it must. Done right, a CDN makes pages faster, absorbs traffic spikes, and keeps parts of your site available while the origin has trouble. Done carelessly, it serves stale pages, caches things it shouldn't, or hides a broken origin behind confusing errors. This guide explains the mechanics so you can reason about both outcomes.

What a CDN does

A CDN provides several distinct functions. Not every provider offers all of them, and some are separate products.

  • Caching of static content: images, stylesheets, scripts, fonts, downloads, and sometimes full HTML pages are stored at edge locations and served from there.
  • Shorter network distance: a visitor in another continent gets bytes from a nearby edge instead of crossing oceans to your origin. This lowers latency, especially for TLS handshakes, which the edge terminates close to the visitor.
  • Connection management: the edge keeps efficient, reused connections to the origin and speaks modern protocols (HTTP/2, HTTP/3) to visitors even if your origin doesn't. Check with the HTTP/2 and HTTP/3 Checker, and see HTTP/2 and HTTP/3 explained.
  • Traffic absorption: many requests never reach the origin, so spikes hit the CDN, not your server.
  • Security features: DDoS mitigation, web application firewall rules, and bot management are commonly bundled. See DDoS basics for website owners.
  • Optional extras: image resizing, compression, and edge compute. Features and names vary by provider; check your provider's documentation.

How a request flows

Visitor -> nearest edge location
            |-- cache HIT:  respond immediately
            '-- cache MISS: fetch from origin (or an upper tier), store, respond

The first visitor in a region typically causes a miss. Later visitors for the same object get hits until it expires or is purged. The percentage of requests served from cache is the cache hit ratio, the main health number for a CDN setup.

Do you need a CDN?

A CDN is likely to help if:

  • Your visitors are spread across regions far from your origin.
  • Pages include many static assets, or large images and video.
  • You get traffic spikes (campaigns, launches, sales). See Black Friday website readiness checklist.
  • Your origin is small and gets overloaded by repeat requests for the same content.
  • You want a layer that filters abusive traffic before it reaches the server.

It may add little if:

  • Your visitors are all near your server and the site is small.
  • Almost everything is personalized or uncacheable (a logged-in application with no public pages), though connection management and security may still help.
  • The slowness is in your application or database. A CDN can't fix a slow backend for uncached requests. See reduce time to first byte and website slow diagnosis.

Measure first with the Website Speed Test and Page Weight Analyzer to see whether static assets dominate the load.

Caching headers: the instructions you give the CDN

A CDN decides what to cache and for how long mainly from HTTP response headers your origin sends, plus any rules you configure in the CDN itself.

Cache-Control

DirectiveEffect
max-age=NFresh for N seconds in any cache, including browsers
s-maxage=NFresh for N seconds in shared caches such as CDNs; overrides max-age there
publicMay be stored by shared caches
privateOnly the browser may store it, not a CDN
no-storeDo not store anywhere
no-cacheMay be stored, but must be revalidated with the origin before reuse
immutableWon't change during its freshness lifetime, so no revalidation needed
stale-while-revalidate=NMay serve stale content for N seconds while fetching a fresh copy in the background
stale-if-error=NMay serve stale content for N seconds if the origin returns errors

The last two matter for reliability. stale-if-error lets cached pages keep serving when the origin fails, but support varies by CDN and configuration, so test it rather than assuming.

Validators: ETag and Last-Modified

When a cached copy expires, the CDN can ask the origin "has this changed?" using If-None-Match or If-Modified-Since. If not, the origin replies 304 Not Modified with no body, saving bandwidth. Make sure your origin sends ETag or Last-Modified for cacheable content.

Vary

Vary: Accept-Encoding is normal. Vary: Cookie or Vary: User-Agent can split the cache into many copies or prevent caching entirely, wrecking your hit ratio.

Cookies

A response with Set-Cookie is often treated as uncacheable by default. Public pages shouldn't set cookies. Look at what your pages send with the Cookie Checker.

Example origin settings

# Fingerprinted static assets: cache for a year
location /assets/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# Public HTML: browsers revalidate, CDN holds for 5 minutes
location / {
    add_header Cache-Control "public, max-age=0, s-maxage=300, stale-while-revalidate=60";
}

Inspect what your site sends:

curl -sI https://example.com/assets/app.js | grep -iE "^(cache-control|etag|last-modified|age|vary|cf-cache-status|x-cache|via)"

Different CDNs expose hit or miss status under different header names, such as cf-cache-status on Cloudflare or x-cache on several others. The HTTP Header Checker shows these headers, and the CDN Detector identifies which CDN is serving a site. For Cloudflare specifics see Cloudflare cache rules and purge.

Versioned assets beat purging

You can't recall copies stored in visitors' browsers. So instead of replacing style.css, change the URL when content changes: style.3f9a1c.css or style.css?v=3f9a1c (the filename approach is more reliably cached). Build tools do this automatically. Then you can use very long lifetimes and never need to purge assets.

HTML is the exception, since its URL must stay stable. Keep HTML lifetimes short, and purge on publish.

Origin shield and tiered caching

Without extra layers, every edge location that misses goes to your origin. A cold cache across dozens of locations can send many near-simultaneous requests for the same object. Origin shield, also called tiered caching or a regional or mid-tier cache by various providers, adds an intermediate cache: edge locations ask the shield first, and only the shield contacts your origin. The effects:

  • Fewer origin requests and a higher effective hit ratio.
  • Request collapsing: many simultaneous misses become one origin fetch.
  • Origin protection during purges or traffic spikes.
  • Slightly more latency on a miss, since there is an extra hop.

It is worth enabling when your origin is modest or far from most edges. Naming and availability differ by provider, so check the documentation.

Failure modes to understand

  • Stale content: a changed page doesn't update because it is cached. Check age and the hit status header, then purge or shorten the TTL.
  • Cached errors: a temporary 500 or 503 gets cached and keeps being served. Check your CDN's behavior for error responses.
  • Personalized content leaked: pages with user data cached publicly. Always exclude logged-in, cart, and account paths.
  • Origin errors hidden or rewritten: the CDN shows its own error page. See fix 502 bad gateway and Cloudflare 520-526 errors explained.
  • Origin exposed: if the origin IP is public, attackers can bypass the CDN. Restrict origin firewall rules to the CDN's published address ranges.
  • Single-provider dependency: if the CDN has an outage, your site goes with it. A status page and external monitoring help you tell which side failed. See website down for everyone or just me.

Verify it is working

  1. Confirm the CDN is in the path with the CDN Detector.
  2. Request a static asset twice and see a miss then a hit.
  3. Check age increases and cache-control matches your intent.
  4. Compare time to first byte from different regions using the Website Speed Test.
  5. Review the CDN's analytics for hit ratio and origin requests.
  6. Monitor externally with the Uptime Monitor, so you see what users see, not just what your origin logs.

Next steps

FAQ

Does a CDN make my site faster for sure?

It speeds up cacheable content and long-distance connections. It cannot speed up uncached requests that depend on a slow application or database.

Can a CDN cache HTML pages?

Yes, if the origin headers or CDN rules allow it. Do it only for public pages that are identical for every visitor, and exclude anything personalized.

What is the difference between max-age and s-maxage?

max-age applies to every cache including browsers. s-maxage applies only to shared caches like CDNs and overrides max-age for them, letting you cache longer at the edge than in browsers.

Will a CDN keep my site up if my server goes down?

Only for content that is cached and still allowed to be served. Dynamic pages and uncached URLs will fail. Directives like stale-if-error can extend this, depending on your CDN.

Get notified when this guide updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.