HTTP Caching Fundamentals: The Foundation of CDN Performance

Why HTTP Caching Matters

HTTP caching is the single most impactful performance optimization on the web. A cached response eliminates network round-trips, reduces server load, and delivers content in milliseconds instead of seconds. Every CDN is fundamentally an HTTP cache — understanding how HTTP caching works is prerequisite to using a CDN effectively. For foundational context, read What Is a CDN? The Complete Beginner's Guide — FlyFish NWA.

Cache-Control: The Primary Header

The Cache-Control response header is the primary mechanism for controlling caching behavior. It contains directives that apply to both browser caches and CDN caches.

Key Directives

• public — Response can be cached by any cache (browser, CDN, proxy)
• private — Response can only be cached by the browser, not shared caches like CDNs
• max-age=N — Response is fresh for N seconds
• s-maxage=N — Like max-age but only for shared caches (CDNs). Overrides max-age for CDNs.
• no-cache — Cache may store the response but must revalidate before each use
• no-store — Do not cache at all. Period.
• must-revalidate — Once stale, must revalidate. Cannot serve stale content even during origin failure.
• immutable — Response will never change; skip revalidation even on user refresh

See Cache-Control Deep Dive for every directive with examples.

Conditional Requests

When a cached response expires, the cache doesn't have to fetch the full response again. It can send a conditional request to check if the content has changed:

ETag + If-None-Match

# Original response:
HTTP/1.1 200 OK
ETag: "abc123"
Cache-Control: max-age=300

# After 300s, cache revalidates:
GET /style.css HTTP/1.1
If-None-Match: "abc123"

# If unchanged:
HTTP/1.1 304 Not Modified  (no body, saving bandwidth)

# If changed:
HTTP/1.1 200 OK
ETag: "def456"
(full response body)

Last-Modified + If-Modified-Since

# Original response:
HTTP/1.1 200 OK
Last-Modified: Mon, 01 Jun 2026 10:00:00 GMT

# Revalidation:
GET /style.css HTTP/1.1
If-Modified-Since: Mon, 01 Jun 2026 10:00:00 GMT

The Vary Header

The Vary header tells caches that the response varies based on certain request headers. The cache must store separate copies for different values of those headers:

Vary: Accept-Encoding
# Cache stores separate copies for gzip, br, and identity encodings

Vary: Accept-Language
# Cache stores separate copies per language — use cautiously

Overusing Vary fragments your cache and reduces hit rates. See cache key design.

Cache Layers

An HTTP response passes through multiple cache layers:

1. Browser cache — Closest to user, governed by max-age. See browser vs CDN cache.
2. CDN edge cache — Shared cache at the nearest PoP, governed by s-maxage
3. CDN shield cache — Regional aggregation layer. See cache hierarchy.
4. Origin server — Source of truth when all caches miss

Cache Freshness Model

A cached response has three states:

• Fresh — Within max-age/s-maxage. Served immediately without contacting origin.
• Stale — Past max-age but still stored. Can be revalidated or served with stale-while-revalidate.
• Expired/Purged — Removed from cache. Next request is a full cache miss.

Common Caching Mistakes

• Using no-cache when you mean no-store (no-cache still allows caching, just forces revalidation)
• Setting max-age=0 without must-revalidate (allows stale serving)
• Forgetting Vary: Accept-Encoding when serving compressed responses
• Setting long max-age on URLs without content-hashing (unable to update)

These caching fundamentals apply universally across CDN providers and deployment scenarios. For a broader introduction to content delivery networks and their practical benefits beyond caching, see this overview of CDN technology and its six key advantages, which covers the business case for CDN adoption alongside the technical considerations explored throughout this guide.