All content of this article is based on [email protected]. Before reading this article, you need to understand the basic concepts of Webpack, such as Entry, Chunk, and Module.

Code splitting is one of the most compelling features of Webpack. This feature allows developers to split code into different packages that can then be loaded on demand or in parallel. It can be used to achieve smaller packages and control resource loading priorities, which, if used correctly, can have a significant impact on load times.

Segmentation strategy

Let’s start with Webpack’s default code splitting strategy.

webpack will automatically split chunks based on these conditions:

  • New chunk can be shared OR modules are from the node_modules folder
  • New chunk would be bigger than 30kb (before min+gz)
  • Maximum number of parallel requests when loading chunks on demand would be lower or equal to 5
  • Maximum number of parallel requests at initial page load would be lower or equal to 3

Webpack will automatically split chunks if the following conditions are met (ps: if there is no special configuration, only asynchronously loaded chunks will be automatically split).

  • The newchunkCan be shared orchunkIn themoduleFrom thenode_modulesfolder
  • The newchunkFile size greater than30kb(Before compression)
  • Loaded on demandchunkThe maximum number of internal parallel requests does not exceed5 个
  • The maximum number of parallel requests to initialize a page is 3

Webpack considers that code can be split if the above four conditions are met. The first two conditions should be easier to understand. Here is the meaning of the last two conditions:

Loaded on demandchunkThe maximum number of internal parallel requests does not exceed5 个

Simply put, no more than 5 requests can be sent to load chunk. Here’s an example:

Js, 2.js, 3.js, and 4.js, and these four files meet the first two criteria for code splitting (shared and larger than 30KB). In this case, five chunks are divided: A.chunk. js, 1.chunk.js, 2.chunk.js, 3.chunk.js, and 4.chunk.js. At this point, the number of concurrent requests for loading chunk~ A is exactly 5, and the compiled loading code is roughly as follows:

// t.e is the method for loading the chunk. The parameter of t.e should be the id of the chunk. For easy reading, I use the name of chunk instead. Promise.all([t.e('1.chunk'),t.e('2.chunk'),t.e('3.chunk'),t.e('4.chunk'),t.e('a.chunk')]).then(() => // do some thing)
Copy the code

If A.js relies on 5.js again, 5.chunk will not be split, because if a.chunk is split, there will be 6 requests for loading A.hunk, and the contents of 5.js will be merged into A.hunk.

The maximum number of parallel requests to initialize a page is 3

In other words, the maximum number of parallel requests for loading an entry is not more than 3. This is basically the same as the previous condition, except that one is for entry and one is for ordinary chunks. The purpose of this configuration is to limit the number of chunks that the code can split, so as to avoid the situation that too many chunks are split, resulting in too many requests.

Note that:

  • These two restrictions do not coverjsOther requests such ascss.
  • If only one more module is allowed to be split, the larger module will be split.

Split configuration

All of the above are default strategies for Webpack code splitting, which the Webpack team considers best practices. If you have special requirements in your project, such as thinking that the default 30KB is too large, you want to split it beyond 10KB. Webpack also provides some configurations to modify the fragmentation policy. This is the Optimization.splitchunks configuration in Webpack. Here are some of the more important configurations.

splitChunks.chunks

function (chunk) | string

Chunks configure the chunks for code splitting. As mentioned earlier, only asynchronously loaded chunks are split by default. If the value of chunks is string, the valid values are all, async, and INITIAL.

module.exports = { //... Optimization: {splitChunks: {// Chunks of all types:'all'}}};Copy the code
module.exports = { //... Optimization: {splitChunks: {chunks (chunks) {// Split everything except 'my-excluded-chunk'returnchunk.name ! = ='my-excluded-chunk'; }}}};Copy the code

splitChunks.minChunks

number

MinChunks means that the Module is shared by at least several chunks before the code is split. The default value is 1.

splitChunks.minSize

number

MinSize corresponds to the 30KB limit in the second condition of the split strategy, which can be flexibly adjusted according to the actual situation of the project.

splitChunks.maxSize

number

This configuration sets the maximum file size of the chunk to be split. The default value is 0, meaning there is no upper limit. With this attribute set, Webpack limits the chunk size to the maxSize value as much as possible, but a complete Module code cannot be broken into chunks, so it will be.

You can set this property to split up more and smaller chunks, but with that comes more requests to load chunks.

splitChunks.maxAsyncRequests

number

MaxAsyncRequests correspond to the configuration in article 3 of the partition policy. The default value is 5

splitChunks.maxInitialRequests

number

MaxInitialRequests corresponds to the fourth configuration in the partition policy, with a default value of 3

splitChunks.cacheGroups

CacheGroups is one of the most important configuration items in splitChunks. Its configuration items include all splitChunks, as well as test, Priority, and reuseExistingChunk.

The configuration in cacheGroups overwrites the configuration in splitChunks and is prioritized (through priority). The main purpose of cacheGroups is to set different partitioning policies for different chunks. This can greatly improve the flexibility of code segmentation, the author here will not elaborate on the use of the method, interested can refer to the official documentation.