Website caching and CDN strategy

Caching is the closest thing web performance has to free money: work you did once, served again for nothing. It’s also the only optimization that can hand one user’s account page to another if a rule is wrong. Both outcomes flow from the same three decisions — what may be reused, by whom, and for how long.

Understand the cache layers

• Browser cache reuses resources for one user.
• Shared or CDN cache reuses responses across users near the edge.
• Reverse-proxy cache sits in front of the application.
• Application cache stores rendered fragments, query results, or computed data.
• Database cache reduces repeated data access.

Each layer has different privacy and invalidation risks. Do not add all layers simply because they are available.

Start with static assets

Versioned assets such as app.a1b2c3.js can be cached for a long time because a content change produces a new URL:

Cache-Control: public, max-age=31536000, immutable

HTML usually needs a shorter policy or revalidation so visitors discover new asset URLs. Avoid long-lived caching for unversioned files unless the update process can purge them reliably.

Choose directives intentionally

• max-age sets how long any cache may treat the response as fresh.
• s-maxage can set a different lifetime for shared caches.
• no-cache permits storage but requires revalidation before reuse.
• no-store tells caches not to store the response.
• private restricts reuse to a private cache.
• validators such as ETag and Last-Modified can make revalidation efficient.

Do not use no-cache when you mean “never store”; the names are easy to misread.

Protect personalized and sensitive content

Authenticated pages, account data, carts, and responses containing user-specific information need explicit policies. A CDN cache key must include every dimension that changes the safe response. Cookies, headers, language, device handling, and query parameters can create accidental cross-user reuse or destroy cache efficiency.

When uncertain, start private and add shared caching only after tests prove correctness.

Use a CDN for the right reasons

A content delivery network can move cacheable bytes closer to users, absorb traffic spikes, terminate TLS, and reduce origin connections. It cannot fix slow uncached application logic by itself.

Measure cache hit ratio, edge and origin latency, bytes served, error rates, and purge behavior. Ensure the origin only trusts forwarding headers from known proxies and remains protected against direct abuse where appropriate.

Plan invalidation before launch

Prefer content-addressed or versioned URLs for assets. For HTML and API data, define purge keys, maximum stale duration, and how urgent corrections propagate. Test rollback: a previous release may reference assets the new deployment deleted.

Verify the result

Inspect headers and repeat requests:

curl -I https://example.com/assets/app.a1b2c3.js
curl -I https://example.com/

Check Age, cache-status headers, Cache-Control, validators, and Vary. Test signed-in and signed-out sessions separately and verify that private data never appears across accounts.

Sources and further reading

• MDN: HTTP caching
• MDN: Cache-Control