TTL Settings Guide: How to Choose Cache Durations Without Breaking Freshness

Overview

A cache TTL, or time to live, tells a browser, CDN, proxy, or application cache how long it can reuse a response before checking again or fetching a fresh copy. In plain terms, TTL is a freshness budget. A longer budget usually means better hit rates, lower origin traffic, and faster repeat visits. A shorter budget usually means fresher content, but more requests travel back to the source.

The challenge is that there is no single correct TTL for an entire website. HTML, images, JavaScript bundles, API responses, logged-in dashboards, and cart pages do not have the same freshness requirements. Teams run into trouble when they apply one aggressive rule everywhere or when they keep TTLs so short that caching becomes mostly decorative.

If you are asking, how long should cache TTL be?, the right answer is usually: long enough to capture repeat traffic, short enough to respect how often the content changes, and paired with an invalidation method for exceptions.

A useful way to think about ttl settings is to separate them by cache layer:

• Browser cache TTL: how long a visitor’s device can reuse a file.
• CDN TTL: how long edge servers keep a copy close to users.
• Server or reverse-proxy TTL: how long an origin-side layer such as NGINX FastCGI cache or Varnish cache can serve content without regeneration.
• Application and object cache TTL: how long computed fragments, query results, or key-value entries remain reusable.

These layers do different jobs. A browser cache can eliminate repeat downloads. A CDN can reduce latency and shield the origin. A server cache can reduce expensive page generation. An object cache such as Redis can speed repeated database-driven work. If you need a quick refresher on those boundaries, see Page Cache vs Object Cache vs Opcode Cache: What Each Layer Actually Does.

For most teams, cache TTL best practices start with one principle: treat mutable HTML differently from versioned static assets.

A practical TTL baseline by content type

These are starting points, not fixed rules:

• Versioned static assets such as hashed CSS, JS, fonts, and build-generated images: long TTLs, often measured in months or up to a year, because the filename changes when the content changes.
• Non-versioned static assets: shorter TTLs unless you have reliable purge controls.
• Marketing HTML and article pages: moderate TTLs, often minutes to a few hours, depending on editorial cadence and tolerance for brief staleness.
• Homepage, category, and landing pages: shorter than evergreen article pages if merchandising or featured content changes often.
• API responses: highly dependent on use case. Public reference data may tolerate longer TTLs; inventory, pricing, or account data often needs very short TTLs or no shared caching.
• Logged-in areas, carts, checkout, and account pages: usually bypass shared caches or use very constrained private caching rules.
• Search results and personalized recommendations: generally require careful variation rules, short TTLs, or explicit no-store behavior.

The common mistake is optimizing for the average page instead of the risky page. It is better to cache 80 percent of your site safely than to push a single broad rule that creates stale account views or incorrect ecommerce states.

TTL also works best when combined with explicit cache headers. If your team needs implementation-level guidance, pair this article with Cache-Control Header Cheat Sheet for Static Assets, HTML, and APIs.

How to choose a TTL without guessing

Use four questions:

1. How often does this content actually change? Not how often it could change, but how often it usually does.
2. What happens if users see an older copy briefly? For a blog post, the risk may be low. For stock levels or account balances, the risk is high.
3. Can we invalidate or purge on demand? Longer TTLs are safer when purges are reliable.
4. Is the content versioned? Versioned assets support the longest browser and CDN TTLs with the lowest freshness risk.

That framework prevents the most common TTL error: setting extremely low durations because the team does not trust its own release and purge process. Very short TTLs can mask workflow problems, but they rarely deliver the best performance or origin efficiency.

Maintenance cycle

The most reliable TTL strategy is not a one-time setup. It is a maintenance routine. A site’s content patterns, deployment flow, plugin stack, and traffic shape change over time, so TTL policy should be reviewed on a schedule instead of only after incidents.

A workable cycle is quarterly for most production websites, with lighter monthly checks for fast-changing platforms or high-revenue paths.

What to review each cycle

• Content map: list page types, API classes, assets, and personalized surfaces.
• Current TTL map: document browser, CDN, reverse-proxy, and application TTLs.
• Purge behavior: verify whether releases, content updates, and product changes trigger invalidation where needed.
• Headers in production: inspect real responses, not just config files.
• Cache hit patterns: compare hit rate by content type, not only sitewide averages.
• Error paths: review whether 404, 301, 500, and maintenance responses are cached appropriately.

Teams often focus on best-case responses and forget negative caching. A short but intentional TTL for 404s can reduce repeated origin work, while a careless long TTL on temporary errors can create its own outage.

A maintenance checklist by layer

Browser layer:

• Confirm long-lived static assets are versioned.
• Check that HTML is not accidentally given asset-style TTLs.
• Review whether fonts, images, and scripts use consistent cache policies.

CDN and edge caching layer:

• Inspect edge rules, overrides, and exceptions.
• Make sure query strings, cookies, and headers are not exploding cache keys without reason.
• Validate that purge flows are fast enough for editorial and release needs.
• Recheck cloudflare cache rules or equivalent vendor rules after platform changes.

Origin and server caching layer:

• Review page cache TTLs for dynamic routes.
• Audit bypass conditions for login, cart, search, preview, and admin paths.
• Verify that nginx fastcgi cache or varnish cache rules still match your app behavior.

Application and object layer:

• Confirm that expensive fragments have TTLs aligned to update frequency.
• Check whether redis object cache entries are too short to help or so long they survive meaningful changes.
• Review stampede protection where many requests regenerate the same expired object.

For WordPress, maintenance should include cache plugin behavior and host-level caching interactions. A plugin such as a cache plugin or litespeed cache can work well, but only if its TTL choices do not fight the CDN or the managed host’s own cache layer. This is especially important for wordpress caching on sites with WooCommerce, membership features, or multilingual plugins.

The release-management angle

TTL policy should be part of deployment design. If your front end ships hashed assets, you can keep browser cache ttl values high with confidence. If your CMS publishes urgent edits without purge support, your HTML TTLs need more caution. If your ecommerce platform updates stock every few minutes, category and product cache windows must reflect that cadence.

In other words, TTL is not only a performance setting. It is an operating model decision that sits between publishing workflow and infrastructure.

Signals that require updates

Even if you have a scheduled review, some changes justify revisiting TTLs immediately. These signals usually mean your current durations no longer fit reality.

1. You changed how often content updates

If a previously static section becomes campaign-driven or your team starts publishing multiple times per day, old TTL assumptions are no longer safe. The opposite is also true: if an area rarely changes now, longer caching may be available.

2. You introduced a CDN, edge logic, or a new hosting layer

Moving to a new CDN, managed WordPress host, reverse proxy, or edge platform can silently change default caching behavior. Review cdn ttl settings, cache key rules, cookie handling, and default status-code caching. A second cache layer is helpful only when its policy is understood.

3. You see unexplained freshness complaints

Users reporting old headlines, outdated product availability, or stale navigation are often not complaining about one bad object. They are telling you your TTL map and purge flow are misaligned. Freshness complaints should be treated as architectural signals, not only support tickets.

4. Cache hit rate is low despite long TTLs

Long durations alone do not guarantee good results. Low hit rates may indicate fragmented cache keys, excessive cookie variation, query-string noise, or frequent purges. In that case, the fix may be key normalization rather than even longer TTLs.

5. Origin load spikes after launches or traffic bursts

If major releases or campaigns create sudden origin stress, your TTLs may be too conservative for key anonymous traffic paths, or your warm-up and purge strategy may be incomplete. This is one of the clearest cases where better website caching directly supports reliability.

6. Core Web Vitals or TTFB regress

When teams work to reduce TTFB and improve Core Web Vitals, TTL settings often need review alongside code changes. If cacheable pages are reaching origin too often, the performance budget is being spent unnecessarily.

7. Ecommerce logic changed

WooCommerce caching and similar ecommerce setups often drift over time as plugins add cookies, fragments, personalized banners, and location-based pricing. A category page that was safely cacheable last quarter may no longer be simple. Revisit variation rules and bypass paths whenever merchandising logic changes.

For specialized high-frequency environments, such as telemetry or industrial systems, update triggers can be even more aggressive because data value decays quickly. Related patterns are explored in Designing cache layers for high-velocity telemetry and Edge vs central caching for real-time industrial monitoring.

Common issues

Most TTL problems are not caused by one obviously wrong number. They come from policy mismatches between layers, workflows, and content behavior. Here are the issues that appear repeatedly.

Long TTLs on unversioned files

This is one of the classic mistakes. If CSS or JavaScript files are cached for a very long time but their URLs do not change when content changes, users can hold stale assets long after a release. The better pattern is long TTL plus fingerprinted filenames.

Short TTLs used as a substitute for invalidation

If every HTML page gets a tiny TTL because the team fears staleness, origin traffic stays high and cache efficiency remains poor. Small TTLs are not a replacement for purge discipline. A more durable model is moderate TTLs plus event-driven purges for important updates.

Conflicting rules between browser, CDN, and origin

A browser may be told one thing, the CDN another, and the origin something else entirely. This makes debugging difficult. Define which layer is authoritative for each content class and document the expected header behavior.

Over-caching dynamic or user-specific responses

Shared caches should be very careful with authenticated, personalized, or transactional content. A shopping cart, account page, or admin response often needs bypass logic, private caching, or no-store directives. A fast wrong page is worse than a slower correct one.

Ignoring cache key design

TTL can only help if the same request maps to the same reusable object. Excessive variation by cookies, headers, language parameters, geolocation hints, or random query strings will fragment the cache. In practical terms, many low-performing caches have a key problem more than a TTL problem.

Not distinguishing page cache vs object cache

Teams sometimes try to fix a dynamic HTML problem with an object cache TTL or expect page caching to solve an expensive database query inside uncached routes. Each layer should have its own TTL strategy. Again, this is where understanding page cache vs object cache matters operationally.

No plan for stale-if-error or stale-while-revalidate behavior

In some stacks, serving slightly older content during origin trouble or background revalidation can improve resilience. But those controls need careful boundaries. They should support availability without hiding real freshness requirements on sensitive routes.

Applying one TTL policy across every site environment

Production, staging, previews, and review apps may need different behavior. Preview links often require near-immediate changes, while production assets can be aggressively cached. Avoid copying a production TTL policy blindly into every environment.

When to revisit

If you want TTL policy to stay useful, revisit it on purpose rather than waiting for complaints. The most practical rhythm is a lightweight monthly check and a deeper quarterly review, with additional reviews after releases that affect rendering, personalization, CDN rules, or content operations.

Use this action plan

1. Inventory content classes: static assets, anonymous HTML, personalized HTML, APIs, media, search, cart, checkout, admin.
2. Assign a freshness tolerance: immediate, near-real-time, same hour, same day, or long-lived.
3. Set TTL by class and layer: browser, edge, origin, object.
4. Document invalidation triggers: deploys, content publishes, product updates, price changes, emergency edits.
5. Test actual headers with real URLs in production.
6. Measure outcome: hit rate, origin requests, TTFB, support complaints, stale-content incidents.
7. Adjust one class at a time instead of changing all TTLs globally.

A good ongoing question is not only how long should cache TTL be, but also what is our fastest safe path to freshness when the content changes unexpectedly? Teams that can answer both tend to get better performance and fewer incidents.

As your site evolves, return to this guide whenever any of the following happens:

• You launch a new theme, framework, or headless front end.
• You add a CDN, change hosting, or move to a new reverse proxy.
• You introduce personalization, localization, or A/B testing.
• You add ecommerce features, subscriptions, or member-only areas.
• You change editorial cadence or publishing workflow.
• You see lower cache efficiency or more freshness complaints.

The durable pattern is simple: cache long where content is versioned or stable, cache carefully where freshness carries business risk, and never let TTL do the job of invalidation alone. That approach keeps website speed optimization grounded in correctness, which is what makes a TTL strategy worth keeping over time.

For readers building a broader internal playbook, this article works best alongside implementation notes on cache headers, page-vs-object caching, and CDN rule design. Review it during your regular performance maintenance cycle, update your TTL map when search intent or platform behavior changes, and treat every stale-content report as a useful signal that the policy may need refinement.