Cache TTL Strategy by Content Type: HTML, Images, CSS, JS, and APIs

Overview

Cache TTL, or time to live, defines how long an object can be reused before the cache needs to revalidate it or fetch a fresh copy from origin. In edge caching and CDN for websites, TTL is one of the simplest settings to change and one of the easiest to misapply. If the value is too short, you give up performance and send unnecessary traffic to origin. If it is too long, you risk serving outdated responses or creating purge pressure every time something changes.

The practical way to think about TTL is by content type. Different classes of content have different update patterns, personalization needs, and risk profiles. A homepage, a logo image, a versioned stylesheet, a product inventory API, and a user dashboard should not share the same cache policy.

As a working reference, the ranges below are a useful starting point:

• HTML for frequently updated public pages: 1 to 10 minutes
• HTML for stable public pages: 10 to 60 minutes
• Images with stable filenames: 1 day to 30 days
• Versioned images and media: 30 days to 1 year
• Versioned CSS and JS: 30 days to 1 year
• Unversioned CSS and JS: 5 minutes to 1 day, depending on deployment frequency
• Public API responses: 30 seconds to 5 minutes
• Semi-static API responses: 5 to 30 minutes
• Personalized or sensitive responses: bypass cache or use private browser caching only

These are not hard rules. They are durable defaults. The right TTL depends on how often content changes, whether URLs are versioned, whether purge is reliable, and whether stale content is merely inconvenient or operationally harmful.

If you are designing edge caching from scratch, it helps to separate three decisions: what is cacheable, where it is cacheable, and for how long. TTL only answers the third question. Many cache problems that look like TTL issues are actually cache bypass rules, cookie variation, or missing versioning. For deeper diagnosis, see How to Diagnose a CDN Cache MISS: A Step-by-Step Troubleshooting Checklist.

Core concepts

This section gives you a practical model for setting TTL by content type rather than by guesswork.

1. TTL should follow change frequency and blast radius

The more often something changes, the shorter the TTL usually needs to be. But change frequency alone is not enough. You also need to ask what happens if users receive an older response for a few minutes.

For example:

• A homepage banner being briefly stale is usually acceptable.
• A pricing table being stale may be risky.
• An account page must not be cached publicly at all.
• A fingerprinted JavaScript bundle can safely live at the edge for a very long time.

In other words, TTL is partly a content decision and partly a risk decision.

2. HTML usually needs shorter TTLs than static assets

Public HTML changes more often, pulls together multiple moving parts, and is more visible when stale. Even on sites with strong website caching, HTML commonly gets shorter edge TTLs than CSS, JS, fonts, and images.

A reasonable pattern for public HTML is:

• News or active publishing pages: 1 to 5 minutes
• Marketing pages edited occasionally: 10 to 30 minutes
• Documentation or evergreen guides: 30 to 60 minutes, sometimes longer if purge is dependable

If you operate a reverse proxy cache in front of origin, you may combine a short edge TTL with conditional revalidation to improve TTFB without making updates difficult. If you are comparing layers, Reverse Proxy Cache vs CDN: What’s the Difference and When Do You Need Both? is a useful companion read.

3. Versioning changes the TTL conversation

The safest way to use long TTLs for static asset TTL is to version file URLs. That usually means adding a hash or build identifier to filenames or query parameters that are treated as unique objects by your caching layer. Once an asset URL changes on deploy, the old object can remain cached for months without harming users because new pages will request the new URL.

This is why versioned CSS and JS often get the longest TTLs in a site stack. For versioned assets, 30 days to 1 year is common guidance. Without versioning, long TTLs become harder to manage because users may continue requesting stale files after a release.

If you need a deeper implementation guide, see How to Cache Static Assets for Faster Core Web Vitals.

4. APIs need policy by endpoint, not one global TTL

API cache TTL should be assigned endpoint by endpoint. Some API responses are ideal for edge caching, especially if many users request the same result. Others are personalized, authenticated, or time-sensitive and should bypass public caches.

A practical API caching strategy often looks like this:

• Shared public configuration or metadata: 5 to 30 minutes
• Frequently requested public lists or search defaults: 30 seconds to 5 minutes
• Inventory, availability, or fast-changing counts: very short TTLs, revalidation, or no shared caching
• User-specific responses: bypass shared cache

When teams set one blanket TTL for all APIs, they often under-cache the stable endpoints and over-cache the risky ones.

5. Purge capability affects how aggressive you can be

Longer TTLs work best when you have predictable cache purge processes. If your team can purge by URL, tag, prefix, or deployment event, you can safely keep more content at the edge for longer. If purging is manual, partial, or error-prone, shorter TTLs may be more forgiving.

That tradeoff matters for HTML and APIs more than for versioned assets. A stable purge workflow gives you freedom. A weak purge workflow often forces caution. If invalidation has caused outages or stale pages in the past, review How to Purge CDN Cache Without Breaking Your Site.

6. TTL is not the same as browser caching

Many teams discuss TTL as if there is only one cache. In practice, your origin, reverse proxy cache, CDN, and browser may all store responses differently. The same object can have one effective lifetime at the edge and another in the browser. That distinction matters when you need fast repeat views without overcommitting to a long browser cache.

For example, you may want HTML to live briefly at the CDN but revalidate often in the browser, while keeping versioned CSS and JS cached aggressively in both places.

Practical TTL reference by content type

Use this as a starting matrix and adjust based on publishing cadence, purge confidence, and personalization:

• Homepage and listing HTML: 1 to 10 minutes
• Article and documentation HTML: 10 to 60 minutes
• Landing pages with infrequent edits: 30 to 120 minutes
• Category pages with filters or sort variants: short TTLs plus careful cache-key rules
• Images without URL versioning: 1 to 7 days
• Versioned images, icons, logos, downloadable media: 30 days to 1 year
• Versioned CSS and JS bundles: 30 days to 1 year
• Unversioned CSS and JS: 5 minutes to 1 day
• Fonts: 30 days to 1 year if versioned
• Public JSON feeds: 1 to 15 minutes
• Public API responses with moderate churn: 30 seconds to 5 minutes
• Authenticated HTML and APIs: no shared caching by default

Related terms

TTL decisions become clearer when a few related caching terms are kept separate.

Freshness lifetime

This is the period during which a cached object can be served without checking origin. TTL is the operational shorthand, but the broader concept is freshness.

Revalidation

When an object is stale, a cache can ask origin whether it has changed instead of downloading the full response. This is useful for HTML and APIs where short freshness windows still benefit from conditional requests.

Cache hit ratio

The percentage of requests served from cache instead of origin. TTL affects this directly, but so do cache keys, bypass rules, cookies, and query string handling. If your hit ratio remains low after raising TTL, the issue may be elsewhere. See How to Improve Cache Hit Ratio on a CDN.

Cache key

The set of request attributes used to decide whether two requests map to the same cached object. URL path, host, query strings, headers, device variations, and cookies can all affect it. A short TTL cannot rescue a fragmented cache key.

Bypass rules

Rules that prevent objects from being stored or served from cache under certain conditions, such as authentication cookies, cart sessions, admin routes, or special headers. On dynamic sites, bypass logic often matters more than the exact TTL number. For examples, review CDN Cache Bypass Rules Explained: Cookies, Query Strings, and Headers.

Stale content and stale serving

Stale content simply means an older version of a response is being served. In some architectures, serving stale content briefly during origin trouble or revalidation can improve resilience. Whether that is acceptable depends on the content type.

Purge and invalidation

Removing cached objects before their TTL expires. Purge makes long TTLs viable for assets and some HTML, but it should not be used as a substitute for clear content classification.

Practical use cases

The easiest way to build a durable cache TTL strategy is to classify your content, assign defaults, and refine from production behavior.

Use case 1: Content-heavy marketing or publishing site

For a site with articles, landing pages, and media assets, a practical setup might be:

• Homepage and category pages: 1 to 5 minutes
• Articles and guides: 10 to 30 minutes
• Images and fonts: 30 days or longer if versioned
• CSS and JS bundles: 1 year if versioned

This keeps HTML reasonably fresh while allowing static files to do most of the heavy lifting for website speed optimization.

Use case 2: WordPress site with editorial updates

WordPress caching often breaks down when teams treat all pages the same. A better model is:

• Cache public posts and pages at the edge with short to moderate HTML TTLs.
• Bypass admin, preview, login, and personalized areas.
• Use long TTLs for theme assets and media when URLs are versioned.
• Purge or warm key URLs after publishing.

If the site includes carts, account areas, or logged-in traffic, apply route-based exceptions carefully. For plugin-side considerations, see Best WordPress Caching Plugins Compared. For store-specific exceptions, see WooCommerce Caching Rules: What to Cache and What to Bypass.

Use case 3: E-commerce catalog with dynamic inventory

E-commerce needs different TTLs for different layers of the same experience:

• Category and collection pages: short TTLs, often 1 to 5 minutes
• Product detail pages: 1 to 10 minutes depending on inventory volatility
• Static assets: long TTLs with versioning
• Cart, checkout, account, and personalized pricing: bypass shared cache

In this environment, overcaching HTML can create business risk, while undercaching assets wastes bandwidth and increases origin pressure.

Use case 4: Public API behind a CDN

For APIs, start with endpoint classes:

• Reference data: longer TTLs
• Frequently polled data: short TTLs and revalidation
• Per-user data: no edge caching

Then audit variation. If response output changes by authorization header, locale, device, or query string, make sure your cache key and bypass rules reflect that reality. Otherwise stale or incorrect API responses can appear even when TTL seems conservative.

Use case 5: Teams optimizing cost as well as speed

TTL affects performance, but it also affects bandwidth, origin compute, and operational load. Longer-lived cacheable assets reduce repeated origin requests and can improve economics, especially on traffic spikes. But long TTLs on fragile dynamic content can increase support work and purge frequency. Cost-sensitive teams should model cacheability before comparing providers. A helpful planning companion is CDN Pricing Comparison Calculator Inputs: What Costs to Estimate Before You Choose.

A simple implementation checklist

1. Inventory content by type: HTML, media, CSS, JS, fonts, API endpoints.
2. Mark each class as public, private, or conditional.
3. Estimate update frequency and stale-risk for each class.
4. Use versioned URLs for deployable static assets wherever possible.
5. Assign default TTL ranges by class instead of one sitewide value.
6. Document bypass rules for login, admin, carts, sessions, and personalization.
7. Test cache behavior with real headers and repeated requests.
8. Measure cache hit ratio, origin load, and TTFB after changes.
9. Add purge procedures for the content types that need fast invalidation.

When to revisit

A TTL policy should be treated as a living reference, not a one-time setup. Revisit it when your content model, traffic pattern, or tooling changes.

Good triggers for review include:

• You launch a new section of the site with different publishing cadence.
• You move from unversioned to versioned asset builds.
• You add personalization, carts, memberships, or logged-in features.
• You change CDN, reverse proxy cache, or origin behavior.
• Cache purge becomes more reliable, or less reliable.
• Cache hit ratio drops after an app release.
• Users report stale pages after deploys or content edits.
• You start optimizing for lower origin cost, not only faster delivery.

The practical habit is to review TTL policy on a schedule, such as quarterly, and after meaningful architecture changes. Keep the policy in a short internal document that lists content classes, TTLs, exceptions, purge steps, and owners. That makes it easier to update without rediscovering the same debates.

If performance or freshness problems appear, do not change only the TTL and hope for improvement. Validate the full path: cache-control headers, cache keys, cookies, query strings, bypass rules, and purge events. TTL is only one part of website caching. A careful review usually delivers better edge caching outcomes than simply making every value shorter.

As a final action step, build your own site-specific TTL table using the ranges in this article, then test one content class at a time. Start with versioned static assets, because they are usually the safest win. Move next to public HTML with short TTLs and clear purge behavior. Leave personalized and sensitive responses out of shared cache unless you have strong controls. That sequence keeps risk low while steadily improving performance.