Hash vs chunkhash vs ContentHash

Introduction

Recently i was going through some Github threads and i saw lot’s of people are pretty confused about the difference between “Hash vs chunkhash vs ContentHash”. So i thought of trying to clarify it. For this article we will go through following:

1. Why we require hashing.
2. Types of hashing.
3. Explain each type with usage.
4. slicing of hashes.

Why we require hashing:

Let’s try to understand why we require concept of hashes at first place. For each app we develop we try to have “long term caching of static content”. But if we will not update file paths, than browser will still serve cached resources for user. In other words, user won’t able to see updated features. So traditionally we used to add version for each file across new build like this.

app.js?build=1
vendor.css?build=1
main.css?build=1

So now-a-days we use webpack to build our resources with webpack as it’s very easier to use. So here comes the concept of hashing in webpack which allow us to generate new hashes for each chunk across new build. You can setup a basic webpack config which will do above for you.

const path = require('path');

module.exports = {
  entry: {
    vendor: './src/vendor.js',
    main: './src/index.js'
  },
  output: {
    path: path.join(__dirname, 'build'),
    filename: '[name].[hash].js'
  }
};

Above config will create following output.

Hash: 55e765r56798c278ytr6
Version: webpack 1.10.1
Time: 76ms
Asset Size Chunks Chunk Names
main.55e765r56798c278ytr6.js 1.43 kB 0 [emitted] main
vendor.55e765r56798c278ytr6.js 1.43 kB 1 [emitted] vendor
[0] ./src/index.js 46 bytes {0} [built]
[0] ./src/vendor.js 40 bytes {1} [built]

The problem with above webpack config implementation is that we are unable to achieve long term caching that browser provide as it create a new hash 55e765r56798c278ytr6 for each chunk. In ideal situation, we want to update only those chunks hashes for our new deployment/build, for which something really have changed on our development side. So that for next time user open our app after a new deployment, user don’t really have to download all the assets again from the server. They should only fetch resources which we have made changes for.

So now webpack provide option for using different type of hashing that you can use based on your requirements.

Types of Hashing:

Webpack provide three types of hashing as follow:

1. [hash]
2. [Chunkhash]
3. [Contenthash]

Let’s try to understand what are these different type of hashes and in which situation we should use them.

Hash:

Hash is corresponding to build. Each chunk will get same hash across the build. If anything change in your build, corresponding hash will also change.

Chunkhash:

Chunkhash is based on webpack entry point Each entry defined will have it’s own hash. If anything changes for that particular entry point than only corresponding hash will change.

Usage:

We surely want to take advantage of browser caching but using name.[hash].js for webpack output config will change each chunk across each build. In order to change hash of only that chunk for which there is corrosponding change in webpack entry, you need to use “chunkhash” instead of “hash”. In short you have to replace name.[hash].js with name.[chunkhash].js.

Note: In order to use browser caching properly, you will also have to add “NamedModulesPlugin” which allows webpack to use relative path instead of incremental id for naming modules. Finally you can also separate out menifest file from all your chunks, for more information you can check here.

Contenthash:

Contenthash is specfic type of hash created in ExtractTextPlugin and is calculated by extracted content not by full chunk content.

Usage:

In case of CSS, if you use name.[chunkhash].css in ExtractTextplugin, you will get same resulted hash for both css and js chunk. Now if you will change any CSS, your resulting chunkhash will not get changed. So in order to work that properly, you need to use name.[contenthash].css. So that when there is change in CSS, your path for css will change in index.html.

It’s recommended to use hash/chunkhash/contenthash for production environment as it increase compilation time. You can also use specific part of hash based on your unique requirement.

Slicing Hashes:

webpack also allow slicing of hashes. If you will write [hash:8] instead of [hash] than you will get 8c4cbfdb instead of 8c4cbfdb91ff93f3f3c5.

Reference Link:

1. https://codeburst.io/long-term-caching-of-static-assets-with-webpack-1ecb139adb95
2. https://webpack.js.org/concepts/manifest/
3. https://survivejs.com/webpack/optimizing/adding-hashes-to-filenames/
4. http://blog.techhysahil.com/uncategorized/migration-webpack-2/
5. https://webpack.js.org/guides/caching/