webpack构建速度优化

webpack核心概念与构建流程：

webpack构建图

webpack核心概念包含入口（entry）、出口（output）、处理器（loader）、插件（plugin） 、模块（module）、模式（mode）、输出文件（bundle）、组合块（chunk）。这部分内容具体可以参考webpack官网。webpack中最易混淆的5个知识点

webpack构建流程大致是进入入口文件，解析出导入语句，根据module（模块）后缀名调出对应的loader进行处理,再找该依赖所依赖的module，递归地进行编译转换，最后将编译好的module整理组合成一个或多个chunk，最终生成bundle文件，整个过程是串行进行的。

由于项目在越来越大，构建速度也相应的越来越慢，打包体积也越来越大，因此有必要对项目进行webpack构建与打包的优化了。

这次主要是构建速度优化，每次去运行项目的时候会看到构建时间，优化目的主要是减少构建时间。

文章内容有如何去输出webpack构建内容分析，以及构建plugin和loader速度分析，还有对于打包的bundle文件大小关系分析。

优化思路：

  1. 首次run的时候尽量让构建速度快

    缩小构建目标、减少文件检索范围（这块内容在下面）

  2. 二次run的时候可以使用到缓存提升构建速度

    二次缓存优化：

    eslint-loader配置cache:true
    https://www.npmjs.com/package/eslint-loader

{
  test: /\.(js|vue)$/,
  loader: 'eslint-loader',
  enforce: 'pre',
  include: [resolve('src')],
  options: {
      formatter: require('eslint-friendly-formatter'),
      cache: true
  }
}

loader缓存会被默认缓存在node_modules/.cache/eslint-loader

vue-loader配置cacheDirectory属性 (暂时不明确)

{
    test: /\.vue$/,
    loader:'vue-loader',
    options: {
        cacheDirectory: path.resolve(__dirname,'node_modules/.cache')
    }
}

babel-loader配置在babel-loader中配置cacheDirectory

{
  test: /\.js$/,
  loader: 'babel-loader?cacheDirectory', // 开启转换结果缓存
  include: [resolve('src')]
}

或者

{
  test: /\.js$/,
  loader: 'babel-loader',
  include: [resolve('src')],
  options:{
    cacheDirectory: true
  }
}

loader缓存会被默认缓存在node_modules/.cache/babel-loader

通过二次缓存提升构建速度有一个强大的插件（墙裂推荐，在下面插件使用中，在优化构建速度的时候可以优先考虑一下）

插件使用

JARVIS（可用来统计打包速度）
JARVIS打包分析.png

使用jarvis插件对webpack构建新能进行分析

ERRORS AND WARNING (错误警告)

TOTAL ASSETS SIZE(打包资源体积)

ALL MODULES (所有打包数量)

安装：

npm i -D webpack-jarvis

使用：

const Jarvis = require("webpack-jarvis"); // 查看打包整体信息
module.exports = {
    plugins:[
        new Jarvis({
        watchOnly: false,
        port: 3002 // optional: set a port
    }),
    ]
}
webpack-bundle-analyzer（分析打包内容体积）
打包体积分析
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
module.exports = {
  plugins:[
     new BundleAnalyzerPlugin()
  ]
}
SpeedMeasurePlugin（分析plugin以及loader的构建耗时）

speed-measure-webpack-plugin是一个专门测试webpack构建速度的工具，可以在终端列出所有Loader和Plugin的耗时。

SpeedMeasurePlugin.png

安装：

npm i -D speed-measure-webpack-plugin

使用：使用插件的实例对象对webpack配置进行一次包裹，如代码所示，然后运行构建即可看到耗时分析

const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();
const webpackPlugin = {
  entry:"",
  // ...
  plugins:[]
}
module.exports = smp.wrap(webpackPlugin); // 包裹
HappyPack（在项目比较大时效果会比较明显，还可能出现构建速度变慢）

https://www.npmjs.com/package/happypack

使用 happypack 提升 Webpack 项目构建速度

HappyPack 可以让 Webpack 同一时间处理多个任务，发挥多核 CPU 的能力，将任务分解给多个子进程去并发的执行，子进程处理完后，再把结果发送给主进程。通过多进程模型，来加速代码构建。

const HappyPack = require('happypack');
const happyThreadPool = HappyPack.ThreadPool({size: 5}); //构建共享进程池，包含5个进程
mudule.exports = {
  entry:...,
  output:...,
  mudule:{
    rules: [
        {
          test: /\.js$/,
          loader: 'happypack/loader?id=babel', // 开启转换结果缓存
          include: [resolve('src')]
      },
    ]
    },
  plugins: [
     // happypack并行处理
     new HappyPack({
         // 用唯一ID来代表当前HappyPack是用来处理一类特定文件的，与rules中的use对应
         id: 'babel',
         loaders: ['babel-loader?cacheDirectory'],//默认设置loader处理 cacheDirectory对babel-loader进行缓存
         threadPool: happyThreadPool,//使用共享池处理
     })
  ]
}
HardSourceWebpackPlugin(效果明显，简直就是神器啊)

HardSourceWebpackPlugin 为模块提供了中间缓存，缓存默认的存放路径是: node_modules/.cache/hard-source。
配置 hard-source-webpack-plugin后，首次构建时间并不会有太大的变化，但是从第二次开始，构建时间大约可以减少 80%左右。

const HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = {
  // ...
  plugins:[
    new HardSourceWebpackPlugin()
  ]
}

由于这个插件效果太过于明显，太过于强大，以至于使用过后我觉得其他优化都可以忽略不计了。

缩小构建目标/减少文件检索范围

缩小构建目标:主要是exclude 与 include的使用：（有效果）

https://www.webpackjs.com/configuration/module/#rule-exclude

  • exclude: 不需要被解析的模块
  • include: 需要被解析的模块
    include和exclude用一个即可，默认exclude的优先级比include高。
module: {
    rules: [
        ...(config.dev.useEslint ? [createLintingRule()] : []),
        {
            test: /\.vue$/,
            loader: 'vue-loader',
            options: vueLoaderConfig
        },
        {
            test: /\.js$/,
            loader: 'happypack/loader?id=babel', // 开启转换结果缓存
            include: [resolve('src')]
        },
        {
            test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
            loader: 'happypack/loader?id=img',
            options: {
                limit: 10000,
                name: utils.assetsPath('img/[name].[hash:7].[ext]')
            },
            include: [resolve('src')]
        },
        {
            test: /\.(mp4|webm|ogg|mp3|wav|flac|aac)(\?.*)?$/,
            loader: 'url-loader',
            options: {
                limit: 10000,
                name: utils.assetsPath('media/[name].[hash:7].[ext]')
            },
            include: [resolve('src')]
        },
        {
            test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/,
            loader: 'url-loader',
            options: {
                limit: 10000,
                name: utils.assetsPath('fonts/[name].[hash:7].[ext]'),
                // todo-tao 将来删除，调整element-ui@2.8.2字体打包后的引用路径
                publicPath: '../../'
            },
            include: [resolve('src'), resolve('node_modules/element-ui')]
        }
    ]
}
减少文件检索范围：这个主要是resolve相关的配置，用来设置模块如何被解析。通过resolve的配置，可以帮助Webpack快速查找依赖，也可以替换对应的依赖。

https://www.webpackjs.com/configuration/resolve/#resolve-modules

resolve.modules：告诉 webpack 解析模块时应该搜索的目录resolve.modules用于配置webpack去哪些目录下寻找第三方模块，默认是['node_modules']，但是，它会先去当前目录的./node_modules查找，没有的话再去../node_modules最后到根目录

所以当安装的第三方模块都放在项目根目录时，就没有必要安默认的一层一层的查找，直接指明存放的绝对位置

resolve.extensions：文件扩展名 ['js','vue','jsx']尽量少，且将会匹配到的多的文件后缀放到最前面。

resolve.mainFiles：解析目录时要使用的文件名，默认是index

resolve: {
  extensions: ['.js', '.vue', '.json'],
  alias: {
      'vue$': 'vue/dist/vue.esm.js',
      '@': resolve('src')
  },
  modules: [path.resolve(__dirname, '../node_modules')]
}

优化的方式还有很多，比如使用DllPlugin优化，原理是它能把第三方库代码分离开，并且每次文件更改的时候，它只会打包该项目自身的代码。所以打包速度会更快。但是在某些资料中发现这个优化不是很理想，vue和react官方都没有很友好的去用这个优化方式，本次优化项目构建速度目前就用到这些内容，如有更好的方式可以一起交流呀。

补充：使用HardSourceWebpackPlugin会出现的问题：

由于HardSourceWebpackPlugin插件做了缓存，所以当更改了webpack配置，或者新增npm包的时候就会出现再次构建新增npm包不生效问题，因为再次构建还是使用的之前的缓存内容新增的npm包内容并没有进行构建，因此在配置发生改变时需要重新构建一次项目，配置如下：

new HardSourceWebpackPlugin({ // 二次构建缓存优化插件
    environmentHash: {
        root: process.cwd(),
        directories: [],
        files: ['package-lock.json', 'yarn.lock'],
    },
})

在实例化HardSourceWebpackPlugin插件的时候传入环境hash配置项，官网是这么说的：
当loaders、plugins、其他构建时的脚本或其他动态依赖项发生更改时，hard-source需要替换缓存以确保输出正确。环境哈希用于确定这一点。如果哈希与以前的构建不同，则将使用新的缓存。

补充：HardSourceWebpackPlugin 缓存ESlint信息， ESlint错误信息被缓存，二次构建时还会存在

根据官网提示新增一个插件，用来排除eslint-loader缓存

new HardSourceWebpackPlugin.ExcludeModulePlugin([
    {
      test: /eslint-loader/
    }
])

https://github.com/mzgoddard/hard-source-webpack-plugin

补充：happy pack使用注意点

happy pack是用来多进程打包加速，这个多进程指的是采用cpu的进程进行加速打包的。
因此在使用的时候需要先获取cpu的进程。
使用os模块 os.cpus().length来获取cpu的进程数。

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

happy pack原理解析

补充：弃用happypack使用thread-loader

在小组分享会上说使用多进程打包加速的时候，有伙伴提出来说，happypack官方停止去维护了，并且webpack4更推荐多进程使用thread-loader.
安装：
npm install --save-dev thread-loader
使用：

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        include: path.resolve("src"),
        use: [
          "thread-loader",
          // your expensive loader (e.g babel-loader)
        ]
      }
    ]
  }
}

https://github.com/webpack-contrib/thread-loader

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 158,425评论 4赞 361
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,058评论 1赞 291
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 108,186评论 0赞 243
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 43,848评论 0赞 204
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,249评论 3赞 286
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,554评论 1赞 216
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,830评论 2赞 312
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,536评论 0赞 197
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,239评论 1赞 241
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,505评论 2赞 244
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,004评论 1赞 258
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,346评论 2赞 253
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 32,999评论 3赞 235
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,060评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,821评论 0赞 194
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,574评论 2赞 271
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,480评论 2赞 267