Recently the project has gone through a huge, unbelievably twisted iteration, and now the project has become bloated. The whole project has already taken almost two minutes to get started. The whole package is over 1.4m

Clearly this performance is unacceptable. The front end team decided to optimize the entire system process for the project.

The following mainly introduces the optimization means of packaging.

1. Call on demand when importing dependencies, no longer importing the entire external dependency.

For the management of the dependencies of the whole project, we found that we only used a small part of the functions of many dependencies. For example, we did not use many components of the UI library, and Echart only used the tip of the iceberg. After the dependency function was introduced on demand, we found that subsequent packages were several hundred K smaller.

2. Multiple processes

To increase packaging speed by adding packaging threads, there are thread-loader, Happypack, Terser and other solutions. After local authentication, happypack is not recommended because it is incompatible with Loader. Just pass it out.

3. Webpack DLL acceleration

In Windows, DLL suffix files are called dynamic link libraries. DLL is a copy of this concept, the actual principle is to cache some commonly used dependencies. The principle is similar to that of commonChunks in that they separate common dependencies. But unlike commonChunks, the DLL generates a manifest.json file to map the separated dependencies. The key is that commonChunks still handles third party dependencies every time a package starts. DLLS only process project-related code files at a time. Using the DllReferencePlugin plugin, DLL files generated in webpack.dll.config.js are referenced to the required precompiled dependencies. That is to say, DLLS are not optimized for production deployment, but for local development performance optimization can make a big difference.

4, webpack hardsourcewebpackplugin

The most awesome plugin found so far reduces project startup speed to 20 seconds. Too powerful to be true. However, being strong comes at a cost. Cost 1: hardsourcewebpackplugin requires a cold start to the processing cache, which means the project’s initial start time can be even longer than before. Cost 2: HMR time average time consumption increases.

5, other

Webpack Devtool generates source map method adjustments to improve HMR, through the alias alias to improve module lookup speed.