What are the recommended caching headers for Next.js pages and assets?
Quick Answer: For Next.js pages, use cache-control policies based on render mode: fully static pages and immutable build assets should be cached at the CDN and browser level with long TTLs, while SSR, personalized, or frequently changing routes should use `Cache-Control: no-store` or short `s-maxage` with `stale-while-revalidate`. For static assets like `/_next/static/*`, the recommended approach is `public, max-age=31536000, immutable` because filenames are content-hashed and safe to cache aggressively.
Detailed Explanation
The optimal caching strategy in Next.js is to separate content by volatility. Static pages generated at build time and hashed assets can be cached aggressively to reduce origin load and improve TTFB, while dynamic pages that depend on cookies, auth state, query parameters, or real-time data should avoid browser caching or rely on short shared-cache directives with revalidation. In practice, this means long-lived cache headers for versioned assets and ISR-generated content, and conservative headers for SSR or user-specific responses. When deploying behind a CDN, combine `s-maxage` for edge caching with `stale-while-revalidate` to preserve performance without sacrificing freshness.
Key Technical Drivers
- Use `Cache-Control: public, max-age=31536000, immutable` for versioned static assets such as `/_next/static/*`, images with hashed filenames, and other build artifacts that never change in place.
- For ISR or CDN-cached pages, prefer `Cache-Control: public, s-maxage=
, stale-while-revalidate= ` so the edge can serve fast responses while refreshing content asynchronously. - For personalized SSR pages, authenticated routes, or data that changes on every request, set `Cache-Control: no-store` or at minimum `private, no-cache, must-revalidate` to prevent serving stale user-specific content.