webpack4项目打包速度优化之路

背景及现状

新接手了一个项目,项目已经两年多了,使用了很多依赖,包括内部开发的组件发布的npm包,导致打包速度越来越慢

分析

目前在本地打包普遍需要240S以上,在gitlab的CI/CD上则需要10分钟左右。需要将CI/CD流水线上的构建速度提高,从而更快的部署,那么我们只有两个优化方向:

  1. 项目打包本身优化速度
  2. 运维支持在CI/CD上做文章,做缓存

由于没有运维,无法获得运维在docker上的缓存支持,无奈只能在项目build本身下功夫

再次分析

我们优化构建速度的方法方式无外乎压缩、多流程并行、减少不必要的消耗、升级版本、缓存等这些方式。而本项目的最终目标是需要再CI/CD上构建速度大幅提升,所以缓存的方式在本次优化中不能起到作用

曲折的优化之路

经过近两个星期的尝试,以及踩各种坑最终使得CI/CD构建的速度降低到4分钟上下,节省60%。下面就来看看踩过的坑

  1. speed-measure-webpack-plugin,为了分析各个loader打包所占用的时间,此插件必不可少。但是啊但是!我们生产构建的时候没有必要开启它,因为它也会大幅拖慢打包速度。经过不下10次的对比,开启时比不开启时多耗时近一分钟!其配置也很简单:
    在vue.config.js中首先声明
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin')
const smp = new SpeedMeasurePlugin()

然后

module.exports = {
...
  configureWebpack:smp.wrap({
  ...
  })
}
  1. cdn加速,项目中引入的如vue,vuex,vue-router等可以使用cdn加速来使用,避免被打包进去,而且这些依赖一般比较庞大,如果使用得当,可以有比较明显的效果。
    ——但是啊但是!本项目中没有用vuex,vue-router的经典模块。。。用了vuex-module、router-module、vue-modx这些方式。。。苍天啊!可能真的是我才疏学浅,孤陋寡闻了。
    ——所以CDN这条路在本项目中没什么卵用了
  2. webpack-parallel-uglify-plugin,此插件是用来开启多进程压缩的,webpack4本身内置了uglify,所以如果项目庞大,使用效果是可以的。
    ——问题就处在这里,开启多进程也是需要消耗时间的,如果项目不够庞大,反而会拖慢速度。本项目就刚好是这么尴尬,使用之后反而拖慢了速度,打包时间竟然上升到300+秒,简直是老奶奶钻被窝,给爷整笑了。代码如下:
    照样先声明
const ParallelUglifyPlugin = require('webpack-parallel-uglify-plugin')

然后

module.exports = {
...
  configureWebpack:({
  ...
    plugins: [
        ...
        new ParallelUglifyPlugin({
        // 传递给 UglifyJS 的参数
        cacheDir: '.cache/',
        uglifyJS: {
          output: {
            // 最紧凑的输出
            beautify: false,
            // 删除所有的注释
            comments: false
          },
          warnings: false,
          compress: {
            // 在UglifyJs删除没有用到的代码时不输出警告
            // warnings: false,
            // 删除所有的 `console` 语句,可以兼容ie浏览器
            drop_console: true,
            // 内嵌定义了但是只用到一次的变量
            collapse_vars: true,
            // 提取出出现多次但是没有定义成变量去引用的静态值
            reduce_vars: true
          }
        }
      })
    ]
    ...
  })
}

所以如果项目本身不是特别庞大,不能用这个

  1. terser-webpack-plugin,其是webpack5内置的压缩插件,但是webpack4还是需要先安装
    npm install terser-webpack-plugin --save-dev
    其和ParallelUglifyPlugin相似,开启多进程,在webpack4下,项目不大的情况下不要使用,本项目使用前后差别不大,聊胜于无。代码如下:
    照样先声明
const TerserPlugin = require('terser-webpack-plugin')

然后

module.exports = {
...
  configureWebpack:({
    ...
    optimization: {
      minimizer: [
        new TerserPlugin({
          parallel: true
        })
      ]
    }
    ...
  })
}

parallel: true的意思是开启进程,数量比计算机内核数少1。true也可以替换成具体的数字;

  1. thread-loader,其也是webpack内置的插件,可以直接使用,配置也相当简单。代码如下:
module.exports = {
...
  configureWebpack:({
    ...
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          use: [
            {
              loader: 'thread-loader'
            },
            'babel-loader',
            'cache-loader'
            ... //其他占用打包时间较大的loader
          ]
        }
        ...    
      ]
    }
    ...
  })
}

其效果较为可以,可以从10分钟优化到近6分钟,提升40%。

  1. include & exclude精确匹配路径,效果不明显,聊胜于无,比较鸡肋。代码如下:
module.exports = {
...
  chainWebpack(config) {
  ...
  config.module
      .rule('vue-loader')
      .test(/\.js$/)
      .include.add(resolve('src')).end()
      .exclude.add(/node_modules\/(?!(autotrack|dom-utils))|vendor\.dll\.js/).end()
    config.module
      .rule('babel-loader')
      .test(/\.vue$/)
      .include.add(resolve('src')).end()
      .exclude.add(/node_modules/).end()
  ...
  }
}
  1. esbuild-loader,其采用go编写,速度大幅提升,也是我最终采用的方式,最终优化到了4分钟上下。不过其也有确定,由于其目前刚出来,才一年左右。目前生态尚不完善,文档较少。如果胆子够大,可以考虑项目整体采用vite,其是基于esbuild,性能很好。上代码:
    首先需要安装esbuild-loader,npm i -D esbuild-loader
    然后声明一下
const { ESBuildMinifyPlugin } = require('esbuild-loader')

然后

module.exports = {
...
  chainWebpack(config) {
  ...
  const rule = config.module.rule('js')

    // 清理自带的 babel-loader
    rule.uses.clear()

    // 添加 esbuild-loader
    rule
      .use('esbuild-loader')
      .loader('esbuild-loader')
      .options({
        loader: 'jsx', // 如果使用了 ts, 或者 vue 的 class 装饰器,则需要加上这个 option 配置, 否则会报错: ERROR: Unexpected "@"
        target: 'es2015',
        jsxFactory: 'h', //项目中使用了JSX语法,必须声明jsxFactory和jsxFragment,否则会报错can not find react
        jsxFragment: 'Fragment'
      })

    // 删除底层 terser, 换用 esbuild-minimize-plugin
    config.optimization.minimizers.delete('terser')

    // 使用 esbuild 优化 css 压缩
    config.optimization
      .minimizer('esbuild')
      .use(ESBuildMinifyPlugin, [{ minify: true, css: true }])
  ...
  }
}
  1. 最后说一下,再好的方法不如升级webpack版本。只是老项目毕竟相互的依赖过于复杂,牵一发动全身,不敢轻易妄动。

题外话

虽然缓存不能在CI/CD起作用————不过,我也尝试了使用缓存进行尝试,一共两种方式:

  1. 使用hard-source-webpack-plugin,代码很简单,webpack4自带hard-source-webpack-plugin插件
    在vue.config.js中首先声明
const HardSourceWebpackPlugin = require('hard-source-webpack-plugin')

然后

module.exports = {
...
  configureWebpack:({
  ...
    plugins: [
      new HardSourceWebpackPlugin()
      ...
    ]
  })
}

对比了效果,如果是在本地构建,速度提升还是很明显的。第一次时间比较长,第二次直接从240S变成40S,大约提升了80%

  1. 使用cache,能到80S左右,效果差一些,能节省70%左右,也是webpack4自带的。代码如下:
    在vue.config.js中
module.exports = {
...
  chainWebpack(config) {
  ...
    config.cache()
  }
}

你可能感兴趣的:(webpack4项目打包速度优化之路)