Caching Dynamic Content
Why this matters: 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.
Key takeaway
Dynamic content changes frequently, so it cannot simply be copied and held. The strategies all share one idea: move the work, or the assembly, to the edge rather than moving the whole response from origin every time.
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.
Adaptive streaming
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.