HTTP Caching Checklist for Production Sites

Overview

This checklist gives you a production-ready way to review browser, CDN, proxy, and origin caching before and after deployment. Instead of treating caching as a single header or a CDN toggle, it helps you verify the full request path: what is cacheable, where it is cached, how it is invalidated, and how you will debug it later.

A useful HTTP caching checklist should answer five questions for every important route:

1. Can this response be cached at all? Static assets, public pages, API responses, authenticated data, and admin traffic usually need different rules.
2. Which layer should cache it? Browser cache, edge/CDN cache, reverse proxy cache, and application-level caches each have different tradeoffs.
3. How long should it stay fresh? Time-to-live needs to reflect change frequency, not just performance goals.
4. What is the invalidation strategy? Purge, versioned asset URLs, surrogate keys, soft revalidation, or a short TTL with background refresh.
5. How will you inspect and verify behavior? If you cannot read headers and reproduce outcomes with curl, browser devtools, and CDN logs, the setup is not finished.

The safest evergreen rule is simple: cache aggressively for content that is immutable or easy to version, and be conservative for anything user-specific, frequently changing, or operationally sensitive.

For teams managing broader caching architecture, it can also help to think beyond page delivery and look at how consistency and traceability are handled in distributed systems. Some of the same operational concerns show up in application-level designs such as unified caching layers and event-driven systems under surge conditions.

Checklist by scenario

Use this section as the main production cache checklist. It is organized by common route and asset types because most caching failures come from applying one policy everywhere.

1. Static versioned assets: JavaScript, CSS, fonts, images

This is the highest-confidence place to cache aggressively.

• Use content-hashed or versioned filenames for deployable assets.
• Set a long cache lifetime for immutable files, typically through Cache-Control with max-age and immutable where appropriate.
• Make sure your CDN honors those headers or has an explicit override you understand.
• Confirm gzip or Brotli compression is enabled where supported.
• Verify ETag or Last-Modified behavior if you still rely on revalidation.
• Ensure old asset URLs remain safe to serve after deployment so clients with older HTML do not break.

If asset URLs are versioned correctly, long-lived browser and edge caching is usually low risk and high value.

2. HTML documents for public pages

HTML deserves more care because it changes more often and controls which asset URLs users discover.

• Decide whether HTML is cached in the browser, at the CDN, both, or neither.
• For frequently updated sites, prefer shorter TTLs with revalidation rather than very long freshness windows.
• Separate anonymous traffic from personalized sessions. Public marketing pages are not the same as signed-in dashboards.
• Check whether the CDN varies on cookies, authorization headers, language, country, or device hints. Unnecessary variation reduces hit rate.
• If your edge supports stale-while-revalidate or stale-if-error semantics, apply them intentionally and test how they behave during origin failure.

A common pattern is to cache public HTML at the edge with modest TTLs while keeping browser caching shorter, especially when content updates are frequent but not truly real-time.

3. APIs and JSON responses

API caching is useful, but only when response scope is well understood.

• Classify endpoints as public, tenant-scoped, user-scoped, or highly sensitive.
• Do not let authenticated responses become shared-cache content unless you have explicit keying and isolation.
• Use Vary carefully. It is necessary for correctness, but broad variation can collapse hit rates.
• Cache expensive but stable read endpoints at the CDN or reverse proxy if response semantics allow it.
• For APIs with rate pressure, consider short TTLs and conditional requests to reduce repeated origin work.
• Document whether the client should cache the response, the edge should cache it, or only the application should memoize it internally.

If there is any doubt about whether a response can leak between users, default to a non-shared cache policy and optimize later with explicit design.

4. Authenticated pages and user-specific content

This is where teams often introduce their worst cache bugs.

• Audit all routes that depend on session cookies, bearer tokens, or request identity.
• Make sure private responses are marked for private handling where needed and not stored in shared intermediaries by accident.
• Check that edge rules do not cache responses simply because the method is GET.
• Verify redirects around login, logout, token refresh, and account switching are not cached in a way that causes broken sessions.
• Test with multiple user accounts to confirm no cross-user content appears from browser back/forward cache, service worker cache, CDN edge cache, or reverse proxy cache.

For sensitive flows, correctness is more important than hit ratio.

5. File downloads and media

• Decide whether files are immutable once published or may be replaced in place.
• If downloadable artifacts can change, version the URL rather than relying on purges alone.
• Check partial content and range request behavior for large files and media streaming.
• Ensure CDN and proxy buffering decisions match file sizes and traffic patterns.
• Confirm content type and content disposition headers are stable across cache hits and misses.

6. Reverse proxy and origin behavior

The origin must be able to support the caching strategy, not fight it.

• Generate consistent caching headers from the application or origin server.
• Review reverse proxy settings for buffers, keepalive behavior, and connection handling. Source guidance for Nginx commonly emphasizes tuning worker processes, connection limits, keepalive settings, and buffer sizes because defaults are often not ideal for production workloads.
• Enable HTTP/2 where appropriate for TLS traffic to improve multiplexing and reduce latency under load.
• Use modern TLS settings and session reuse features where supported. This does not replace caching, but it reduces handshake overhead on repeated requests.
• Confirm that origin responses differ only when intended. Randomized headers or inconsistent cookies can make content effectively uncacheable.

Operational tuning matters because even a good cache policy can be undermined by weak origin behavior. The same is true in edge-heavy systems such as edge dashboard architectures, where delivery logic and freshness rules must line up.

7. Purge and deployment workflow

A cache deployment checklist is incomplete without invalidation planning.

• Choose a primary invalidation method: versioned URLs, tag-based purges, path purges, or short TTLs.
• Document who can purge, how they do it, and how long propagation usually takes.
• Avoid making full-cache purges the default response to every release.
• Include cache purge steps in CI/CD only when necessary and scoped.
• Test rollback behavior. A rollback that points HTML to missing assets is a classic failure mode.

If your team uses canaries or shadow traffic for releases, it is worth aligning cache verification with those steps as part of production validation. That idea shows up clearly in systems-focused rollout practices like canary and shadow-mode validation.

What to double-check

This section covers the details that are easy to miss even when the main rules look correct.

Header correctness

• Inspect Cache-Control, ETag, Last-Modified, Expires, and Vary on real responses, not just framework defaults.
• Make sure there is no conflict between origin headers and CDN cache rules.
• Check whether redirects carry the right cache policy.
• Confirm 404, 301, 302, and 500-class responses are handled intentionally. Error caching can be useful or damaging depending on duration.

Cookie behavior

• Audit whether your application sets cookies on anonymous responses unnecessarily.
• Remove or isolate tracking and experiment cookies that prevent public caching.
• Verify that CDN rules do not bypass cache for every cookie when only a few matter.

Variation and key design

• Review which request attributes are part of the cache key: host, query string, language, device, auth state, country, or custom headers.
• Normalize query parameters to avoid fragmenting the cache with irrelevant marketing or analytics parameters.
• Treat Vary as part of contract design, not an afterthought.

Compression and protocol settings

• Verify compression at the right layer so you do not double-compress or store unnecessary variants.
• Confirm HTTP/2 support on secure endpoints if your infrastructure uses Nginx or another reverse proxy that requires explicit configuration.
• Review keepalive and buffer settings on the proxy, especially if large upstream responses or slow clients are common. The source material highlights that production Nginx setups often benefit from tuning keepalive, client body buffers, sendfile, and proxy buffers rather than relying on defaults.

Observability

• Add headers or logs that let you distinguish cache hit, miss, revalidate, bypass, and stale serve behavior.
• Test from browser devtools, curl, and at least one external network vantage point.
• Capture examples of expected headers per route type so future reviewers know what correct looks like.

If your environment has strict audit or compliance requirements, traceability matters as much as performance. Operationally, that is similar to the discipline discussed in governance and traceability for cached outputs and privacy-first cache hygiene.

Common mistakes

These are the failures that repeatedly show up in production, especially after rushed launches or infrastructure changes.

Caching HTML like static assets

Teams often copy long-lived cache rules from JavaScript bundles onto HTML documents. That usually leads to stale page shells, delayed content updates, and difficult rollbacks. HTML usually needs shorter TTLs or revalidation, even when assets can be cached for much longer.

Letting cookies disable caching everywhere

One analytics or A/B testing cookie can quietly turn public pages into origin-only traffic if the CDN treats any cookie as a cache bypass. Review cookie-based cache behavior explicitly.

Assuming the CDN honors origin headers by default

Some CDNs require separate policy configuration for edge caching, query-string handling, or cookie variation. Do not assume browser headers and edge behavior are identical.

Ignoring query parameter sprawl

Tracking parameters can create thousands of cache variants for the same resource. Normalize or strip parameters that should not affect the response body.

Relying on purge alone

Purge tools are useful, but versioned URLs are usually safer for immutable assets. Purges can lag, be scoped too broadly, or become an operational crutch.

Not testing logged-in and logged-out paths separately

Many cache incidents only appear when switching identities, reusing tabs, or mixing anonymous and authenticated traffic during the same browser session.

Forgetting failure behavior

A cache policy should define what happens when the origin is slow or unavailable. If your edge can serve stale responses during origin trouble, test that path intentionally. If it cannot, know that in advance rather than during an incident.

When to revisit

Treat this as a living production cache checklist, not a one-time setup. Revisit it whenever the inputs change.

• Before launches: especially major redesigns, framework upgrades, CDN migrations, or new authentication flows.
• Before seasonal traffic periods: if you expect traffic spikes, confirm that cache hit rates, purge procedures, and origin capacity assumptions still hold.
• After incidents: stale content, mixed-user responses, elevated origin load, or unexpected CDN bills all justify a full review.
• When deployment workflows change: new build systems, asset naming conventions, CI/CD purge steps, and edge middleware can all alter cache behavior.
• When application behavior changes: personalization, localization, experimentation, and new API clients often require a fresh cache-key design.

For a practical review cycle, keep a short runbook with these action items:

1. List your top route types: static assets, public HTML, authenticated HTML, public APIs, private APIs, downloads.
2. Record the expected cache policy for each route type in one table.
3. Test each route with browser devtools and curl before release.
4. Verify CDN behavior separately from origin behavior.
5. Check purge and rollback steps during release rehearsal, not after a bad deploy.
6. Store sample headers and expected cache outcomes in your engineering docs.

If you maintain multiple systems or teams, schedule the review the same way you schedule TLS, backup, and incident-readiness checks. Caching drifts over time because frameworks evolve, infrastructure defaults change, and new product features quietly introduce personalization. A lightweight recurring review is usually enough to prevent expensive surprises.

The goal is not to maximize caching everywhere. It is to make caching predictable, observable, and safe enough to trust in production.