One day, a project arrived. The NPM run build packaging test was executed, and the total time was 45028ms for the first time and 32344ms for the second time. The heart is broken. Thinking that every time you perform packaging, you’re wasting a little more shengming, so you have to optimize.

Webpack-bundle-analyzer is not very time-consuming

Looking at the Webpack configuration file, which uses the plugin Webpack-bundle-Analyzer, it not only analyzes the module composition ratio of the packaged file, but also starts a browser page (as shown below), suspecting that it might be time-consuming, so it comments it out.

Then, do the packaging again. It takes 46627ms for the first packaging and 31127ms for the second packaging. It didn’t seem to work.

2. The removal of speed-measure-webpack-plugin has achieved initial results

I see a speed-measure-webpack-plugin in the packaging process that requires constant updates to the console, so I comment it out. When the packaging is performed again, it takes 37290ms for the first packaging and 23843ms for the second packaging. Okay, lower it for a few seconds, and it’s working.

3, Hard-source-webpack-plugin and cache-loader can be used together

Plugins in webpack.prod.config.js add: new HardSourceWebpackPlugin(),

At this point, the first pack 46186ms, the second pack 36192ms. It doesn’t seem to be working. When packing twice, I often make a mistake:

hashing(node:142152) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_ARG_TYPE]: The “data” argument must be one of type string, TypedArray, or DataView.

Ts \ TSX \sass\ SCSS \less\ CSS = cache-loader After adding, 22678ms was packed for the first time and 8812ms for the second time. Work wonders! Also, the hard-source-webpack-plugin error has disappeared.

The hard-source-webpack-plugin seems to be related to the cache-loader, so it was decided to remove the hard-source-webpack-plugin. After removing the hard-source-webpack-plugin, it was found that the first packing time was back to 31266ms and the second packing time was 18025ms. The hard-source-webpack-plugin needs to be used with the cache-loader.

Since there is a server directory in the project directory with many files that don’t actually need to be built, we try to narrow down the module search. Add: modules: [‘node_modules’, path.resolve(__dirname, ‘SRC ‘)],

The first packing becomes 24807ms and the second packing becomes 8999ms. It doesn’t help.

It seems that reality and imagination are likely to be different, and the proof is in the pudding.

Iv. The comment-related configuration of TerserPlugin has a significant impact on the size of packaged files

After adding the following configuration:

new TerserPlugin({
  parallel: true,
  terserOptions: {
    format: {
      comments: false,
    },
  },
  extractComments: false,
}),
Copy the code

After packaging, the resource size changed from 26,334,098 bytes to 10,853,505 bytes.