TTL Tuning Guide: How to Choose Cache Expiration Times by Content Type

Overview

A useful TTL tuning guide should do two things: help you choose a reasonable default quickly, and help you know when that default is wrong. Teams often get stuck at one of two extremes. Either everything is cached for a very short time because freshness feels safer, or everything is cached for a very long time because performance feels urgent. Both approaches create avoidable problems.

Short TTLs can quietly shift load back to origin, reduce cache hit ratio, and make traffic spikes more expensive than they need to be. Long TTLs can leave users with stale pages, stale API responses, or broken assumptions after a deployment. The goal is not to maximize cache duration everywhere. The goal is to match the TTL to the behavior of the resource.

When you choose cache expiration times, think in terms of content classes rather than individual URLs first. A product image, a home page, a release manifest, a search API response, and a user dashboard do not deserve the same cache policy. Once you define those classes, you can refine within each class based on risk and change rate.

As a starting point, most teams can group resources into five buckets:

• Versioned static assets: files whose URLs change when content changes
• Shared but mutable content: HTML pages, feeds, listings, docs, or public API responses that can change without a URL change
• Personalized or session-aware content: dashboards, carts, account pages, and auth-dependent API responses
• Expensive computed content: search results, aggregate reports, transformed images, or rendered fragments
• Error and fallback responses: 404s, redirects, maintenance pages, and origin failure behavior

If you are still building your mental model, it helps to separate browser caching, CDN or edge caching, reverse proxy caching, and application-level caching. The TTL that works at one layer may be too aggressive or too timid at another. A browser might keep a static asset for months, while the CDN keeps an HTML page for a few minutes and the application caches a database query for a few seconds.

For a broader primer on layering, see Reverse Proxy Caching Explained for Beginners. If your issue is less about TTL selection and more about directive syntax, Common Cache-Control Header Mistakes and How to Fix Them is a useful companion.

Core framework

Use this framework to choose a TTL by content type instead of guessing. It works well in planning documents, CDN rule reviews, and post-incident retrospectives.

1. Start with change frequency, not popularity

Popular content is a strong candidate for caching, but popularity alone should not decide the TTL. The first question is simple: how often can this content change without a URL change? If the answer is "only on deploy," you can usually cache aggressively. If the answer is "at any moment because inventory, pricing, or status can shift," your TTL needs more caution.

A practical way to frame this is to ask for the shortest meaningful update interval. If users would reasonably expect the content to reflect changes within five minutes, then a one-hour TTL is probably too long unless you have reliable purging or revalidation.

2. Measure freshness tolerance

Not every stale response matters equally. Some content can be ten minutes stale with little user impact. Other content becomes misleading after thirty seconds. Define the tolerance in business terms rather than technical ones:

• Would a stale response cause a bad decision?
• Would it create support requests?
• Would it break a workflow?
• Would users even notice?

This turns TTL tuning into a product and operations decision, not just a cache configuration exercise.

3. Account for invalidation capability

Your safe TTL increases when you can purge precisely and reliably. If your CDN supports tag-based purge or URL-level purge and your deployment pipeline uses it consistently, you can often set longer TTLs on mutable content because you are not relying on passive expiration alone. If purges are slow, broad, or manual, shorter TTLs may be the safer default.

If you are deciding between expiration-heavy and purge-heavy strategies, CDN Cache Purge Strategies: Full Purge vs Tag Purge vs URL Purge is worth reviewing.

4. Separate browser TTL from edge TTL

One common mistake is using the same TTL everywhere. Browsers are hard to control once a response is cached on a user device. Edges and reverse proxies are easier to override, purge, or revalidate centrally. In many cases, mutable HTML should have a shorter browser TTL than edge TTL, especially if you want to preserve freshness while still protecting origin.

This is also where directives such as s-maxage become useful, because they let shared caches keep content longer than browsers do.

5. Prefer versioning for truly static assets

Versioned assets are the easiest case in TTL tuning. If the URL changes whenever the content changes, you can usually cache very aggressively because freshness is built into the filename or query version. This is where long TTLs become operationally safe rather than risky.

For deeper guidance, see Immutable Caching for Versioned Assets: When max-age=31536000 Makes Sense.

6. Use practical starting ranges

These are not universal rules, but they are strong starting points for many teams:

• Versioned JS/CSS/font bundles: months to one year, often with immutable semantics
• Unversioned static files: minutes to one day, depending on update discipline
• HTML for marketing or documentation pages: 1 to 15 minutes at the edge, shorter in the browser if content updates matter
• Homepage or category pages with frequent editorial updates: 30 seconds to 5 minutes
• Public API responses with stable shared data: 30 seconds to 10 minutes
• Search results or filter-heavy listings: 10 seconds to 2 minutes if cacheable and normalized
• Authenticated API responses: often no shared caching, but short private caching may still help in some cases
• Images and media files with stable URLs: days to months when versioned or fingerprinted; shorter if replacements happen in place
• RSS/Atom/JSON feeds: 5 to 30 minutes for most publishing workflows
• 404 responses and redirects: low to moderate TTLs, depending on how often routes are created or changed

These ranges are more useful when paired with a policy note. For example: "HTML pages default to 5 minutes at the CDN unless tied to flash promotions, live inventory, or breaking announcements." Clear exceptions matter more than the exact default.

7. Tune against failure modes, not just best-case performance

A TTL is also a resilience tool. During origin degradation, a somewhat longer edge TTL can absorb load and protect users from errors. But if your content becomes dangerous when stale, that same TTL can worsen the incident. Good TTL choices reflect your likely failure modes: traffic spikes, database contention, slow renders, upstream API instability, or operational gaps in purging.

If you use stale-while-revalidate or related patterns in your stack, combine them thoughtfully with TTLs rather than treating them as substitutes.

Practical examples

The most helpful TTL guidance is concrete. Below are example content types and the reasoning behind a reasonable starting TTL.

Example 1: Marketing site HTML

A company homepage changes a few times a week, but traffic spikes during launches. A practical approach is a short browser cache and a slightly longer edge cache. For example, browsers might revalidate often while the CDN serves cached HTML for a few minutes. This keeps updates reasonably fresh while still reducing origin load during campaigns.

If the team has dependable purge hooks in the CMS or deploy pipeline, the edge TTL can often be increased. If content editors publish urgent fixes without purge support, keep it shorter.

Example 2: Documentation pages

Documentation often changes in bursts around releases but remains stable between them. That makes docs a good candidate for moderate edge TTLs. A few minutes to an hour can work depending on release cadence and whether page URLs are versioned. Pages tied to versioned docs sets can usually be cached more confidently than a single "latest" branch.

Example 3: Public product catalog API

A catalog API serves names, descriptions, and category metadata shared across users. Inventory counts are excluded. This is a strong fit for shared caching. A TTL in the range of one to ten minutes is often a reasonable place to start, then adjust based on how quickly merchandising changes need to appear and whether purge events are available from the product system.

If clients can tolerate slightly stale category text but not stale stock status, split the endpoints instead of forcing one TTL to serve both needs.

Example 4: Search autocomplete

Autocomplete is latency-sensitive and can be expensive under load. If suggestions are based on slowly changing indexed data, even a short TTL such as 15 to 60 seconds can help dramatically. The key is normalization: query strings, locale, device hints, and other parameters must be controlled carefully or the cache will fragment.

Example 5: User dashboard HTML

Dashboard pages are often personalized and session-aware, so shared caching may be inappropriate. But that does not mean caching has no role. You might still cache subcomponents, API fragments, or private browser responses briefly if the data is safe to reuse for the same user. The right TTL is usually short because freshness expectations are higher.

Example 6: Versioned application bundles

Bundled CSS and JavaScript with content hashes in the filename should usually get very long TTLs. This is the cleanest cache win in modern front-end delivery. If your build pipeline guarantees a new URL for every content change, long-lived caching is the default, not the exception.

Related reading: Apache Cache Headers Guide for Static Assets and HTML.

Example 7: Product images

Images are often requested repeatedly and can be expensive to optimize on demand. If image URLs are versioned, long TTLs are usually appropriate. If images are replaced in place under the same URL, choose a shorter TTL or ensure purge tooling is solid. This is especially important for e-commerce teams where image corrections need to appear quickly.

For more detail, see Image Caching Best Practices for Modern Web Performance.

Example 8: News feed or release feed

Feeds are an easy place to overcache. Subscribers often expect timely updates, but feeds also receive repeated polling. A moderate TTL such as 5 to 15 minutes is a common compromise. If updates are infrequent, you can go longer. If timing is critical, shorten the TTL and offset load elsewhere.

Common mistakes

Most TTL problems come from process gaps, not missing theory. These are the mistakes that show up most often.

Using one TTL for everything

This usually means the cache policy was chosen for convenience rather than content behavior. It tends to under-cache stable resources and over-cache sensitive ones.

Ignoring URL versioning discipline

Long TTLs without versioned asset URLs are risky. Teams then rely on emergency purges to fix routine deploys, which is a sign the cache strategy is carrying too much operational strain.

Skipping cache key design

A good TTL cannot compensate for a bad cache key. If query parameters, cookies, headers, locale, or device variants are not normalized, you may see low hit rates even with generous expiration times. In that situation, raising the TTL often changes little.

Confusing hit ratio with success

A higher cache hit ratio can be useful, but it is not automatically evidence of a healthy policy. You can increase hit ratio by serving stale or overly generic responses more often. Measure user impact, origin protection, and correctness alongside hit rate. See Cache Hit Ratio: What It Means, How to Measure It, and When It Misleads.

Forgetting error caching and negative caching

Teams often tune success responses carefully and leave 404s, redirects, and temporary errors untreated. Short-lived negative caching can reduce repeated misses and unnecessary origin work. But be careful with routes that may appear soon after a miss, such as newly published pages.

Letting stale content become a deployment surprise

If editors or engineers regularly say, "Why is the old page still showing?" the issue is rarely just TTL. It is usually a mismatch between deployment expectations and invalidation behavior. Document which content types depend on passive expiration and which rely on purge events.

Missing the browser-versus-edge distinction

If you cache HTML too aggressively in browsers, users may keep seeing stale pages even after you purge the CDN. If you need fast corrections, favor shorter browser caching and somewhat longer shared-cache behavior where you have more control.

For practical rule design at the edge, Cloudflare Cache Rules Explained with Practical Examples and Varnish Cache Configuration Patterns for APIs and Content Sites are useful next reads.

When to revisit

TTL tuning is not a one-time setup task. Revisit it whenever the underlying operating assumptions change. This matters because the same content can justify a different TTL after a tooling upgrade, a release-process change, or a shift in traffic shape.

Review your TTL choices when any of the following happens:

• You introduce asset fingerprinting or remove it
• You add reliable purge hooks from your CMS, deploy system, or product backend
• You change CDN vendors or reverse proxy behavior
• You move content from server-rendered HTML to API-driven rendering or vice versa
• You start serving more personalized responses at the edge
• You observe cache-related incidents, stale-content complaints, or origin overload
• You launch new content types such as feeds, localized pages, or transformed media
• You adopt stale serving patterns or service worker caching that change freshness behavior

A practical review process can be simple:

1. List resource classes such as HTML, versioned assets, product APIs, search APIs, media, and feeds.
2. Document current TTLs at browser, CDN, reverse proxy, and application layers.
3. Note invalidation methods for each class: none, deploy-based, URL purge, tag purge, or event-driven purge.
4. Identify freshness expectations from the user or business point of view.
5. Review incidents and support tickets for signs of stale data or unnecessary origin load.
6. Adjust one class at a time rather than changing every policy together.
7. Recheck after deployments and traffic peaks to see whether the new TTL behaves as expected.

If you want a practical default, start by making your easiest wins explicit: long-lived caching for versioned assets, moderate shared caching for stable public content, cautious caching for mutable HTML, and narrow exceptions for personalized or highly volatile data. Then iterate. TTL tuning works best when it is treated as part of release engineering and performance operations, not as an isolated header exercise.

The right cache expiration times are rarely permanent. What makes this a useful reference is not a fixed table of numbers, but a repeatable decision process. As your content patterns change, your TTL policy should change with them.

For teams building a broader caching playbook, also review Service Worker Caching Strategies Compared: Cache First, Network First, and Stale While Revalidate.