How webpack implements static resource caching

introduction

Static resource caching is a point of front-end performance optimization, so in the front-end development process, the cache is generally used to the maximum extent (mainly strong caching here). Back to the topic of this article, in a project built with webpack, if you are not careful, even if the server sets a cache strategy, the built project may not be able to achieve static resource caching. So how can webpack achieve the effect of using cache? Let's talk about this issue below.

Distinguish between several different hashes

We all know that webpack has various hash values, including each project build hash , chunkhash of different entries, and contenthash of the file content. With so many hashes, what are the differences between them?

hash

Hash is related to the entire webpack build project. The value corresponding to the hash is different each time the project is built, even if the project file has not been "modified".

In fact, it has been modified, because each time webpack is packaged and compiled, the webpack runtime code will be injected, causing changes to the entire project, so the hash value will change every time.

Taking my project code as an example, here is a comparison of the code before and after two builds without any modification.

It can be seen that the hash of the corresponding project builds has changed twice. It can be inferred that caching cannot be achieved using this method because the hash changes every time.

chunkhash

Chunkhash, as the name suggests, is related to the chunk packaged by webpack. Specifically, webpack analyzes the dependencies of the entry configuration file and builds the chunk of the entry based on it, and generates the corresponding hash value. Different chunks will have different hash values. Generally, in a project, the public dependency library and program entry files are isolated and packaged separately, and chunkhash is used to generate hash values. As long as the public dependency library remains unchanged, the corresponding chunkhash will not change, thus achieving the purpose of caching.

Generally, chunkhash is used for webpack entry in the project, which is specifically reflected in the output configuration item:

module.exports = {
  entry: {
   app: './src/main.js',
   vendor: ['react', 'redux', 'react-dom', 'react-redux', 'react-router-redux']
  },
  output: {
    path:path.join(__dirname, '/dist/js'),
    filename: '[name].[chunkhash].js'
  }
 ...
}

Finally, the chunkhash compilation results of app and vendor are as follows

contenthash

Contenthash represents the hash value generated by the file content. Different contents generate different contenthash values. In a project, the usual practice is to extract the CSS in the project into corresponding CSS files for reference. For example, use it in webpack configuration like this:

module.exports = {
  ...
  plugins: [
     new ExtractTextPlugin({
	filename: 'static/[name]_[chunkhash:7].css',
	disable: false,
	allChunks: true
     })
  ...
  ]

There is a problem with the above configuration because chunkhash is used and it shares chunkhash with chunks that depend on it.

For example, in the above app chunk example, it depends on an index.css file. The hash of index.css follows the chunkhash of the app. As long as the app file changes, even if the index.css file does not change, its hash value will also change, causing the cache to fail.

Then we can use the contenthash value in extra-text-webpack-plugin to ensure that even if the content of other files in the module where the css file is located changes, as long as the content of the css file remains unchanged, its hash value will not change.

Implementing js cache

The main function of the webpack plug-in CommonsChunkPlugin is to extract the common part of the webpack project entry chunk. The specific usage will not be introduced in detail. If you don’t know much about it, you can refer to the introduction on the webpack official website;

This plug-in is a commonly used optimization function in webpack projects and is used in almost every webpack project. Benefits of using this plugin:

• Improve webpack packaging speed and project size: extract all common codes from the chunk file at the webpack entry to reduce code size; at the same time, improve webpack packaging speed.
• Utilize the cache mechanism: Dependent public module files are generally rarely changed or never changed, so independent module files can be extracted and cached for a long time.

However, in the project, if the plug-in is opened incorrectly, the second point above cannot be achieved, because in this case:

The Entry Chunk packaged with the public code or library code that has not been modified will change with the changes of other business codes, causing the long cache mechanism on the page to fail.

So, let's open CommonsChunkPlugin correctly.

CommonsChunkPlugin incorrect usage

If we isolate the common libraries of our project such as react, react-dom, and react-router from the business code and extract them as vendor chunks, the webpack configuration is as follows:

const webpack = require("webpack");
const path = require('path');
module.exports = {
  entry: {
    app: "./src/main.js",
    vendor: ["react","react-dom", "redux", "react-redux", "react-router-redux"]
  },
  output: {
    path: path.resolve(__dirname, 'output'),
    filename: "[name].[chunkhash].js"
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({names: ["vendor"]})
  ]
};

In the above, some basic libraries of the project are packaged into a chunk called vendor, and business-related codes are packaged into a chunk called app;

The results of webpack packaging and compilation are as follows:

After we modify the business code app.js, the recompilation results are as follows:

It can be found that under the configuration of CommonsChunkPlugin, when the business code app changes, the library code also changes, and the vendor's chunkhash also changes. In this way, the name of the vendor's reference changes, causing the long cache mechanism on the browser to fail.

What causes the problem

The reasons why vendor changes every time webpack is compiled:

Webpack generates some runtime code every time it builds. When there is only one file, the runtime code is stuffed directly into that file. When there are multiple files, the runtime code will be extracted into the common file, that is, the vendor chunk configured by CommonsChunkPlugin above.

The runtime code generated by webpack each time it compiles, including the definition of the global webpackJsonp method and the maintenance of module dependencies, can be found here>>.

Therefore, in the CommonsChunkPlugin configuration of webpack above, these codes will be packaged into the vendor every time they are compiled, causing the chunkhash of the vendor to change every time.

Then, we can configure the vendor chunk and extract the common code, that is, the webpack runtime code, so that the basic library modules that the project depends on can be isolated from the business modules. Because these files will not be modified, these files can achieve the effect of long cache. The specific configuration is as follows:

module.exports = {
  entry: {
    app: "./app.js",
    vendor: ["react","react-dom", "redux", "react-redux", "react-router-redux"]
  },
  ....
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({names: ["vendor"]}),
    new webpack.optimize.CommonsChunkPlugin({
        name: 'manifest',
        chunks: ['vendor']
    })
  ]
};

In this way, even if the business app code is modified, the vendor chunk of the basic library that the project depends on will not change; only the extracted manifest chunk will change each time, but the size of this file is very small, and this method has greater benefits than vendor. As shown below:

The package compilation result after modifying the app code is as follows. You can see that the vendor chunkhash has not changed.

There are a few things to note when configuring CommonsChunkPlugin in webpack:

1. When configuring the output item of webpack, its filename and chunkFilename must use chunkhash. Do not use hash, otherwise the expected effect will not be achieved even with the above configuration. As for the difference between hash and chunkhash, please refer to github's answer

2. For file-loader used to extract static resources such as pictures and fonts, the configured hash represents the content hash value of the static file, not the hash value generated by webpack each time it is packaged and compiled. Remember! ! !

3. For the extracted CSS style files, you need to use contenthash , which has the same meaning as hash in file-loader . This cannot be chunkhash, otherwise it will be consistent with the chunkhash of the entry chunk from which the style file is extracted, which will not achieve the purpose of caching.

Implementing CSS caching

Webpack implements CSS caching by using the contenthash introduced above. The hash attribute value is actually calculated by extra-text-webpack-plugin . To implement CSS caching, you can use contenthash as follows

module.exports = {
  ...
  plugins: [
     new ExtractTextPlugin({
	filename: 'static/[name]_[contenthash:7].css',
	disable: false,
	allChunks: true
     })
  ...
  ]

Implement image/font caching

For static resources such as pictures and fonts, when using webpack to build and extract, file-loader is actually used to complete it, and the corresponding file hash value is calculated by the corresponding file-loader . So what hash values ​​are used for these static files? In fact, they are hash attribute values. As shown in the following code:

module.exports = {
 ...
 rules:
   ...
    {
      test: /\.(gif|png|jpe?g)(\?\S*)?$/,
      loader: require.resolve('url-loader'),
      options:
        limit: 10000,
        name: path.posix.join('static', '[name]_[hash:7].[ext]')
      }
    },
    font:
      test: /\.otf|ttf|woff2?|eot(\?\S*)?$/,
      loader: require.resolve('url-loader'),
      options:
        limit: 10000,
        name: path.posix.join('static', '[name]_[hash:7].[ext]')
      }
    }
 ]
}

You can see that the hash attribute value is used above. This hash is not the hash that webpack builds each time the project is built. It is calculated by file-loader based on the file content. Don't mistake it for the hash built by webpack.

refer to

1. Correct way to open CommonsChunkPlugin of webpack
2. Webpack pit-filling road-extracting independent files (modules)
3. Webpack code splitting skills
4. I heard that you use webpack to process the hash of the file name? Then I suggest you check whether the hash you generated is correct.
5. chunkhash
6. Multiple-commons-chunks
7. Use webpack to implement persistent caching
8. The difference between hash and chunkash in Webpack, and the hash fingerprint decoupling solution for js and css

This is the end of this article about how to implement static resource caching with webpack. For more relevant webpack static resource caching content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!