"If you don't understand, just ask" What is the performance bottleneck of webpack packaging?

background

In the previous article, we analyzed: why esbuild is so fast.

There is also data comparison:

It can be seen that: esbuild took the lead with absolute advantage.

But looking at the bottom, it is the webpack we are most familiar with.

So, why is the construction of Where is it slow?

The following are some of my thoughts, I share with you, I hope it will be helpful to you.

text

First, let's take a look at the general process of webpack construction:

The process takes a long time.

So, where is performance bottleneck of the entire process?

I think it is mainly in the following two stages:

1. code construction
2. code compression

Let's look at them separately.

1. Code Construction

In the code construction phase, a very important thing that needs to be done is the dependency analysis module to generate Module Graph .

This part has a very complicated process.

This part is very complicated and time-consuming.

For this reason, webpack also designed the corresponding algorithm to optimize this part, and those who are interested can study it.

For the detailed analysis of this part, there is a video that tells it well, you can check it out if you are interested:

Speaking of building.

Modern browsers esm better and better, and the browser can complete the work of module dependency analysis.

Moreover, many package analysis tools of the browser are C/C++ , which is obviously webpack using js to analyze the entire dependency map, and the speed is also much faster.

2. Code Compression

Currently the most mature js compression tool is UglifyJS .

It will analyze the code syntax tree of js, understand the meaning of the code, so as to achieve optimizations such as: removing invalid codes, removing log output codes, and shortening variable names.

webpack uses compression plugin to complete this part of the work.

Among them: webpack used by terser is written in js , derived from the earliest uglyfy.js , with rich functions, but the speed is very, very slow.

This is one of the reasons why webpack is slow.

But in terms of code compression, vite also Terser .

In this regard, there is a related description in the document:

• build.minify:

  • Type: boolean |'terser' |'esbuild'
  • Default:'terser'

Set to false to disable minimizing obfuscation, or to specify which obfuscator to use.

The default is Terser .

Although Terser is slower than , the file after construction is smaller in most cases.

ESbuild minimizes confusion faster, but the built file relatively larger.

For more information, please refer to:
https://cn.vitejs.dev/config/#build-minify

In addition, if you pay attention, you will find a phenomenon:

1. Esbuild, written GO
2. SWC is written in Rust .

They are not written in js

Future front-end compiler tools, will probably go in this direction, either with Go write, or use Rust write, rather than this can form performance bottlenecks things with js to achieve.

One more thing needs to be mentioned.

In the picture at the beginning of the article, it seems that webpack5 is slower than webpack4:

But this does not mean that webpack 5 is not good. Don't get me wrong.

webpack 5 which made lot of optimization, get rid of a lot of historical baggage.

Some new features include very useful, such as:

• Module Federation
• Real Content Hash

It is not difficult to think that the webpack team still made a lot of efforts, ❤️.

to sum up

This article suddenly had an idea in the middle of the night, and it took two hours to write it.

Hope to inspire everyone, thank you.