Static assets use content-hash filenames for cache busting

Without content-hash filenames, long-lived cache headers create a contradiction: you want assets cached forever, but you also need users to get updated JavaScript after a deploy. Non-hashed filenames like main.js force a compromise — either short caches that cause repeat downloads, or long caches that serve stale JavaScript after deploys. Content hashing resolves this: main.a3f92b.js is immutable by definition — the hash changes whenever the content changes, guaranteeing users always get the latest code on deploy while keeping the file cached indefinitely between deploys. ISO 25010 performance-efficiency.resource-utilization requires that caching strategies actually eliminate redundant transfers.

Enable content hashing in your build configuration. Next.js generates hashed filenames for all chunks by default — no Webpack configuration required. For Vite or custom Webpack setups, configure the output filename templates.

// Next.js — no configuration needed
// Build output: .next/static/chunks/main-a3f92b8d.js (hashed automatically)

// Vite — vite.config.ts
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        entryFileNames: '[name].[hash].js',
        chunkFileNames: '[name].[hash].js',
        assetFileNames: '[name].[hash][extname]'
      }
    }
  }
})

// Webpack — webpack.config.js
module.exports = {
  output: {
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].chunk.js'
  }
}

Verify by running your build and confirming filenames in the output directory contain hash strings.