Performance

How to fix: Cache-Control headers

Cache-Control tells browsers and CDNs how long they may reuse a response instead of downloading it again.

Not sure whether your site has this problem? Check it in seconds.

Why it matters

Good caching makes repeat visits faster and reduces load on your server. Bad caching either re-downloads everything every time or serves visitors out-of-date pages.

How to check

Check the Cache-Control header on your CSS, JavaScript and image files in DevTools → Network.

How to fix it

Versioned/hashed assets

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

HTML pages

Cache-Control: no-cache

Nginx

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

Common mistakes

Long cache times on files whose names don't change (app.js): visitors keep the old version. Use hashed file names, or a short cache.
no-cache doesn't mean 'don't store': it means 'check with the server before reusing'. Use no-store for truly sensitive responses.

Frequently asked questions

Does Next.js handle this?

Next.js sets long-lived immutable caching on its hashed static assets by default; you mostly need to think about your own files and API responses.

Related guides

Response compression (gzip / Brotli)

Guidance is general. Test header and DNS changes on a staging copy first, and check your hosting provider's documentation for platform-specific steps.