Webpack4 makes some significant improvements to the Chunk graph and implements Chunk Spliting (an improvement over CommonsChunkPlugin) with a new optimization strategy.

Let’s look at some of the downsides of the old Chunk Graph.

In the old Chunk graph, chunks were connected through parent-child relationships and chunks contained moudles.

When a chunk with a parent block is loaded, you can be sure that at least one of its parents has already loaded. Optimization strategies use this principle. That is, when the parent chunk of chunk has the same Module, the module can be removed from the chunk because it is already available in any case.

Chunks referenced by an entry or async import point are loaded in parallel.

This relationship makes it difficult to “split” chunks. This happens when you use the CommonsChunkPlugin, for example. One or more chunks are removed and placed into a new chunk, which needs to be connected to the Chunk graph. But how? As the parent of old Chunk? Or subblocks? The CommonsChunkPlugin uses it as a parent block, but this is technically incorrect and negatively affects other optimizations (the parent block information is inaccurate).

The new Chunk Graph introduces a new object: ChunkGroup. Chunkgroups contain Chunks.

A ChunkGroup is referenced at an entry point or asynchronous split point, which means that all Chunks contained in this group are in parallel. A Chunk can be referenced by multiple CHunkGroups.

There is no longer a parent-child relationship between chunks, but a relationship between ChunkGroups.

Now the “Chunks” can be implemented. The new Chunks are added to all ChunkGroups that contain the original Chunks without negatively affecting the parent-child relationship.

Now that we’ve solved this problem, we can start to use chunk splitting more. We can split any chunk without risking breaking the Chunk graph.

The CommonsChunkPlugin has a number of problems:

  • This results in unnecessary code being downloaded.
  • In asynchronouschunksLow efficiency.
  • It’s cumbersome to use.
  • The implementation is hard to understand.

All the new plugins were born: SplitChunksPlugin.

It automatically identifies how chunks should be broken up using module repeats and categories (that is, node_modules).

This is a paradigm shift. The CommonsChunkPlugin is like: “Add a new chunck and move in all the modules that match the minChunks rule”. SplitChunksPlugin is like, “Here’s a blueprint, figure out how to make it happen.” (Imperative vs declarative)

SplitChunksPlugin has a few other nice features:

  • Never download extra modules (as long as you don’t enforce block merging by name)
  • asynchronouschunksStill effective
  • By default, asynchronouschunksIt’s open
  • When there are more than one third-party class library, this will split itselfchunks
  • Easy to use
  • chunk graphDo not rely onhacksmethods
  • More automation

Here are some examples of what SpitChunksPlugin can do for you. These examples show only the default behavior. Custom configurations have more results.

Note: You can configure this with Optimiztion.splitchunks. Case of chunks, by default only in asynchronous block (async chunks) play a role, but the configuration optimiztion. SplitChunks. Chunks: “all” can make a straight piece of (initial chunks) and its effect.

Note: We assume that all third-party libraries used for this are over 30KB, because optimizations will only occur after that size.

Vendors

Chunk-a: react, react-dom, some components chunk-B: react, react-dom, some other components chunk-C: Angular, some components chunk-d: Angular, some other components

Webpack automatically adds two vendors chunks, like the following:

Vendors ~chunk-a to chunk-b: react,react-dom vendors~chunk-c to chunk-d: Angular chunk-a to chunk-d: only components

Cross Vendors

Chunk-a: React, react-dom, some components

Chunk-b: React, React -dom, Lodash, some other components

Chunk-c: react,react-dom.lodash Some components

Again, webpack automatically adds two vendors chunks, like the following:

vendors~chunk-a~chunk-b: react,react-dom

vendors~chunk-c~chunk-d: lodash

Chunk-a to chunk-C: only components

Module Shared

Chunk-a: Vue, some components, some shared components

Chunk-b: Vue, some other components, some shared components

Chunk-c: Vue, some components, some shared components

Assuming the shared component is larger than 30KB, Webpack adds a new Vendors Chunk and a Commons chunk, like this:

vendors~chunk-a~chunk-b~chunk-c: vue

Commons ~chunk-a~chunk-b~chunk-c: some shared components

Chunk-a to chunk-C: only components

When the shared component size is less than 30KB, Webpack specifically copies modules from Chunk-A to chunk-B, and we don’t think the reduced download size is worth making additional requests for loading modules separately.

Multiple modules shared

Chunk-a: React, react-dom, some components, some shared React components

Chunk-b: React, react-dom, Angular, some other components

Chunk-c: react,react-dom, Angular, some components, some shared React components, some shared Angular components

Chunk-d: Angular, some other components, some shared Angular components

Webpack adds two vendors chunks and two Commons chunks

vendors~chunk-a~chunk-b~chunk-c: react,react-dom

vendors~chunk-b~chunk-c~chunk-d: angular

Commons ~chunk-a~chunk-c: Some React shared components

Commons ~chunk-c~chunk-d: Some Angular shared components

Chunk-a to chunk-d: only components

Note: since the chunk names made up by name all the chunk source, it is recommended that in the formation of long-term cache environment, file name should not contain [name], or through optimization. SplitChunks. Anme: false close to create a name. Otherwise, the previous files will become invalid if more chunks with the same vendors are added.

The original address: webpack 4: Code Splitting, the chunk graph and the splitChunks optimization | author: Tobias Koppers