This article is published by the Cloud + community

Author: Zhihang

build

There are two aspects that affect the speed of the front-end release, one is build, one is compression, and optimizing these two things can reduce a lot of release time.

thread-loader

Thread-loader will run your loader in a worker pool to achieve multithreaded builds.

If you place this loader before other loaders (as shown in the example below), loaders placed after this loader will run in a separate worker pool.

Install

$ npm install --save-dev thread-loader
Copy the code

Usage and exmaple

// webpack.config.js
module.exports = {
  module: {
    rules: [{test: /\.js$/.include: path.resolve("src"),
        use: [
          "thread-loader".// Your high overhead loader is placed here (LLDB babel-loader)]]}}Copy the code

Each worker is a separate Node.js process with a 600ms limit. Data exchange across processes is also limited. Use it in a high-overhead loader; otherwise, the effect is poor

For more configurations, see: github.com/webpack-con…

happypack

Happypack, with its multi-process model, speeds up code construction. Judging from the number of Starts on Github, Happypack is popular.

The principle of

Related technical principle here is no longer cumbersome, you can view taobao FED related articles happypack principle analysis

Usage and example

var HappyPack = require('happypack');
var happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });

/ /... Omit other configurations
module: {
  loaders: [{test: /\.less$/.loader: ExtractTextPlugin.extract(
            'style',
            path.resolve(__dirname, './node_modules'.'happypack/loader') + '? id=less')}}],plugins: [
      new HappyPack({
        id: 'less'.loaders: ['css! less'].threadPool: happyThreadPool,
        cache: true.verbose: true})]Copy the code

Summary of construction methods

In practice, Thread-loader and Happypack have little impact on packaging speed for small projects because of their additional overhead, such as I/O. It is recommended that they be used only in large projects and can be tested before being put into production.

The compression

The webpack-parallel-ugli-fi -plugin is not recommended

The project is basically in the stage of no maintenance, no one handles the issue, and no one merges the PR.

The terser-webpack-plugin is recommended

Terser-webpack-plugin is a webpack plugin that uses Terser to compress JS.

Compression is one of the most time-consuming steps in pre-release processing, and if you’re in WebPack 4, you can speed up your build release with just a few lines of code.

Usage and example

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  optimization: {
    minimizer: [new TerserPlugin(
      parallel: true   / / multi-threaded)],}};Copy the code

See the link above for more usage.

conclusion

With the improvements to WebPack 4 and the inspiration of zero-configuration Web application packaging tools like Parcel, the configuration of WebPack is getting simpler, so why not try it out?

This article has been published by Tencent Cloud + community in various channels

For more fresh technology dry goods, you can follow usTencent Cloud technology community – Cloud Plus community official number and Zhihu organization number