Caching Dynamic Content
In one line: the easy half of a CDN is static files. The interesting half is everything personalized, computed, or freshly generated — and the techniques here are why modern CDNs are compute platforms rather than file servers.
Three optimization strategies
Edge scripting
Scripts run on proxy servers instead of the origin, generating content based on parameters such as user location, time of day, or third-party APIs (a weather lookup, for example).
The response is genuinely dynamic yet never crosses the network to origin. This is the idea behind modern edge-compute products, and it converts a latency problem into a placement problem for computation rather than data.
Compression
Tools such as Cloudflare's Railgun compress dynamic content to reduce bandwidth usage between the origin and proxy servers.
Note where the saving is: the origin-to-proxy leg, not proxy-to-client. Dynamic content must be fetched from origin on change, so shrinking that hop is what pays — especially since the same fetch happens for many edges.
Edge Side Includes (ESI)
A markup language that defines which parts of a web page are dynamic. The CDN assembles the final response by combining cached static assets with dynamic fragments retrieved from the origin.
Although ESI is not a W3C standard, it is widely used to avoid re-fetching entire pages when only small fragments change.
Why ESI is the highest-leverage of the three
A typical page is mostly static — header, navigation, layout, footer, images — with a small personalized region: a username, a cart count, a recommendation strip.
Without ESI the whole page is dynamic, because one dynamic byte poisons it, and nothing caches. With ESI the 95% that is stable is served from edge cache and only the 5% is fetched.
This is the same insight as the flash-crowd degradation strategy from that building block, running the other way: there, dropping personalization made a page cacheable; here, isolating personalization makes the rest of it cacheable without dropping anything.
Adaptive streaming
DASH and video quality
Dynamic Adaptive Streaming over HTTP (DASH) uses a manifest file with URIs for different video resolutions, allowing the client to fetch the appropriate quality based on network conditions. Netflix uses a proprietary version of DASH for optimization.
The CDN-relevant part: each resolution is a separate, static, cacheable object. Adaptive streaming turns "one video, variable quality" into "many fixed files plus a small manifest" — which is precisely what a CDN is good at. The adaptation happens in the client, not the network.
Choosing among them
| Situation | Technique | Why |
|---|---|---|
| Response depends on location, time, or a third-party API | Edge scripting | Compute it at the edge; origin is never involved |
| Mostly-static page with small personalized regions | ESI | Cache the shell, fetch only the fragment |
| Genuinely dynamic content that must come from origin | Compression | Can't avoid the fetch, so shrink it |
| Video at varying network quality | DASH / HLS | Each resolution becomes a cacheable static object |
Key takeaway
Dynamic does not mean uncacheable. Decompose the response: cache what is stable, compute at the edge what depends only on the request, and fetch from origin only what genuinely requires authoritative state.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "Dynamic content can't be cached, so it goes to origin." |
| L5 | Knows the techniques: "edge scripting for location-based responses, and ESI so the static shell caches even though part of the page is personalized." |
| Staff+ | Decomposes the response and bounds it: "most of the page is stable, so ESI lets 95% cache and only the personalized fragment fetches. But I'd keep anything needing authoritative state at origin — an edge with stale inventory gives fast wrong answers." |
Next: what happens when the edge doesn't have it either.