SplitChunksPlugin quick start

preface

Before WebPack V4, CommonsChunkPlugin was used to extract common JS files and libraries, but the function of this plug-in is limited, can only pack the public file into a public file, load when entering the page, can only avoid repeated loading of files and libraries, and can not play to optimize the page loading speed.

With the release of WebPack V4, SplitChunksPlugin is a built-in extension that can be configured in Optimization.splitChunks without additional input. The plug-in can extract not only common files and libraries, but also files loaded on demand (that is, through import(‘.. /a.js’) dynamically imported files).

It is recommended that developers introduce asynchronously code that they do not need to use immediately (for example, code for logging in to pop-ups, code for clicking on events), which is the key to speeding up web pages. It is perfect to facilitate Preloading and fetching, which are outside the scope of this article. If you are interested in fetching, you can reference it.

The default configuration

If you don’t manually configure Soptimization.plitchunks, webPack will split the code according to the default configuration.

module.exports = {
  / /...
  optimization: {
    splitChunks: {
      chunks: 'async'.minSize: 30000.maxSize: 0.minChunks: 1.maxAsyncRequests: 5.maxInitialRequests: 3.automaticNameDelimiter: '~'.name: true.cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/.priority: - 10
        },
        default: {
          minChunks: 2.priority: - 20.reuseExistingChunk: true}}}}};Copy the code

The default configuration roughly means:

By default, only modules introduced on demand are split;
fromnode_modulesFor modules that have been referenced twice or more, code splitting is performed;
Partitioned modules must be larger than 30KB (before code compression);
When loading on demand, the number of parallel requests must be less than or equal to 5;
When the initial page loads, the number of parallel requests must be less than or equal to 3;

Interpretation of Configuration Parameters

What is “chunks” in SplitChunksPlugin?

Generally speaking, “chunks” refer to files that are sent to webpack for processing, such as JS/CSS/IMG files. Modules or files imported through import are referred to as “chunks”.

splitChunks.chunks

Optional value: function (the chunk) | initial | async | all

Initial indicates a module that is not dynamically introduced in the entry file
All Indicates all modules
Async indicates the module that is introduced asynchronously

The configuration is as follows:

// src/index.js 
// Static import
import lodash from 'lodash' // Size about 529KB (compressed)
// Dynamic import
import(/*webpackChunkName:"jquery"*/ 'jquery') // Size about 281KB (compressed)
Copy the code

// webpack.config.js
module.exports = {
  / /...
  optimization: {
    splitChunks: {
      chunks: 'async'}}};Copy the code

When configured with chunks: ‘async’ (the default), the packaging results are as follows:

Cause analysis:

The chunks that are introduced dynamically are coded separately, so only the jquery code is packaged separately into vendors~jquery.js, and the LoDash code is not packaged separately, but into the index.js file.

Change the configuration to chunks: ‘INITIAL’ and the package result is as follows:

Cause analysis:

Both dynamically imported and statically imported code are split into separate files.

Change the configuration to ‘chunks: ‘all’ and the package result is as follows:

Cause analysis:

The result looks similar to initial, but there is a difference. If set to all, the static and dynamic module code is packaged into a chunk. The difference is that both packages are larger than 30KB, which matches the minSize rule. If both packages are less than 30KB in size, they will be packaged into a single file, which will not be demonstrated here. If you are interested, try it out for yourself.

Modify the index.js file as follows:

// src/index.js 
import lodash from 'lodash'
Copy the code

Repacking results are as follows:

Cause analysis:

Lodash is split into venders~index.js because LoDash was introduced directly in the entry file.

splitChunks.minSize

The configuration is as follows:

// src/index.js 
// Static import
import lodash from 'lodash' // Size about 529KB (compressed)
Copy the code

// webpack.config.js
module.exports = {
  / /...
  optimization: {
    splitChunks: {
      chunks: 'all'.minSize: 600000}}};Copy the code

Packing results are as follows:

Cause: minSize is set to 600KB, but the loDash library size does not exceed 600KB, so no code splitting is done.

splitChunks.maxSize

More than a single module size maxSize (and greater than minSize), will conduct code division, priority minSize > maxSize > (maxInitialRequests/maxAsyncRequests), 0 means no attempt to large volume of module partition, If you set a value (the default value of 30000), so when a single module is beyond this value, will try to the module division, and ignore the maxInitialRequests/maxAsyncRequests the two parameters.

splitChunks.minChunks

When the number of references exceeds this value, code splitting is performed (except for dynamic import).

The configuration is as follows:

// src/index.js 
// Static import
import(/*webpackChunkName:"a"*/ './a.js')
import(/*webpackChunkName:"b"*/ './b.js')
Copy the code

// src/a.js 
import 'jquery'
Copy the code

// src/b.js 
import 'jquery'
Copy the code

// webpack.config.js
module.exports = {
  / /...
  optimization: {
    splitChunks: {
      chunks: 'all', minChunks:2}}};Copy the code

Packing results are as follows:

Cause analysis: minChunks are 2, and jquery is introduced in module A and module B, which meets the condition that modules are introduced twice. Therefore, code segmentation is performed for jquery.

splitChunks.maxAsyncRequests

MaxAsyncRequests indicates that the number of asynchronous chunks that can be loaded in parallel after splitChunks are segmented by splitChunks codes does not exceed this value.

The configuration is as follows:

// src/index.js 
// Static import
import(/*webpackChunkName:"a"*/ './a.js')
import(/*webpackChunkName:"b"*/ './b.js')
Copy the code

// src/a.js 
import 'jquery'
Copy the code

// src/b.js 
import 'jquery'
Copy the code

// webpack.config.js
module.exports = {
  / /...
  optimization: {
    splitChunks: {
      chunks: 'all'.maxAsyncRequests: 1}}};Copy the code

Packing results are as follows:

Cause analysis:

Modules A and B both introduce jquery, but jquery is not packaged as a separate module, because if it were, both index.js and vendors would be loaded when entering the home page. This violates the limit that the number of asynchronous requests cannot be greater than 2. So modules A and B will be introduced into index.js as separate JS. If you open index.html, you can see that only one script tag, index.js, has been introduced.

splitChunks.maxInitialRequests

The maximum number of asynchronous requests that an entry file can make in parallel. 3 means that only 3 JS files are requested at most when the page first comes in, so the code split of an entry page cannot exceed 3 (even though a single file may be large). The configuration is as follows:

// src/index.js 
// Static import
import jquery from 'jquery'
import(/*webpackChunkName:"a"*/ './a.js')
Copy the code

// src/a.js 
import 'jquery'
Copy the code

// webpack.config.js
module.exports = {
  / /...
  optimization: {
    splitChunks: {
      chunks: 'all'.maxAsyncRequests: 1}}};Copy the code

Packing results are as follows:

Cause analysis:

Since maxAsyncRequests are set to 1, only one index.js is introduced into the index. HTML.

If maxAsyncRequests are set to 2, the packaging results in the following:

Jquery is packaged separately in wendors~index.js as maxAsyncRequests are set to 2, meaning that index. HTML can have up to two script tags.

splitChunks.automaticNameDelimiter

This parameter is used to configure the concatenation between the chunk name (vender) and the original name, for example, the ~in the middle of vender~index.js and vender~a.js.

splitChunks.name

Optional value: Boolean: true | function (module, chunks, cacheGroupKey) | string

The user specifies the segmentation module name. If this value is set to true, it is automatically generated based on chunks and cacheGroup keys

splitChunks.cacheGroups

In this group, the configuration of splitchunk. * can be automatically inheritance and overwritten. It also has its own configuration (test, Priority, reuseExistingChunk, Filename, Enforce)

CacheGroups are configured as follows:

module.exports = {
  / /...
  optimization: {
    splitChunks: {
      // ...
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/.priority: - 10
        },
        default: {
          minChunks: 2.priority: - 20.reuseExistingChunk: true}}}}};Copy the code

With cacheGroups, we can define custom chunk groups that are filtered by test criteria and assigned to the same group.
CacheGroups have two default groups, vendors, which match modules from the node_modules directory; A default contains modules shared by more than two chunks. Vendors take precedence over default.

CacheGroups. {cacheGroup}. The test attribute

Optional value, the function module, the chunk () | RegExp | string specifies some module belongs to the venders this buffer group, omit the test all modules

CacheGroups. {cacheGroup}. Also specify properties

A module can belong to more than one cache group. This attribute specifies the priority of the cache group. The default value is 0

CacheGroups. {cacheGroup}. ReuseExistingChunk properties

Repurposingchunks that already exist are not imported if chunks in the cache group already exist in the main Module, which is one of the reasons why cacheGroups exist.

CacheGroups. {cacheGroup}. The filename attribute

Used to specify the module name to match. If the filename attribute is not specified, the default chunk name is used.

CacheGroups. {cacheGroup}. Enforce attribute

Set to true said ignore splitChunks minSize, splitChunks. MinChunks, splitChunks. MaxAsyncRequests and splitChunks maxInitialRequests configuration, Generates chunks for the current cache group.

For example, when using the mini-CSs-extract-Plugin to package CSS files, you usually need to configure the cachegroups. {cacheGroup}.enforce attribute.


module.exports = {
  / /...
  optimization: {
    splitChunks: {
      // ...
      cacheGroups: {
        styles: {
          name: 'styles'.test: /\.css$/.chunks: 'all'.enforce: true,}}}}};Copy the code

As a result, the mini-CSS-extract-plugin automatically splits CSS styles into the DIST folder.

conclusion

SplitChunksPlugin: SplitChunksPlugin: SplitChunksPlugin: SplitChunksPlugin: SplitChunksPlugin If you find any problems, feel free to point them out in the comments section and I will make changes when I see them.

digression

To be honest, this article took nearly one day, because I also summarized it while learning. The last document was issued half a year ago, as expected, people are lazy! I hope I can learn more and write more articles in the future. Read the article is easy, write the article is difficult, because can not according to the official website, otherwise meaningless, each knowledge point to their own to verify, dare to send out to everyone to see, because do not want to mislead you.

Github link: github.com/linlif/webp…

(End of article)

preface

The default configuration

Interpretation of Configuration Parameters

splitChunks.chunks

splitChunks.minSize

splitChunks.maxSize

splitChunks.minChunks

splitChunks.maxAsyncRequests

splitChunks.maxInitialRequests

splitChunks.automaticNameDelimiter

splitChunks.name

splitChunks.cacheGroups

CacheGroups. {cacheGroup}. The test attribute

CacheGroups. {cacheGroup}. Also specify properties

CacheGroups. {cacheGroup}. ReuseExistingChunk properties

CacheGroups. {cacheGroup}. The filename attribute

CacheGroups. {cacheGroup}. Enforce attribute

conclusion

digression

Related Posts

JavaScript implements linked lists

A map function caused a murder

NPM private warehouse setup