Skip to main content

HTTP

Cache-Control Headers: Making Repeat Visits Fast

Tell browsers and CDNs how long to reuse your assets.

Quick answer

Cache-Control is an HTTP response header that tells browsers and CDNs whether and how long to store a copy of a resource. Correct caching makes repeat visits dramatically faster and reduces server load, while wrong settings serve stale content or prevent caching entirely.

Without caching, every page load re-downloads every asset. Cache-Control directives like max-age, no-cache and immutable let you control freshness: long-lived cache for versioned static files, short or revalidated cache for HTML and APIs.

Check your website

See how your site handles cache-control headers: making repeat visits fast — free, no account needed.

For business owners

Caching is free performance. A visitor who returns to your site should load instantly from their browser cache instead of waiting for your server again. Good cache headers cut hosting costs, improve Core Web Vitals and make the site feel professional on repeat visits.

How it works (technical)

Common directives:

  • Cache-Control: public, max-age=31536000, immutable — cache versioned assets (CSS/JS with hashes) for a year.
  • Cache-Control: no-cache — may store but must revalidate before use (good for HTML).
  • Cache-Control: private — only the user's browser, not shared CDNs.
  • ETag / Last-Modified — enable 304 Not Modified responses to save bandwidth.

Use fingerprinted filenames for static assets so you can cache aggressively. HTML usually gets short TTLs or no-cache with revalidation so content updates propagate quickly.

Real-world example

A SaaS dashboard set no cache headers, so every navigation re-fetched large JavaScript bundles. Adding long max-age for hashed static files and no-cache with ETag for HTML cut repeat-load time by more than half and reduced origin traffic sharply.

Why it matters

Caching directly improves load time, TTFB perception and server efficiency. Performance scanners flag missing or weak cache headers as an easy optimisation.

How to fix it

  1. Set long max-age (with immutable) for versioned static assets.

  2. Use no-cache or short TTL for HTML and dynamic API responses.

  3. Add ETag or Last-Modified for efficient revalidation.

  4. Configure CDN edge caching to match your Cache-Control policy.

  5. Verify headers with browser DevTools or curl -I.

Best practices

  • Fingerprint static asset filenames so aggressive caching is safe.

  • Separate cache policy for HTML (fresh) vs assets (long-lived).

  • Purge CDN cache deliberately when you deploy breaking changes.

Common mistakes

  • Caching HTML aggressively so users see stale content for days.

  • Setting no-store on everything and preventing any browser cache.

  • Forgetting to version filenames, then caching old JS after a deploy.

Frequently asked questions

What is the difference between no-cache and no-store?

no-cache allows storage but requires revalidation before use. no-store forbids storing the response at all. HTML often uses no-cache; sensitive data uses no-store.

How long should I cache images?

If URLs are stable, months to a year is fine. If you replace images in place without changing the URL, use shorter TTLs or versioned paths.

Put this into practice

See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.

Scan your website free

See Pro plans · Create account