webpack 构建及优化

webpack 构建优化

• speed-measure-webpack-plugin

  这个插件可以测量项目的webpack构建速度，可以让我们清晰的知道如何去优化webpack的构建配置

• webpackbar
  在建造或观看时显示优雅的进度条

分析

webpack构建的优化可以从这几方面入手

1. 指定一些loader的构建目录
   webpack在进行构建的时候会构建node_modules目录和我们自己的目录，那么在一些loader中指定让webpack构建我们想让他构建的目录就可以了。
2. 缓存
   webpack进行构建，如果每一次都从头到尾进行构建，花费的时间就狠慢，所以有缓存存在的话第二次构建的速度会提升
3. 多线程
   webpack构建是单线程的，如果我们能够开启多个线程去帮忙构建的话，把cpu拉满构建，构建速度会再次提升。

配置测量工具和进度条显示

const speedMeasurePlugin=require("speed-measure-webpack-plugin");
const WebpackBar = require('webpackbar');// 在plugins下new WebpackBar(),即可
const smp=new speedMeasurePlugin();
// 将webpack配置文件定义为常量，用speed-measure-webpack-plugin进行包裹，
module.exports=smp.wrap(config);

开发环境dev构建优化

指定构建目录优化

一开始什么优化都没有做的时候，我的测试项目npm start 为3.88m

图是运用speed-measure-webpack-plugin插件，途中可以清晰可见，在整个打包过程中，babel-loader,eslint-loader,css-loader,postcss-loader,less-loader,对着几个包的处理花费的时间多。

• 对bebel-loader，eslint-loader，做扫描范围限制。需要解析的目录为src下，不需要处理的是node_modules目录，

      include: paths.appSrc,
       exclude:paths.appNodeModules,
  

  npm 测试项目运行npm start 为1.76m

• css-loader,postcss-loader,less-loader这三个loader因为我们引入了antd或者其他组件的，如果在这里只对我们写的less进行处理会出现问题，这里就不对这三个loader做特殊处理了。

缓存加快第二次构建

在webpack生态中，有许多的loader具备缓存的功能，开启会加快速度，babel-loader 和eslint-loader具备，

 {
        test: /\.(js|jsx|mjs)$/,
        enforce: 'pre',
        use: [
          {
            options: {
              formatter: eslintFormatter,
              eslintPath: require.resolve('eslint'),
              cache:true,///配置缓存功能
            },
            loader: require.resolve('eslint-loader'),
          },
        ],
        include: paths.appSrc,
        exclude:paths.appNodeModules,
  },
 {
            test: /\.(js|jsx|mjs)$/,
            include: paths.appSrc,
            exclude:paths.appNodeModules,
            loader: require.resolve('babel-loader'),
            options: {
                plugins: [
                    ['import', [{ libraryName: 'antd', style: true }]]
                ],
              // This is a feature of `babel-loader` for webpack (not Babel itself).
              // It enables caching results in ./node_modules/.cache/babel-loader/
              // directory for faster rebuilds.
              cacheDirectory: true,//配置缓存
            },
   },

第一次打包约为1.86m，缓存文件写入本地node_modules/.cache目录下，可在相应文件能够看到相应的babel-loader,eslint-loader,加入缓存之后节省了约两倍的时间，第二次打包时间为39.95s

happypack多线程

将eslint-loader和babel-loader用happypack来包裹不在主线程里面运行，删除缓存文件，第一次npm start为1.04m,较之前为加入happypack时提升了0.8M，第二次npm start 为30s左右，较之前提升了7s，

配置happypack方式如下，在plugins下书写下面的

new HappyPack({	
      id: 'esjs',	
      threadPool: happyThreadPool,	
      loaders: [	
        {	
          loader: 'eslint-loader',	
          // cacheDirectory: true,
           options: {
              formatter: eslintFormatter,
              eslintPath: require.resolve('eslint'),
              cache:true,
            },
            // include: paths.appSrc,
        },	
      ],	
    }),
     new HappyPack({	
      id: 'js',	
      threadPool: happyThreadPool,	
      loaders: [	
        {	
          loader: 'babel-loader',	
          // cacheDirectory: true,
            options: {
                plugins: [
                    ['import', [{ libraryName: 'antd', style: true }]]
                ],
              // This is a feature of `babel-loader` for webpack (not Babel itself).
              // It enables caching results in ./node_modules/.cache/babel-loader/
              // directory for faster rebuilds.
              cacheDirectory: true,
            },
            // include: paths.appSrc,
        },	
      ],	
    }),

在loader使用如下所示

    {
            test: /\.(js|jsx|mjs)$/,
            include: paths.appSrc,
            exclude:paths.appNodeModules,
            // loader: require.resolve('babel-loader'),
              use: 'happypack/loader?id=js',//和plugins下制定的happypack的id一致
            // options: {
            //     plugins: [
            //         ['import', [{ libraryName: 'antd', style: true }]]
            //     ],
            // //   // This is a feature of `babel-loader` for webpack (not Babel itself).
            // //   // It enables caching results in ./node_modules/.cache/babel-loader/
            // //   // directory for faster rebuilds.
            //   cacheDirectory: true,
            // },
          },

打包配置优化

打包配置由于是使用docker部署，执行的流程如下所示

git clone XXX.git
npm install 
npm run build:prod

所以在打包时候的缓存没有作用

配置构建目录优化

从图中检测到未做优化时候花费5.20m，并且在babel-loader,eslint-loader,mini-css-extract-plugin,css-loader,postcss-loader,less-loader,花费的时间多，

对babel-loader,eslint-loader做检测范围限制，限制为src目录下，打包花费时间为4.20m，提升了1m

happypack多线程优化

将babel-loader，eslint-loader用happypack包裹，打包代码为3.79m，较之前提升0.40M，提升不明显，

UglifyJsPlugin优化

查看smp，发现UglifyJsPlugin花费了2mins，对其做优化，开启UglifyJsPlugin的多线程运行。

new UglifyJsPlugin({
        parallel: true,
    	cache：true，
      })

打包时间可提升为2.50m，较之前提升，1.29m，如果加入缓存，打包环境，第二次打包为44s左右

总结

yJsPlugin的多线程运行。

new UglifyJsPlugin({
        parallel: true,
    	cache：true，
      })

打包时间可提升为2.50m，较之前提升，1.29m，如果加入缓存，打包环境，第二次打包为44s左右

总结

开发环境start，从3.88M提升到了第一次运行1.04m，第二次运行30s，打包环境从5.20m提升到2.50m，本地打包提升到44S