How Does CDN Caching Work?

CDN caching works by storing copies of your website’s content closer to your users, on servers around the world - so that when someone visits your site, they get the data from a nearby location instead of waiting for it to travel from your origin server. 

‍

Basic Principle

‍

Think of a CDN (Content Delivery Network) as a network of strategically located servers (called edge servers). When someone requests your website—say, an image or a CSS file—the CDN checks if it already has a cached copy of that file at a location near them.

‍

If yes? It serves it right away. That’s a cache hit.

‍

If no? It fetches the file from your origin server, saves a copy for the next request, and delivers it to the current user. That’s a cache miss.

‍

Once it’s cached, any user who asks for that same file within the cache’s lifespan will get it instantly from the edge—no round trips to the origin server. That’s the magic.

‍

What Gets Cached (and What Doesn't)

‍

Not everything is automatically cached. Static assets are the main target:

‍

• Images (.jpg, .png, .webp)
• Stylesheets (.css)
• Scripts (.js)
• Fonts (.woff, .woff2)
• Media (.mp4, .webm, etc.)

‍

Most CDNs won’t cache HTML pages or APIs by default, because these often change per user or per session. But that’s where CDN dynamic content caching comes into play—I'll get to that.

‍

What gets cached is determined by:

‍

• File type and extensions
• Response headers (Cache-Control, Expires, etc.)
• Custom rules you set inside your CDN config

‍

Cache-Control

‍

CDNs don’t just guess how long they should cache something. They follow instructions, mostly from the Cache-Control header that your origin server sets.

‍

Here’s the anatomy of it:

‍

• Cache-Control: public, max-age=86400
  → Cache this for 24 hours (86400 seconds) for everyone.
• Cache-Control: private, no-store
  → Don’t cache this; it’s user-specific (like a dashboard or profile).
• Cache-Control: s-maxage=3600
  → Special directive for shared caches (like CDNs); cache for 1 hour.

‍

You can also use Expires, but most modern CDNs favor Cache-Control. If neither is present, some CDNs apply default behaviors (e.g., cache static files for a few minutes or hours).

‍

I always explicitly set Cache-Control—never assume the default behavior will be optimal. That’s step one to building a CDN with best caching strategies.

‍

Caching Algorithms and their Purpose

‍

What if the CDN runs out of space? How does it choose what to keep and what to evict?

‍

That’s where CDN caching algorithms come in. Most CDNs use variants of classic algorithms:

‍

• LRU (Least Recently Used): Oldest unused content gets kicked out first. It’s simple and effective.
• LFU (Least Frequently Used): Rarely requested content gets evicted before popular content.
• Hybrid: Some CDNs use a smart mix, factoring in file size, request frequency, and recency.

‍

You don’t control this directly (unless you build your own CDN), but understanding it helps. If your asset isn’t being accessed frequently, don’t expect it to stick around forever at the edge. 

‍

CDNs optimize for hit rate vs. storage.

‍

The Fingerprint of a Request

‍

This part trips people up. Even if the URL looks the same, the cache key might not be.

‍

A cache key is how the CDN decides if a cached version exists. By default, it might look at:

‍

• The URL
• Query parameters
• Cookies
• Headers

‍

For example:

/image.jpg?v=1  → different cache key from /image.jpg?v=2

‍

Some CDNs (like Cloudflare, Fastly, Akamai) let you customize the cache key. You can ignore query strings, normalize headers, strip cookies, etc.

‍

Small differences can lead to cache fragmentation and lots of unnecessary origin hits.

‍

Dynamic Content and Edge Logic

‍

Here’s where it gets interesting; CDN dynamic content caching is no longer just about static files.

‍

If you want to cache personalized or dynamic pages (like product listings or even HTML), you’ve got two main tools:

‍

• Edge Side Includes (ESI): A way to cache parts of the page (e.g., product list cached, cart widget dynamic).
• Custom logic at the edge: With CDNs like Fastly, Cloudflare Workers, or Akamai EdgeWorkers, you can write logic to decide:
  
  • When to serve from cache
  • When to bypass it
  • How to cache authenticated pages without exposing private data

‍

Example: I once cached category pages for logged-in users only if no cart or pricing info was shown. That’s caching dynamic content safely—a key part of a modern CDN caching strategy.

‍

Invalidate, Purge, and Stale Content

‍

What happens when you update content?

‍

You have to deal with:

‍

• Purge: Explicitly clear cached content via API or dashboard.
• Soft purge / Invalidate: Mark content as stale, but serve it until the new version is ready.
• Stale-while-revalidate: A header-based trick where the CDN serves stale content while refreshing in the background.

‍

I like stale-while-revalidate and stale-if-error. They prevent slow origin responses or 500 errors from blowing up the user experience.

‍

You just need to add this to your header:

‍

Cache-Control: max-age=3600, stale-while-revalidate=300, stale-if-error=86400

‍

Advanced Caching Concepts

‍

If you’ve got the basics down and want to really dial in your caching strategy, here’s where it gets interesting.

‍

1. Request Flow Under the Hood

‍

When a user requests a file, the CDN checks:

‍

• Is it in cache?
  
  
• Is it still fresh (TTL not expired)?
  
  
• Does the request force revalidation (like Cache-Control: no-cache)?
  
  

If yes → served instantly (cache hit).

If not → origin is contacted, and response is cached (cache miss).

‍

Sometimes the CDN revalidates with your origin using ETag or Last-Modified, so the full file isn’t always fetched again.

‍

2. Time-to-Live (TTL) in Practice

‍

TTL (like max-age=3600) controls how long an object stays in cache. Once expired:

‍

• The object is revalidated or replaced
• If stale caching is enabled, stale content is served temporarily

‍

Fine-tuning TTLs is how you balance freshness vs performance.

‍

3. Tiered Caching

‍

Some CDNs use a two-layer cache system:

‍

• Tier 1: Edge servers, closest to the user
• Tier 2: Mid-tier regional caches

‍

When Tier 1 misses, it checks Tier 2 before hitting your origin. Great for global traffic distribution and origin cost savings.

‍

4. Origin Shield

‍

An optional feature (e.g., in Fastly or CloudFront) that centralizes cache misses to a single point before your origin server. It:

‍

• Reduces origin load
• Increases cache efficiency
• Simplifies debugging

‍

5. Cache Debugging Tips

‍

How do you know if caching is working?

‍

• Look for headers like x-cache: HIT or cf-cache-status: HIT
• Check the Age header to see how long the asset’s been cached
• Watch cache hit ratios in your CDN dashboard

‍

6. Things That Kill Caching

‍

These are common mistakes that destroy your cache efficiency:

‍

• Not versioning static assets (e.g., /style.css instead of /style.v2.css)
• Unnecessary query strings (especially marketing tags)
• Cookies on static resources (some CDNs bypass cache when cookies are present)
• Overly conservative headers (like Cache-Control: no-store)

‍

7. Micro-Caching

‍

Used for dynamic pages. Cache responses for just a few seconds (e.g., 5–10 seconds). It helps absorb spikes on high-traffic endpoints like homepages or product search.

‍

8. Immutable Caching

‍

If you use versioned filenames (e.g., bundle.6d7e91.js), you can safely cache those assets for a year:

‍

Cache-Control: public, max-age=31536000, immutable

‍

This tells the CDN “this file will never change, don't revalidate.”

‍

CDN Caching in the Real World

‍

Let me paint a scenario.

‍

You have a Shopify or WordPress site with a product catalog and blog. You’re using a CDN—say Cloudflare or Fastly.

‍

• Your images, CSS, JS are all cached with long max-age.
• Your product pages? HTML is cached at the edge for anonymous users (via a page rule or custom Worker).
• Your dashboard? Bypassed cache completely—Cache-Control: private, no-store.
• You set custom cache keys to strip tracking query params (?utm=...), so they don’t break your hit ratio.

‍

When a user lands on your homepage:

‍

• The edge serves all static assets instantly.
• The HTML is already cached unless it recently changed.
• The user sees a blazing fast page

‍

If something breaks? You purge that asset or path via the CDN dashboard or API. You’ve got full control.

‍