Cache-Control Headers and TTL Settings: A Practical Website Caching Configuration Guide

Overview

Website caching can reduce repeat requests to your origin server, lower time to first byte (TTFB), and make pages feel more responsive. It only works reliably when each response communicates its caching policy clearly. The main tool for doing that is the Cache-Control response header.

A useful starting point is to separate content into three groups:

• Long-lived static assets: versioned JavaScript, CSS, fonts, and images that can receive a long browser and CDN TTL.
• Public page content: articles, category pages, and landing pages that can be cached but may need scheduled revalidation or purging.
• Private or dynamic responses: account pages, checkout steps, cart data, personalized dashboards, and sensitive API responses that generally should not be shared through a public cache.

Cache headers are not a substitute for a complete caching design. Browser caching, CDN caching, page caching on the origin, and object caching such as Redis solve different problems. For a broader explanation, see page cache vs object cache vs CDN edge cache.

Before changing a TTL, identify which layer is serving the response. A browser may reuse an object without contacting the CDN; the CDN may serve a cached response without contacting the origin; and the origin may itself use Varnish, Nginx FastCGI Cache, or another server cache. A change at one layer will not necessarily clear the others.

What to track

Maintain a small cache inventory rather than treating every URL the same. For each important route or asset type, record the intended policy and the observed response headers. The following fields are enough for a useful recurring review.

1. Cache-Control directives

Check whether responses include the directives you expect:

• public allows a response to be stored by shared caches when other conditions permit.
• private limits storage to a private cache, such as the user’s browser, and is appropriate for many personalized responses.
• no-store instructs caches not to store the response. Use it deliberately for responses that should not be retained.
• no-cache does not mean “never cache.” It permits storage but requires validation before reuse.
• max-age sets the browser freshness lifetime in seconds.
• s-maxage can set a separate freshness lifetime for shared caches such as a CDN, where supported.
• must-revalidate tells a cache not to use a stale response after it becomes stale without successful validation.
• stale-while-revalidate permits a cache to serve a stale response for a defined period while it checks the origin in the background.
• stale-if-error can permit stale content during an origin error for a defined period, if supported by the caching layer.

Do not combine directives by habit. For example, a public article might use a moderate s-maxage with revalidation or purge procedures, while a private account response may use private, no-store. Confirm the behavior with actual requests rather than assuming every intermediary interprets a policy identically.

2. TTLs at each layer

Track browser TTL, CDN or shared-cache TTL, origin page-cache TTL, and object-cache expiration separately. A long CDN TTL can improve cache-hit performance, but it also increases the time outdated content may remain available if invalidation is incomplete. A short browser TTL may create more requests even when the CDN still serves the response quickly.

For static assets, a long TTL is easiest to manage when filenames change whenever the content changes, such as app.8f31c.js. For HTML, use a shorter or more actively managed policy when editors publish frequently. For APIs, consider whether the response is public, whether it varies by authorization or cookies, and whether stale data is acceptable.

3. Cache status and validation signals

Record cache-status headers exposed by your CDN or proxy, such as hit, miss, bypass, or revalidated states. Also check Age, ETag, and Last-Modified where present. These signals help distinguish a cache miss from an origin response that was deliberately marked uncacheable.

Useful monitoring targets include cache-hit ratio, origin request volume, purge completion, response age, error responses, and TTFB. A hit ratio alone is not a quality score: caching a large number of low-value assets may look successful while important HTML pages continue to miss.

Cadence and checkpoints

Review cache behavior on a monthly or quarterly cadence, with additional checks after deployments, CDN rule changes, hosting migrations, or authentication changes. A repeatable review is more useful than occasional manual inspection.

Monthly checkpoint

1. Request representative URLs with a command-line tool or browser developer tools. Inspect Cache-Control, Age, validators, Vary, and cache-status headers.
2. Test at least one anonymous page, one logged-in or private route, one API response, and several static assets.
3. Compare cache hits, misses, bypasses, and origin latency with the previous review.
4. Check whether recent content was purged or revalidated as intended.
5. Confirm that cart, checkout, login, account, and personalized pages are not being shared publicly.

Quarterly checkpoint

Revisit the cache map when the site’s content model changes. A blog may move from occasional publishing to frequent updates; an ecommerce store may add inventory or personalized pricing; an API may gain new authentication or query parameters. These changes can make an old TTL or bypass rule unsafe.

Also review whether your cache rules still match the deployment process. If asset filenames are fingerprinted, long-lived asset caching may be appropriate. If filenames stay constant, a deployment should include reliable purge or revalidation steps. The guide to busting cache safely during deployments covers that relationship in more detail.

How to interpret changes

A sudden increase in origin traffic does not always mean the TTL is too short. It may indicate a cache key change, a new query string, a cookie causing bypasses, an unexpected Vary value, a purge, an expired object, or a CDN rule that no longer matches the URL.

When cache hits fall, compare a working URL with a failing URL. Look for differences in hostname, protocol, query parameters, cookies, authorization headers, and response headers. Test from more than one location if edge caching is involved. If only one route is affected, inspect its application response. If many routes changed at once, examine the CDN, reverse proxy, deployment, or DNS path first.

When users report stale content, determine which layer is serving it before reducing every TTL. Check the response age, purge history, origin content, and browser cache. A targeted purge or corrected cache key may solve the problem without sacrificing the performance benefits of a longer TTL.

Use stale-while-revalidate when a brief period of older content is acceptable and avoiding a request-time delay is valuable. It is less suitable for inventory, account balances, permissions, or other data where freshness has a direct operational consequence. For ecommerce, keep product discovery and editorial pages separate from cart and checkout behavior; the cache bypass guide for login, cart, and personalized pages provides practical patterns.

When to revisit

Revisit your cache headers and TTL settings at least quarterly, and immediately after a major change to content publishing, authentication, hosting, CDN configuration, domain routing, or deployment practice. Also review them when TTFB, cache-hit ratio, origin load, or stale-content reports change unexpectedly.

Keep a dated record of intended policies and observed behavior. For each review, capture one successful cache hit, one expected bypass, one purge or revalidation test, and one private-response check. This creates a small operational baseline that makes regressions easier to spot.

For the next review, start with these actions:

1. List your most important public, private, API, and static URL patterns.
2. Write the intended Cache-Control policy beside each pattern.
3. Measure the actual response headers from the browser, CDN, and origin where possible.
4. Test a content update and verify its purge, revalidation, or versioned-asset path.
5. Record any mismatch, assign an owner, and retest after the configuration changes.

A concise audit is available in the website caching checklist for headers, TTLs, and purging. Treat the checklist as a recurring control, not a one-time setup task: caching remains reliable when its rules are reviewed alongside the site’s content, application, and deployment changes.