What Is Long Cache TTL? Complete Guide (2026)

Why Long Cache TTL Matters for Performance

A short or missing cache TTL means every page view re-downloads CSS, JS, fonts, and images that haven't changed. The cost compounds across five places:

• Time to First Byte (TTFB):additional asset requests delay the user's next render. With proper caching, repeat visits hit the browser cache and skip the network entirely for those files.
• Bandwidth waste: on a 500 KB JS bundle, every cache miss costs the user 500 KB they paid for once already.
• Mobile performance: repeat-visit speed-ups are most pronounced on slower mobile networks where every request roundtrip costs hundreds of milliseconds.
• Server load: serving cacheable assets repeatedly burns origin CPU and bandwidth that could be saved by upstream caches.
• Core Web Vitals:faster repeat-visit LCP and reduced INP both benefit when the browser doesn't need to re-acquire render-blocking resources.

The Pattern: Long Cache + Content Hashing

The reason a 1-year cache TTL is safe is because production builds emit asset filenames containing a content hash. When the file's contents change, the hash changes — and the URL becomes a brand-new resource the browser has never cached.

<!-- Today's build -->
<script src="/assets/main.a3f7c2.js"></script>

<!-- Tomorrow's build (after a code change) -->
<script src="/assets/main.b91d44.js"></script>

Because the URL itself changed, there is no "stale cache" problem — the browser simply has no copy of main.b91d44.js and fetches it fresh. The previous file (main.a3f7c2.js) sits unused in the cache until eviction; that costs nothing because the user never requests it again.

This is why the right Cache-Control header for hashed assets is the most aggressive one available:

Cache-Control: public, max-age=31536000, immutable

• public — any cache (browser or shared) may store it.
• max-age=31536000 — store it for one year.
• immutable — promise the browser this URL will never serve different bytes, so it never needs to send a conditional revalidation request.

How to Check Your Site's Cache TTL

Cache TTL is set per response by the server (or origin behind a CDN). The fastest ways to audit it:

• Greadme deep scan — surfaces every static asset with a TTL under the recommended threshold, names the offender, and pairs each finding with a one-click GitHub PR for the fix.
• Greadme crawler scan — checks cache headers across every indexable page, so you can see whether the regression is local to one route (a misconfigured static folder) or sitewide.
• Greadme AI visibility analyzer — connects performance findings (including cache regressions) to AI-search outcomes by scoring how well each page is positioned to be cited.
• Chrome DevTools → Network panel — open a request, inspect the Response Headers, and look for Cache-Control. Any static asset under 30 days is a regression.
• web.dev Measure— the "Uses efficient cache policy on static assets" audit lists every flagged resource with its current TTL.
• Google Search Console → Crawl stats — indirectly visible through repeat-asset re-fetches by Googlebot when caching is too short.

8 Practical Ways to Set a Long Cache TTL

Cache-Control: public, max-age=31536000, immutable

Cache-Control: no-cache
# or
Cache-Control: public, max-age=300, must-revalidate

location ~* \.(js|css|woff2|png|jpg|svg)$ {
  expires 1y;
  add_header Cache-Control "public, max-age=31536000, immutable";
}

location / {
  expires -1;
  add_header Cache-Control "no-cache";
}

<FilesMatch "\.(js|css|woff2|png|jpg|svg)$">
  ExpiresActive On
  ExpiresDefault "access plus 1 year"
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

Common Caching Mistakes and Fixes

How TTL Strategies Compare

Different resource types need different cache policies. Use this table as the default starting point.

FAQ

What is the recommended Cache TTL for static assets?

One year — 31,536,000 seconds — combined with content-hashed filenames. The full recommended header is Cache-Control: public, max-age=31536000, immutable. Audits flag any static resource with a TTL under 30 days.

What does the immutable directive do?

immutable tells the browser the URL will never serve different bytes. With it set, the browser doesn't even send a conditional revalidation request — it just uses the cached copy until max-age expires. Use it only on URLs that change when content changes (i.e., hashed asset URLs).

Should HTML have a long cache TTL?

No. HTML is the entry point that references hashed asset URLs. If HTML is long-cached, users can get stuck pointing at deleted hashes. Use Cache-Control: no-cache or a short max-age (60–300 seconds) so the browser revalidates HTML on each visit.

How do I invalidate a long-cached asset if it's broken?

Change the URL. Because production assets are content-hashed, any code change automatically produces a new filename. Users will request the new URL on their next visit; old URLs sit unused in caches until eviction. There is no "purge" needed.

What's the difference between max-age, expires, and s-maxage?

max-age is the modern way to set TTL in seconds. Expires is the legacy header expressing an absolute date. s-maxage applies only to shared caches (CDNs, proxies) and overrides max-age there. Prefer max-age for browser caching and add s-maxage only when you need different shared-cache behaviour.

Does long cache TTL affect AI search engines like ChatGPT and Perplexity?

Indirectly. AI answer engines and Google AI Overviews preferentially cite pages that already rank well — and short-TTL repeat-visit penalties feed into Core Web Vitals and Page Experience scores. Faster repeat visits also mean Googlebot and AI crawlers pull less data per crawl, reducing crawl budget pressure on your origin.

Will long caching break my deploys?

Only if you long-cache without content-hashing. The combination of max-age=31536000, immutable + hashed filenames is safe by construction: every deploy emits new URLs the browser has never cached. The risk only appears if you long-cache unhashed filenames.