Caching static and dynamic content

Static and dynamic are cache decisions

Caching static and dynamic content is not really about whether a file came from disk or a database. It is about whether a later request can safely reuse an earlier response. A logo, stylesheet, product image, public article, search result, API response, and account page all have different freshness and privacy rules. The right cache policy depends on those rules.

Static assets are usually the easiest candidates. If a JavaScript file or image has a versioned filename, it can often be cached for a long time because a future update will use a new URL. Dynamic content is more subtle. Some dynamic responses are public and repeatable, such as a product listing or article page generated by a CMS. Others depend on a user's identity, permissions, cart, location, device, or session state. Those differences decide whether a shared CDN cache is helpful, dangerous, or irrelevant.

What the cache needs to know

A cache needs three kinds of information: how to identify the response, how long it remains usable, and which request attributes change the answer. The cache key identifies the object. At minimum it usually includes scheme, host, path, and sometimes query string. Depending on the application, headers, cookies, language, device type, or selected query parameters may also need to be part of the key.

Freshness is usually controlled by response headers. Cache-Control: max-age tells a browser or cache how long a response may be fresh. s-maxage can give shared caches a different lifetime from browsers. private says the response is only for the current user agent, while no-store says it should not be stored at all. Revalidation headers such as ETag and Last-Modified let a cache ask whether a stored response is still current without downloading the full object again.

Variation is where many mistakes happen. A response that changes by language should vary by language. A response that changes by login state must not be served from the same shared cache entry to logged-out and logged-in users. A response that does not actually change by user agent should not vary by user agent, because unnecessary variation fragments the cache and lowers hit rates.

Good patterns for static content

For static assets, prefer immutable URLs. Add a content hash or version number to filenames, then give those files long cache lifetimes. When the content changes, publish a new URL. This avoids frequent purges and lets browsers and CDN edges reuse the object confidently.

Keep HTML and assets separate in policy. The HTML document may need a short lifetime because it references current assets or displays changing business content. The referenced CSS, JavaScript, fonts, and images may be safe for much longer. Treating every response as short-lived wastes cache capacity and increases origin load.

Also normalize avoidable noise. Tracking parameters may not change the asset, so including them in the cache key can create many duplicate cache entries. On the other hand, parameters that select size, format, currency, or search filters may be meaningful. The implementation should distinguish noise from intent rather than ignoring all query strings blindly.

Dynamic content can still be cacheable

Dynamic content can be cached when the response is predictable for a defined audience and the cache key captures the attributes that matter. Public CMS pages, category pages, availability summaries, and selected read-only API responses are common examples. They may be generated dynamically at the origin, but they do not have to be regenerated for every visitor.

The safer approach is route-by-route classification. Public and identical responses can use shared caching. Public but frequently changing responses can use short TTLs or revalidation. Personalized or permissioned responses should use private browser caching or no storage. State-changing methods such as POST, PUT, PATCH, and DELETE should not be treated as shared-cacheable unless a very specific application design proves otherwise.

Dynamic caching also benefits from request collapsing or shielding patterns. When many edges miss the same object at the same time, one upstream fetch can prevent a burst of duplicate origin work. This matters during purges, deployments, flash sales, and traffic spikes.

A practical route inventory

Build a simple inventory before changing policy:

1. List the route or path pattern.
2. Mark the audience: public, authenticated, role-based, admin, or machine-to-machine.
3. Identify what changes the response: query parameters, cookies, headers, geography, device, or account state.
4. Decide the storage rule: long shared cache, short shared cache, revalidate, browser-only, or no-store.
5. Define the purge or update mechanism.
6. Record the metrics that prove the policy works.

This exercise often finds routes where application headers and CDN rules disagree. The application may send no-cache for everything, or a CDN rule may override headers too broadly. Either can be valid in a narrow case, but broad defaults usually hide important differences.

Common failure modes

The highest-impact mistake is caching private content in a shared cache. This can expose account pages, carts, API responses, or personalized fragments to other users. The opposite mistake is treating every response as uncacheable, which forces needless origin work and makes traffic spikes more expensive.

Other failures include stale pages after publishing, purge storms that overload the origin, cache poisoning through untrusted headers or query parameters, duplicate objects caused by tracking parameters, and low hit rates caused by excessive Vary behavior. Dynamic pages can also fail in confusing ways when one piece of the response is personalized but the rest is public.

Operations and security implications

Caching is a production control. Changes to TTLs, keys, header overrides, and purge rules can affect privacy, availability, cost, and incident response. They need review and logs, especially for authenticated areas, APIs, checkout, and admin paths.

Measure cache hit ratio, byte hit ratio, origin request rate, origin latency, purge frequency, stale response serving, and user-facing errors. Break results down by route. A high global hit ratio can hide a checkout route that is slow, or a low global hit ratio can be acceptable if most bytes are served from cache.

The best caching strategy is explicit. Static assets should be easy to reuse. Dynamic content should be cached only when the audience and variation rules are understood. Sensitive responses should be protected even when caching would look attractive on a performance dashboard.