The common belief is that CDN edge caching only works for static assets — images, CSS, JavaScript — and that dynamic HTML with personalized content must always be served from the origin. This significantly understates what modern CDN architectures can do. Edge caching for dynamic pages uses a combination of cache key segmentation, edge-side includes, stale-while-revalidate patterns, and edge compute functions to serve personalized HTML from cache while maintaining per-user relevance. The TTFB reduction is substantial: eliminating the round trip to origin (often 50-200ms) and origin server processing time (often 100-500ms) compresses TTFB to the edge-to-user network latency alone, typically 5-30ms.
Cache Key Segmentation: Serving Different Cached Versions per User Segment
Traditional CDN caching maps one URL to one cached response. Cache key segmentation extends this to map one URL to multiple cached responses, differentiated by request attributes that correlate with content variation. Rather than caching a single HTML document per URL, the CDN maintains separate cached versions keyed by geography, device type, logged-in state, A/B test cohort, language preference, or any combination of these attributes.
A site serving 5 geographic variants, 2 device types (mobile/desktop), and 3 A/B test cohorts maintains 30 cached versions per URL. Each user’s request is matched to the appropriate cached version based on request headers, cookies, or geolocation data. The TTFB for each user within a recognized segment equals edge network latency plus cache lookup time — typically 5-30ms combined — eliminating origin server processing entirely.
This approach is not true per-user personalization. It is segment-level caching that covers the majority of what sites label as “personalized content” but is actually segment-specific: regional pricing, localized navigation, device-optimized layouts, and experiment-specific variations. The distinction matters because segment-level caching scales with the number of segments (tens to hundreds of cache entries per URL), while true per-user caching would require millions of entries per URL and is infeasible.
The cache key composition must be deterministic and computable at the CDN edge without origin consultation. Cloudflare, Fastly, and Akamai all support custom cache key construction using request headers (Accept-Language, User-Agent), client IP geolocation, and cookie values. The operational complexity lies in defining segments that are coarse enough to achieve high cache hit rates but fine enough to serve relevant content. Overly granular segmentation (caching per user ID) defeats the purpose; overly coarse segmentation (one version for all users) serves irrelevant content.
Edge-Side Includes: Caching the Page Shell, Personalizing the Fragments
Edge-Side Includes (ESI) and equivalent fragment-based architectures decompose the HTML page into independently cacheable fragments. The common page shell — header, navigation, main content area, footer, and structural layout — is cached at the edge with a long TTL because it changes infrequently and is identical across users. Personalized fragments — user greeting, cart item count, recommendation widget, notification badge — are fetched separately and assembled into the cached shell at the edge before delivery to the user.
The origin server generates the page shell with ESI tags marking the positions of personalized fragments:
<header>
<nav><!-- Cached navigation --></nav>
<esi:include src="/api/user-greeting" />
<esi:include src="/api/cart-count" />
</header>
<main><!-- Cached article content --></main>The CDN edge processes these tags: it serves the cached shell immediately and fetches the fragment sources (which may themselves be cached with shorter TTLs or computed by edge functions). The assembled response reaches the user with TTFB determined by the slowest fragment fetch, which is typically much faster than full-page origin rendering.
Cloudflare Workers, Fastly Compute, and AWS CloudFront Functions all support variations of this fragment assembly pattern, though ESI tag processing specifically requires CDN-level support (Fastly and Akamai support ESI natively; Cloudflare requires Workers-based implementation). The implementation complexity varies significantly — native ESI support requires minimal code changes, while Workers-based fragment assembly requires custom edge function development.
Alibaba Cloud’s research into Edge Side Rendering (ESR) extended this concept further by streaming the cached shell to the user immediately while simultaneously fetching dynamic fragments. The user receives the static content first (reducing perceived TTFB to near-zero) and the dynamic fragments stream in as they become available. Their published results showed TTFB reductions of 1 second and white screen time reductions of 1 second compared to traditional origin rendering.
Stale-While-Revalidate for Dynamic Pages: Instant Response with Background Refresh
The stale-while-revalidate Cache-Control directive enables the CDN to serve a cached (potentially slightly outdated) HTML response immediately while triggering an asynchronous background request to the origin for a fresh version. The user receives the cached response with edge-cache TTFB (5-30ms), and the cache updates in the background for subsequent requests.
The HTTP header implementation:
Cache-Control: max-age=60, stale-while-revalidate=3600This directs the CDN to serve the cached response as fresh for 60 seconds. After 60 seconds, the response is stale but can be served for up to 3600 additional seconds while a background revalidation occurs. The first request after staleness begins receives the stale response instantly and triggers the origin fetch; subsequent requests during the revalidation window also receive the stale response until the fresh response arrives and replaces it.
For pages where content freshness tolerance is measured in minutes rather than seconds — news homepages, product listing pages, blog indexes, category pages — this pattern delivers origin-bypassing TTFB with acceptable staleness. The freshness window (max-age) should be tuned to the content’s actual update frequency. A product listing page that updates every 15 minutes can safely use max-age=900.
Combining stale-while-revalidate with stale-if-error adds resilience: if the origin is unreachable during revalidation, the CDN continues serving the stale response rather than returning an error. For TTFB stability, this means the CDN edge always has a response available regardless of origin health.
The SEO-relevant consideration is that Googlebot may receive stale content during revalidation windows. For most content types this is inconsequential — a product listing that is 5 minutes stale differs negligibly from the current version. For time-sensitive content (breaking news, flash sales, inventory-dependent pages), the staleness window must be shorter or the cache must be proactively purged when content changes.
Edge Compute Personalization and Its Caching Limitations
Edge compute platforms execute lightweight code at CDN points of presence, enabling per-request personalization without origin round trips. The computational model is simple: the edge function receives the request, decodes session tokens or reads cookies to determine user context, makes personalization decisions locally, and assembles the response from cached fragments plus edge-computed dynamic elements.
Cloudflare Workers, Fastly Compute (formerly Compute@Edge), Vercel Edge Functions, and AWS CloudFront Functions each provide this capability with different runtime constraints. Cloudflare Workers and Fastly Compute support full JavaScript and WebAssembly execution with relatively generous CPU time limits (10-50ms for most plans). AWS CloudFront Functions are more constrained (execution under 1ms recommended) but suitable for simple header manipulation and redirect logic.
The TTFB benefit derives from eliminating the edge-to-origin round trip entirely for the complete HTML response. A request that previously required: user to edge (20ms) + edge to origin (80ms) + origin processing (200ms) + origin to edge (80ms) + edge to user (already accounted for) = 380ms TTFB now completes as: user to edge (20ms) + edge compute (10ms) + cache lookup (2ms) = 32ms TTFB. The improvement factor depends on the origin’s geographic distance from the CDN edge and the origin’s processing time, but reductions of 50-80% are consistently reported in production deployments.
Fastly’s documentation on serving dynamic content at the edge describes a content stitching pattern where the edge function combines cached content fragments with per-request personalized elements into a single streaming response. The user receives the response progressively — cached elements stream immediately, and personalized elements stream as the edge function computes them — providing perceived TTFB near zero for the initial content.
The tradeoff is compute cost per request at the edge (charged per invocation and CPU time by most providers) and the constraint that edge functions must complete quickly to maintain the TTFB advantage. If edge personalization logic requires database queries, API calls to upstream services, or complex computation exceeding 50ms, the TTFB advantage over origin rendering diminishes. Edge compute is most effective for personalization that can be resolved from request headers, cookies, and cached data without external calls.
Pages requiring real-time data accuracy cannot tolerate any cache staleness, which excludes them from the edge caching strategies described above. Specific categories include:
- Live pricing and inventory: e-commerce pages displaying current stock levels or dynamically priced items must reflect the current state at the moment of request. A stale cache showing “in stock” for a sold-out item creates a worse user experience than a slightly slower TTFB.
- Authenticated account pages: user account dashboards, order history, and profile pages contain per-user data that cannot be segmented or cached without security implications.
- Transactional checkout flows: payment and checkout pages must communicate with real-time payment processing, inventory reservation, and fraud detection systems.
- Real-time collaboration: documents, chat interfaces, and live editing sessions require server-side state that changes with every interaction.
For these pages, the CDN’s contribution to TTFB is limited to network-layer optimizations: TCP connection reuse via persistent connections at the edge, TLS session resumption to avoid full handshake costs on repeat connections, HTTP/2 or HTTP/3 multiplexing to reduce connection overhead, and origin shield architectures that consolidate edge-to-origin requests through a single intermediate cache layer, reducing origin load without eliminating origin round trips.
The TTFB floor for these non-cacheable pages is determined by edge-to-origin network latency plus origin processing time. Optimization must focus on origin-side performance: database query optimization, application code efficiency, efficient template rendering, and server-side caching of data that can tolerate staleness even if the full HTML response cannot. Reducing origin processing from 500ms to 100ms achieves a larger TTFB improvement for these pages than any CDN configuration change.
Does edge-side includes (ESI) work with all CDN providers?
No. ESI support varies significantly across CDN providers. Akamai has the most mature ESI implementation. Cloudflare does not support ESI natively but offers Cloudflare Workers as a functional equivalent for fragment assembly at the edge. Fastly supports ESI through its VCL configuration layer. Each provider’s implementation has different syntax constraints and caching behavior for fragments, requiring provider-specific testing.
Can edge caching dynamic HTML pages cause issues with CSRF tokens or session-bound content?
Yes. CSRF tokens embedded in cached HTML become shared across users if the cache key does not include session identifiers. This creates both a security vulnerability and a functional failure. The solution is excluding CSRF tokens and session-bound elements from the cached page shell and injecting them via client-side JavaScript or ESI fragments that bypass the cache entirely.
Does HTTP/3 at the CDN edge provide a larger TTFB improvement than HTTP/2 for dynamic pages?
The improvement depends on the network conditions. HTTP/3 uses QUIC, which eliminates head-of-line blocking and merges connection setup into a single round trip. For users on lossy mobile networks or high-latency connections, the difference is measurable. For users on stable broadband, the improvement over HTTP/2 is minimal because connection overhead is already a small fraction of total TTFB.
Sources
- https://web.dev/articles/optimize-ttfb
- https://www.fastly.com/blog/serving-truly-dynamic-content-with-a-modern-cdn-and-edge-first-delivery
- https://systemdr.substack.com/p/edge-caching-dynamic-content-strategies
- https://wjaets.com/index.php/content/technical-review-edge-side-includes-esi-composition-cdn-level
- https://www.alibabacloud.com/blog/esr-optimizes-frontend-performance-by-using-edge-computing-capabilities-of-cdn_596863
