One recent development issue: WebPack builds and compiles slowly as the project gets bigger. Although webpack4 is officially claimed to be over 90% faster, in practice it feels almost as fast as webpack2. I was fed up with waiting a few seconds to compile while hot loading, so I started optimizing. The final optimization effect is good, and the speed can reach more than 80%. Along the way, I optimized according to the thinking of previous experiments and experienced various problems. Instead of sharing the methods to solve the problems, I want to share the ideas to solve the problems.

Quantify your goals first

Before we do an experiment, we always have a goal. But the problem is, although it feels slow, I don’t know exactly how long it took, or where it was slow, so there’s no way to know how far we can optimize, and there’s no way to start optimizing. So the first task is to get information about the WebPack compilation process. After a bit of digging around in the official WebPack documentation, I found that the devServer.stats attribute in the configuration provides complete information about the build process

stats: {
    timings: true,
    modules: false,
    assets: false,
    entrypoints: false,
    assetsSort: 'field',
    builtAt: false,
    cached: false,
    cachedAssets: false,
    children: false,
    chunks: false,
    chunkGroups: false,
    chunkModules: false,
    chunkOrigins: false,
    performance: true,
    errors: true,
    warnings: true,},Copy the code

This gives the build and compile times:


Guess the factors that might affect the speed

The current project is a multi-entry project, where each entry has little to do with each other, but is packaged and compiled together. Would it be faster if we compiled one entry at a time? There are three entrances, but when only one entry is loaded, you can see:


"scripts": {
    "dev": "webpack-dev-server --config ./webpack.config/dev.js --hot --inline"."teacher": "app=teacher webpack-dev-server --config ./webpack.config/dev.js --hot --inline"."student": "app=student webpack-dev-server --config ./webpack.config/dev.js --hot --inline"."home": "app=home webpack-dev-server --config ./webpack.config/dev.js --hot --inline",}Copy the code

Add an app=XXX parameter to dev command in package.json

const teacherEntry = {
    ueditor: [
        'babel-polyfill'.'./src/common/UEditor/ueditor.config.js'.'./src/common/UEditor/ueditor.all.js'.'./src/common/UEditor/kityformula-plugin/addKityFormulaDialog.js'.'./src/common/UEditor/kityformula-plugin/getKfContent.js'.'./src/common/UEditor/kityformula-plugin/defaultFilterFix.js'
    ],
    teacher: ['./src/app/teacher/index.js'],
    teacherLogin: './src/app/teacherLogin/js/teacherLogin.js'
};
const studentEntry = {
    student: ['babel-polyfill'.'./src/app/student/index.js'],
    studentLogin: './src/app/studentLogin/js/studentLogin.js'
};
const homeEntry = {
    home: './src/app/home/index.js'
};
const entryObj = {
    teacher: teacherEntry,
    student: studentEntry,
    home: homeEntry
};

const entry = process.env.app
    ? entryObj[process.env.app]
    : Object.assign({}, teacherEntry, studentEntry, homeEntry);
Copy the code

We then added code to webpack.base.config.js to load different entries according to the value of process.env.app, so that we can run different commands to load different entries during development.

Check webPack Config for any configuration that affects performance

Then use control variables to remove webpack loaders and plugins one by one, and observe the reduced time.

new WriteFilePlugin({
    test: / ^ ((? ! hot-update).) * $/}),Copy the code

I found that I was using a plug-in that writes files to the exit, but all I really need to do is write to an HTML file

new WriteFilePlugin({
    test: /\.html$/,
    useHashIndex: true
}),
Copy the code

The build and compile times have been reduced to 30s and 3s, with a bit of optimization. Babel does not ignore node_modules when compiling JS.

{
    test: /\.js$/,
    include: /(src|node_modules\/flv.js)/,
    exclude: /(node_modules)/,
    loader: 'babel-loader'
},
Copy the code

Add that to find that the time becomes 27 seconds and 2.2 seconds, already half of the initial time.

Look at other people’s projects and see if you can learn from them

After seeing the configuration, I found no more problems, so I started To Google other people’s optimization methods. Happypack (multithreaded compilation) and cache-loader (cache) are used in a similar project.

new HappyPack({
    id: 'babel', // for loaders id loaders: ['cache-loader'.'babel-loader? cacheDirectory'// If you are using babel-loader to parse threadPool, verboseWhenProfiling:true// Display information}),Copy the code

After adding happypack and cache-loader, we can see that the first build speed is significantly improved, down to 13.5s! But the compile speed is pretty much the same, still 2s. The revolution has not yet succeeded. Comrades still need to work hard.

Look at information about the compilation process for optimization points

To further optimize the speed of compilation, we have to analyze what happened in the compilation process. Set assets in Stats to True and observe the compiled file:

devtool: 'cheap-module-eval-source-map'
Copy the code

When we tried it out, the build and compile times were reduced to 11s and 0.8s.

conclusion

After this way of optimization, deeply webpack configuration extensive and profound. Each project may have different problems affecting the speed of Webpack, so here to share the idea of locating problems, I hope to help friends with similar problems to find problems step by step, improve the speed.

Author: Brady