Static vs Dynamic Content Caching: How CDNs Handle Both

Static assets get year-long TTLs. Dynamic responses get 1 to 60 seconds, and most of the remaining origin savings sit inside that short window. Dynamic content caching means storing responses that change often or vary by user for seconds rather than days, keyed on exactly the inputs that change the output, and serving them stale while the edge revalidates in the background. This article covers four things as of October 2026: the micro-caching arithmetic, cache key patterns for personalized pages, a static vs dynamic decision table, and a failure-mode checklist.

Micro-caching math, as of 2026: put a 1-second shared-cache TTL (Cache-Control s-maxage=1, per RFC 9111) with request coalescing in front of an endpoint taking 5,000 requests per second, and origin sees roughly one request per second per cache node, a 99.98 percent reduction. Adding stale-while-revalidate (RFC 5861) removes the latency spike at expiry, because the edge answers from the stale copy while a single background fetch refreshes it.

The short verdict by workload:

• Version static assets and cache them for a year.
• Micro-cache anonymous HTML and public API reads for 1 to 60 seconds.
• Cache personalized pages by segment, never by user.
• Send carts, checkout and writes through uncached. Speed them up with connection reuse and origin shield instead.

How dynamic content caching differs from static caching

The request path is identical for both. The edge computes a cache key, looks it up, and serves a HIT. On a MISS it fetches from origin, ideally through an origin shield so that many edges collapse into one upstream request, then stores the response if its headers allow and returns it. Static and dynamic content diverge on three variables only: TTL length, cache key width, and how invalidation happens.

Static content: long TTLs and versioned URLs

Images, video segments, stylesheets, JavaScript bundles, installers and archives rarely change after publication. The correct pattern is a content hash in the filename plus Cache-Control: public, max-age=31536000, immutable. A new release then ships under a new URL instead of relying on a purge. At this point the hit ratio depends mostly on long-tail popularity and cache capacity, not on TTL tuning. Well-run static zones commonly sit above 95 percent.

Dynamic content: short TTLs, narrow keys, fragments

Personalized pages, dashboards, prices, scores and search results change per second or per user. Most of these responses are still shareable for a short window or across a group of users. The engineering work is finding that window and that group, then encoding both in headers and cache rules. Edge-Side Includes (ESI) or edge logic then assemble the cacheable shell with the small user-specific fragment fetched from origin.

What is dynamic caching?

Dynamic caching is the practice of caching frequently changing HTTP responses at the CDN edge for very short, deliberately chosen periods, typically 1 to 60 seconds. It is paired with request coalescing and stale-serving directives, so origin sees a bounded request rate regardless of traffic. It trades a small, known staleness window for large reductions in origin load and tail latency.

Micro-caching: the arithmetic that justifies it

Origin load under micro-caching is roughly cache nodes divided by TTL, independent of client traffic. Take 40 edge nodes, no shield and a 1-second TTL: origin peaks near 40 requests per second whether clients send 500 or 50,000. Put an origin shield in front and the figure drops toward 1 per shield node. In nginx, the same pattern is a short proxy_cache_valid for 200 responses, proxy_cache_lock on so concurrent misses wait for one fetch, and proxy_cache_use_stale updating with proxy_cache_background_update on.

stale-while-revalidate and stale-if-error

A header such as Cache-Control: public, s-maxage=5, stale-while-revalidate=30, stale-if-error=300 tells a shared cache three things:

• The response is fresh for 5 seconds.
• For 30 more seconds the cache may serve it while one background fetch refreshes it.
• For 5 minutes it may serve it if origin returns errors.

The second directive removes the p99 spike at expiry. The third turns an origin outage into staleness instead of 5xx errors. Support varies by CDN, so confirm both directives in vendor documentation before relying on them.

Cache keys for personalized content

The cache key decides correctness. Too narrow and users see each other's data. Too wide and the hit ratio collapses. Build keys from the smallest set of inputs that actually change the response: path, a normalized and allow-listed set of query parameters, and at most a few low-cardinality dimensions such as device class, country, language or logged-in versus anonymous.

• Segment, never identity. Key on "plan=pro" or "region=EU", not on a session cookie. Ten segments cache well. Ten million users do not.
• Normalize before keying. Lowercase, sort parameters, and strip tracking parameters such as utm values and click IDs. Unnormalized marketing links can split one page into thousands of cache entries.
• Avoid Vary: Cookie and Vary: User-Agent. Both explode cardinality. Derive a single normalized header at the edge and vary on that instead.
• Split the page. Cache the shell by segment and fetch the greeting, cart count or recommendations as a separate uncached or per-user-cached fragment through ESI or a client-side call.

These rules are also where location-, device- and content-type-based cache durations belong. A product page can carry a 30-second TTL while its price fragment carries 2 seconds.

Dynamic content delivery when nothing can be cached

Dynamic content delivery for truly uncacheable responses (checkout, authenticated writes, per-user API calls) still benefits from a CDN through dynamic acceleration. The edge terminates TCP and TLS near the user, reuses warm long-haul connections to origin, and routes over the best available path. It reduces the round trips a request pays, without storing anything.

The arithmetic, as an estimate. A user 150 ms of round trip from origin opening a fresh TCP plus TLS 1.3 connection pays about 3 round trips before the first byte: roughly 450 ms. The same user 20 ms from an edge holding a pooled origin connection pays about 2 × 20 + 150 = 190 ms. That saves around 260 ms on the first request. Edge compute extends the idea by moving token validation, A/B assignment and fragment assembly to the edge, which removes the origin round trip entirely for those steps.

Static vs dynamic caching decision table

Only carts, checkout and writes are truly uncacheable; everything else is a choice of TTL and key width.

Failure modes: what breaks and how to confirm it

Cross-user leaks are the failure that matters most, because the rest cost performance while this one costs a security incident.

Security when caching dynamic responses

A cached response skips every origin-side check. Authorization therefore has to live in the cache key or at the edge: signed URLs or tokens validated before lookup, and private, no-store on anything tied to a session. TLS on both legs, plus the DDoS mitigation and bot management your CDN or security vendor provides, protect the dynamic tier. Bots love uncached search and login endpoints because every request reaches origin.

Cost and business impact of caching both tiers

Offload is where the money is. Every point of hit ratio removes origin compute and egress. For e-commerce, micro-cached listing pages keep browsing responsive during sales peaks. Media and gaming push most of their bytes as static segments, builds and patches, where cache warm-up before a known release prevents the cold-cache flood. Predictive and machine-learning TTL tuning gets marketed heavily. Explicit TTLs plus warm-up before known events deliver most of the value without the opacity.

Splitting tiers across providers is a common pattern. BlazingCDN is built for the static side of the decision table: high-volume video, installers, game builds and images, with origin shield, request coalescing and an average cache hit ratio above 96 percent. It can run as a second CDN behind DNS with a weighted traffic split, so heavy static bytes move while dynamic acceleration and security stay with your existing stack.

Verify this on your own stack

• Request a micro-cached URL repeatedly within its TTL. The Age header should rise and the cache status header (often Cache-Status per RFC 9211) should read HIT.
• Chart origin requests per second per endpoint. After micro-caching it should flatten near the number of shield or edge nodes divided by TTL.
• Alert on any response carrying Set-Cookie with Age above 0.
• Report hit ratio per path prefix, not globally: a 95 percent static average can hide a 10 percent dynamic tier.

FAQ: dynamic content caching on a CDN

Can a CDN cache dynamic content?

Yes, a CDN can cache dynamic content when the response is shareable for a short window or across a group of users. Typical setups micro-cache anonymous HTML and public API reads for 1 to 60 seconds and cache personalized pages by segment. Truly per-user responses such as carts and checkout stay uncached and rely on dynamic acceleration instead.

What TTL should I use for micro-caching dynamic pages?

Start with 1 to 5 seconds for prices, scores and inventory, and 30 to 60 seconds for anonymous HTML. Origin load under micro-caching scales with cache nodes divided by TTL, so even 1 second removes most traffic at high request rates. Raise the TTL only after confirming the business tolerates that staleness window.

Does stale-while-revalidate work for dynamic content caching on CDNs?

It works on CDNs that implement RFC 5861 and is especially valuable for dynamic content. The edge serves the expired copy instantly while one background request refreshes it, which removes latency spikes at expiry. Support and exact semantics differ between providers, so verify behavior in vendor documentation and test it before depending on it.

How do you cache personalized content without leaking user data?

Cache personalized content by segment, never by user identity. Key on low-cardinality values such as plan, region or language, cache the page shell, and fetch user-specific fragments separately. Mark any response that sets cookies or depends on a session as private or no-store, and alert when such a response is served with an Age header above zero.

Is dynamic caching safe for API responses?

Dynamic caching is safe for public, idempotent GET responses whose cache key includes every parameter that changes the output. Allow-list query parameters, normalize their order, and never cache responses to authenticated or write requests. Unkeyed parameters are the common bug: two clients send different filters and both receive whichever response was cached first.

What is the difference between dynamic content delivery and dynamic caching?

Dynamic caching stores frequently changing responses briefly at the edge, while dynamic content delivery accelerates responses that cannot be stored at all. Delivery relies on TLS termination near the user, warm pooled connections to origin and path optimization, typically saving a few hundred milliseconds on long-distance first requests. Most production setups combine both.

Measure your cacheable share this week

Export one day of edge or origin logs and bucket every request into the six rows of the decision table above. Then compute what fraction of origin requests come from anonymous HTML and public API reads. That fraction is your micro-caching opportunity. Enable a 1-second TTL with request coalescing on the single busiest endpoint, and compare origin requests per second and p99 latency before and after. Run the Set-Cookie alert first.

If the exercise shows that most of your bytes sit in the static rows, the BlazingCDN features for static content caching list origin shield, request coalescing, purge, cache warm-up through the API and Prometheus metrics on every plan.