Front-end development experience enhancement – Webpack packaging speed optimization

This topic is webpack speed optimization

Preparation consists of 2 steps:

1. How to find slow packing speed? (Exact which plugin is slow and which loader is slow)
2. How to solve the slow problem?

Get into the business

How to find slow packing speed? (Exact which plugin is slow and which loader is slow)

Installing a plug-in: speed – measure – webpack – plugin: www.npmjs.com/package/spe…

• Note: webpack5 above, there may be problems

How to configure speed-measure-webpack-plugin:

// Modify your WebPack configuration

// Take the following objects
const webpackConfig = {
  entry: ' '.output: ' '.plugins: [new MyPlugin(), new MyOtherPlugin()],
};

// Write it as follows
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();

const webpackConfig = smp.wrap({
  entry: ' '.output: ' '.plugins: [new MyPlugin(), new MyOtherPlugin()],
});
Copy the code

After NPM run build, the result is as follows

You can view the elapsed time of the plugin and loader

Once you know what’s slow, start thinking of ways to fix it

How to solve the slow problem?

First of all, the official website recommended optimization operation, first to get down

(some optimization of operating the new version webpack has built-in) : webpack.docschina.org/guides/buil…

Sort out a few small points to operate:

1. Use the latest version (new versions have performance optimizations)
   • For example, use the latest versions: Webpack, Node, various loaders and plugin
2. By using the include field, only apply the Loader to the module that actually needs to convert it:

   const path = require('path');
   
   module.exports = {
     / /...
     module: {
       rules: [{test: /\.js$/,
           include: path.resolve(__dirname, 'src'), // Avoid scanning node_modules
           loader: 'babel-loader',},],},};Copy the code

3. The Devtool sourceMap
   • For production (formal) environments :(none) (or omit devtool option) – do not generate source map (reduce volume)
     • Formal environments can also harmlessly use sourceMap: the blogger’s sister juejin.cn/post/695604…
   • For development (Dev) environments: Eval-source-map is recommended

After the basic general scheme is done, is it over? – It’s not over yet. There’s room for improvement. Scroll down

Analysis question: What can be optimized? What won’t move?

Elimination. Let’s see what doesn’t move? (This analysis case is vUE project, the react project can also be similar analysis)

• Generally stable third-party loader or Webpack official plug-in, itself has been optimized, if you want to move the source code transformation, the cost is too high, the benefit is not obvious. It can be almost ignored, such as vue-loader, CSS-loader, sas-loader, and less-loader

In addition to the “basic development standard”, it is up to the developers themselves to check if there are any time-consuming plug-ins in the project.

For example: for old company projects taken over by bloggers, the speed-measure-webpack-plugin mentioned above is used to analyze the time consuming items that can be operated (usually the extra loader or plugin added by the developers themselves).

Optimization of 1

[email protected]@image-webpack-loader took 12.081 secs detected

• Image-webpack-loader: takes 12 seconds. (The rest are basic plug-ins and loaders with little room for optimization)
• Knowing that image-webpack-loader compresses images and recompresses them every time they are packaged takes too much time. So consider, all images should be compressed once (tinypng.com/ can be used) and then removed in this loader

Packaging speed optimization effect: 30s -> 20s

Optimization of 2

The fewer files to package, the better. There is no need to package the third-party library every time. Generally, there are many third-party libraries in the project, so you can configure CDN, and then the third-party library does not need to be packaged

Before CDN configuration: Vender package collection is 7.71Mb, very scary

With CDN: Vender package collection down to 1.95Mb, which is pretty awesome

Packaging speed optimization effect: about 20s -> 13s

For details about how to configure the CDN (Webpack Project), see webPack Project: Configure the CDN of third-party libraries and implement CDN fault tolerance

Optimization of 3

Plug-in hard – source – webpack – plugin: www.npmjs.com/package/har…

What it does: It provides an intermediate caching step for modules. To see the results, you’ll need to run WebPack twice using the plug-in: the first build will take the normal amount of time. The second build will be significantly faster.

The second packaging time can be optimized to about 3s

Optimization of 4

After packaging, various resource size proportion: www.npmjs.com/package/web…

Using plug-ins:

// npm install -D webpack-bundle-analyzer
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
 plugins: [
   new BundleAnalyzerPlugin()
 ]
}
Copy the code

Examples of optimization points:

1. The plugin makes it easy to find packages that are too large, such as loadsh, and can be imported on demand

    // npm i -D lodash.clonedeep
   
    import clonedeep from 'lodash.clonedeep'
    import('lodash.clonedeep').then(clonedeep= >{})Copy the code

2. Moment language pack can also be imported on demand (for example, you only need Chinese, other languages can not load)

   const webpack = requrie('webpack')
   
   plugins: [
     // Ignore moment language package
     new webpack.IgnorePlugin({
       resourceRegExp: /^\.\/locale$/,
       contextRegExp: /moment$/,}),]Copy the code

   The above is to shield all language packages, so you need to manually import the required language packages

   // ./src/index.js
   import 'moment/locale/zh-cn.js' // The language package should be loaded first
   import moment from 'moment'
   Copy the code

3. Some strangers you don’t know how old they are

• For example, a public component in the internal public component library that the blogger wrote himself added BRACE (for an online code editor). The result is that the BRACE package contains various languages and has 8M left after being packaged… Solution: Only introduce the parts required by the business, such as SQL, JS, etc

Optimization of 5

Use the WebPack plugin DllPlugin

Principle:

• Code that doesn’t change (like a common library), or code that is large and doesn’t move very often. Package the code once, so you don’t have to refer to it again. This will speed up the packaging
  • For example: pack the public library into a separate library file, and only need to pack the business code each time. In this way, the time of public packaging is reduced and the overall speed is improved (the public library can also be replaced by CDN here).
  • In addition to the common library, some large, time-consuming, and infrequent code can also use this plug-in

How to use DllPlugin (specific) : segmentfault.com/a/119000002…

Original arrangement, there are mistakes can leave a message, if useful, thank you for your praise ~