CDN and HTTP caching explained

A CDN (content delivery network) is a set of servers spread around the world. It keeps copies of your content and serves them from a location near each visitor. The result is lower latency, less load on your own server and better protection during traffic spikes.

How it works

A visitor requests /logo.png. DNS or routing sends them to a nearby edge server.
If the edge has a fresh copy (a cache hit), it answers immediately.
If not (a cache miss), it asks your origin server, stores the answer and returns it.
The next visitors in that area get the cached copy.

A good setup has a high hit ratio: most requests never reach your server.

What to cache

Static files: images, CSS, JavaScript, fonts, videos. Easy and high value.
Public pages that are the same for everyone, such as articles, for a short time.
API responses that are public and change slowly.

Do not cache responses that are personal: account pages, carts, anything that depends on a cookie or login, unless you know exactly how.

The headers that control caching

Cache-Control is the main one:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted static file
Cache-Control: public, max-age=300, s-maxage=600     # public page, browser 5 min, CDN 10 min
Cache-Control: private, no-store                     # personal data, never cache

max-age: seconds a browser may reuse it. s-maxage: the same for shared caches such as a CDN.
public and private: whether shared caches may store it.
no-cache: store it but revalidate before using. no-store: do not store at all.
stale-while-revalidate: serve a stale copy while fetching a fresh one in the background.

Revalidation

When a copy has expired, the cache can ask the origin "is this still current?" using ETag or Last-Modified. If so, the origin replies 304 Not Modified with no body, which saves bandwidth.

Cache busting with fingerprints

Cache static files for a long time and put a hash in the file name (app.3f9c2a.js). When the content changes, the name changes, so users get the new file immediately and you never need to purge.

HTML pages are usually cached for a short time or revalidated, because they reference those fingerprinted files.

Cache key and Vary

The cache key decides what counts as the same request, usually the URL. Be careful with:

Query strings: ignore tracking parameters like utm_source so they do not create many copies.
Vary: Vary: Accept-Encoding stores separate copies for different encodings. A wrong or too broad Vary (such as on Cookie) can wreck the hit ratio.
Cookies: avoid setting cookies on cacheable pages, since many CDNs skip caching when a cookie is present.

Purging

When you must update something right away, use the CDN's purge by URL, tag or prefix. Plan so you rarely need it: fingerprinted assets and short HTML cache times.

Protect your origin

Allow the origin to accept traffic only from the CDN, so attackers cannot bypass it.
Use a CDN-side rate limit, bot protection and a WAF.
Enable origin shield or tiered caching if offered, to reduce origin load.
Forward the real client IP using a trusted header and trust it only from the CDN.

Mistakes that leak data

Caching a personalised page, so one user sees another user's content. This is a real and serious bug.
Caching error pages for too long.
Caching responses that depend on an Authorization header.
Forgetting private on user-specific API responses.

Always test with two different accounts and check the Cache-Control and the CDN's cache status header (often CF-Cache-Status, X-Cache or Age).

Quick check

curl -sI https://example.com/logo.png | grep -i -E "cache|age|etag"

Takeaway: put a CDN in front, cache static files for a long time with fingerprinted names, give public pages a short cache, never cache personal responses, lock the origin to the CDN and always verify with real requests.

Networking & Cloud series, Part 1 (how the internet works): 5 of 5. Previous: Load balancers explained: Layer 4 vs Layer 7 and health checks.

CDN and HTTP caching: make your site fast and cheaper to run