The oldest trick for caching the uncacheable is decomposition: split the page into fragments with different lifetimes, cache each on its own terms, and assemble at the edge. Edge Side Includes standardized it two decades ago; edge compute reinvented it with better tools; the architectural judgment underneath never changed.
ESI, the original contract
ESI markup embeds include tags in a template; the edge fetches each fragment (itself cacheable with its own TTL and key) and stitches the response. A product page becomes a day-cached shell, an hour-cached price block and an uncached cart badge, and suddenly ninety percent of its bytes serve from cache despite the page being personal. Support and dialect vary by provider, classic ESI implementations differ in nesting, error handling and variable support, so treat the spec as a family, not a standard.
The compute-era version
Edge functions perform the same assembly imperatively: fetch fragments concurrently, compose with real logic, degrade gracefully when a fragment times out. The wins over classic ESI are error handling you control, parallelism you can see, and composition logic beyond inclusion, personalization decisions, A/B branching, auth-aware assembly. The costs: compute pricing per request and a codebase where your page structure now partly lives at the edge, with the deploy and observability duties that implies.
The historical arc carries a lesson about durable ideas: ESI arrived before its ecosystem, languished as a niche capability for years, and then edge compute made fragment assembly programmable and the pattern quietly won, streaming SSR at the edge, islands architectures, partial prerendering are all fragment caching wearing this decade’s clothes. Infrastructure ideas rarely die; they wait for their tooling. For architects the practical takeaway is to evaluate patterns on their arithmetic (reuse ratios, fragment costs) rather than their fashion status, because the arithmetic is what resurfaces, generation after generation, under new names.
When composition pays, and when it is theater
The math works when a heavy, popular shell wraps small dynamic islands: high shell reuse, low fragment cost. It fails when fragmentation goes granular, twenty fragment fetches per page recreates the latency you were avoiding, or when the truly dynamic part is the whole page. Measure the candidate page: what fraction of bytes is genuinely user-specific? Below a few percent, composition is compelling; above a third, cache the API and render client-side or ship the origin render.
In practice
Start with one page template and two fragments: shell plus the single most cache-hostile island. Prove the hit-ratio and TTFB delta in the field, establish fragment-timeout fallbacks (stale fragment beats blocked page), then expand template by template. Composition architectures grow well incrementally and fail well too, each fragment is a bulkhead, which is more than most performance techniques can claim.
We prototype edge composition on one of your real templates as part of performance engagements, with before/after field data.