Asset fingerprinting (content hashing)
A content hash in each asset filename makes changed files get new URLs, while unchanged files stay safely cached.
See it
What it is
Asset fingerprinting puts a hash derived from a file's contents into its name, such as app.a1b2c3.js. Change the bytes and the URL changes; keep the bytes and the URL stays stable. That lets a CDN and browser cache the asset for a year while new HTML points to a fresh filename on the next release. The older trick was a query string like style.css?v=2; moving the hash into the filename is the version of that idea every cache and proxy actually respects.
Reach for it on production JavaScript, CSS, images, and fonts that come from a build pipeline. Pair hashed filenames with Cache-Control: public, max-age=31536000, immutable, and give HTML a short lifetime or require revalidation because HTML is the map to the current assets.
Gotcha: never overwrite the bytes at a fingerprinted URL. Caches are allowed to keep an immutable response without checking again. Also deploy new assets before new HTML and retain the previous assets long enough for open tabs and cached HTML, or those documents can request files the server has already removed.
Ask AI for it
Add content-hashed production assets to this webpack build. Set output.filename to '[name].[contenthash:8].js', configure MiniCssExtractPlugin with '[name].[contenthash:8].css', give asset modules hashed filenames, and let HtmlWebpackPlugin inject the current URLs. If this project builds with Vite, note that it content-hashes by default and only needs build.rollupOptions.output.entryFileNames, chunkFileNames, and assetFileNames confirmed. Serve hashed assets with Cache-Control: public, max-age=31536000, immutable; serve HTML with Cache-Control: no-cache. Upload assets before HTML, keep the previous release's assets during rollout, and prove that unchanged files retain their URL while one edited file receives a new hash.