The official Webpack documentation states that code separation is one of the most compelling features of Webpack. This feature enables you to separate code into different bundles and load these files on demand or in parallel. Code separation can be used to obtain smaller bundles and control resource load priorities, which, when used properly, can greatly affect load times.

In order to optimize chunk separation, it is necessary to know which chunk packages are of large size to determine the direction. Vue-cli3.0 is taken as an example to start the optimization journey of Webpack packaging and chunk separation.

Vue-cli3 has the default build configuration, and the package result is as follows:

Webpack4.0 upgrade later, CommonsChunkPlugin removed, by optimization. The splitChunks and optimization runtimeChunk configuration is replaced.

Webpack automatically separates chunk packets based on the following conditions:

  • From the public module node_modules
  • Package size before compression greater than 30kb (default)
  • Load a maximum of 5 chunk packages for parallel requests on demand (default)
  • First screen Initial loading parallel requests The number of Chunk packages does not exceed three (default)

SplitChunksPlugin Default configuration:

optimization: {
        minimize: false,
        splitChunks: {
            chunks: 'all',// indicates the range of blocks to display. There are three optional values: initial(initial block), async(load block on demand), and all(default=all). name:true// Chunk Names. The default value is the Chunk name and the Chunk namehashAutomatic value generation; MinChunks: 1,// How many times modules are referenced before they are split (default=1) minSize: 30000,// Minimum size of code blocks (default=30000) maxAsyncRequests: MaxInitialRequests: 3,// maxInitialRequests: 3,// automaticNameDelimiter:'~', cacheGroups: {// Can inherit/override all the parameter values of splitChunks above, vendors: {name:"vendors",
                    chunks: "all".test: /node_modules\//,// indicates that modules are filtered. The default value is all modules, which can match the module path or the chunk name. When matching the chunk name, all modules in it will be selected. Priority: 10,// indicates the extraction weight. A larger number indicates a higher priority. Because a module may satisfy multiple cacheGroups conditions, the highest weight determines which one to extract; reuseExistingChunk:true// Indicates whether to use the existing chunk, if yestrueIf the current chunk contains modules that have been extracted, no new ones will be generated. }, commons: { name:"commons",
                    chunks: "initial",
                    minChunks: 2
                }
            }
        },
        runtimeChunk: {
            name: "manifest"}}Copy the code

However, the default build configuration ends, and the public vendor package size is obviously too large, which affects the loading performance. The size of each chunk packet should not be larger than 30kb.

The next step is to continue separating the vendors packages.

Optimized configuration:

optimization: {
      splitChunks: {
        chunks: "all",
        minSize: 30000,
        maxAsyncRequests: 5,
        maxInitialRequests: 5,
        cacheGroups: {
          vue: {
            test: /[\\/]node_modules[\\/](vue)[\\/]/,
            name: "vue",
            priority: 2
          },
          router: {
            test: /[\\/]node_modules[\\/](vue-router)[\\/]/,
            name: "vue-router",
            priority: 2
          },
          vendors: {
            test: /[\\/]node_modules[\\/]/,
            name: "vendors",
            priority: 1,
            reuseExistingChunk: true
          }
        }
      },
      runtimeChunk: {
        name: "manifest"}}Copy the code

The project is rebuilt with the following results:

Conclusion: This is just a practice for optimizing splitChunks’ chunk packaging strategy, and how to formulate the strategy depends on the actual business.