webpack优化编译速度
① 编译优化-HappyPack
多线程（多进程模拟）支持
HappyPack的工作原理：在Webpack和Loader之间多加了一层，改成了Webpack并不是直接去和某个Loader进行工作，而是Webpack test到了需要编译的某个类型的资源模块后，将该资源的处理任务交给了HappyPack，由HappyPack在内部线程池中进行任务调度，分配一个线程调用处理该类型资源的Loader来处理这个资源，完成后上报处理结果，最后HappyPack把处理结果返回给Webpack，最后由Webpack输出到目的路径。通过这一系列操作，将原本都在一个Node.js线程内的工作，分配到了不同的线程（进程）中并行处理。
使用方法如下：
首先引入HappyPack并创建线程池：
替换之前的Loader为HappyPack的插件：
将原Loader中的配置，移动到对应插件中：
Webpack v4编译速度优化实践
② 如何解决webpack打包后，dist文件过大的问题
去除不必要的插件
刚开始用 webpack 的时候，开发环境和生产环境用的是同一个 webpack 配置文件，导致生产环境打包的 JS 文件包含了一大堆没必要的插件，比如 HotMoleReplacementPlugin, NoErrorsPlugin... 这时候不管用什么优化方式，都没多大效果。所以，如果你打包后的文件非常大的话，先检查下是不是包含了这些插件。
提取第三方库
像 react 这个库的核心代码就有 627 KB，这样和我们的源代码放在一起打包，体积肯定会很大。所以可以在 webpack 中设置
{
entry: {
bundle: 'app'
vendor: ['react']
}
plugins: {
new webpack.optimize.CommonsChunkPlugin('vendor', 'vendor.js')
}
}
这样打包之后就会多出一个 vendor.js 文件，之后在引入我们自己的代码之前，都要先引入这个文件。比如在 index.html 中
<script src="/build/vendor.js"></script>
<script src="/build/bundle.js"></script>
除了这种方式之外，还可以通过引用外部文件的方式引入第三方库，比如像下面的配置
{
externals: {
'react': 'React'
}
}
externals 对象的 key 是给 require 时用的，比如 require('react')，对象的 value 表示的是如何在 global 中访问到该对象，这里是 window.React。这时候 index.html 就变成下面这样
<script src="//cdn.bootcss.com/react/0.14.7/react.min.js"></script>
<script src="/build/bundle.js"></script>
当然，个人更推荐第一种方式。
代码压缩
webpack 自带了一个压缩插件 UglifyJsPlugin，只需要在配置文件中引入即可。
{
plugins: [
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false
}
})
]
}
加入了这个插件之后，编译的速度会明显变慢，所以一般只在生产环境启用。
另外，服务器端还可以开启 gzip 压缩，优化的效果更明显。
代码分割
什么是代码分割呢？我们知道，一般加载一个网页都会把全部的 js 代码都加载下来。但是对于 web app 来说，我们更想要的是只加载当前 UI 的代码，没有点击的部分不加载。
看起来好像挺麻烦，但是通过 webpack 的 code split 以及配合 react router 就可以方便实现。具体的例子可以看下 react router 的官方示例 huge apps。不过这里还是讲下之前配置踩过的坑。
code split 是不支持 ES6 的模块系统的，所以在导入和导出的时候千万要注意，特别是导出。如果你导出组件的时候用 ES6 的方式，这时候不管导入是用 CommomJs 还是 AMD，都会失败，而且还不会报错！
当然会踩到这个坑也是因为我刚刚才用 NodeJS，而且一入门就是用 ES6 的风格。除了这个之外，还有一点也要注意，在生产环境的 webpack 配置文件中，要加上 publicPath
output: {
path: xxx,
publicPath: yyy,
filename: 'bundle.js'
}
不然的话，webpack 在加载 chunk 的时候，路径会出错。
设置缓存
开始这个小节之前，可以先看下大神的一篇文章：大公司里怎样开发和部署前端代码。
对于静态文件，第一次获取之后，文件内容没改变的话，浏览器直接读取缓存文件即可。那如果缓存设置过长，文件要更新怎么办呢？嗯，以文件内容的 MD5 作为文件名就是一个不错的解决方案。来看下用 webpack 应该怎样实现
output: {
path: xxx,
publicPath: yyy,
filename: '[name]-[chunkhash:6].js'
}
打包后的文件名加入了 hash 值
const bundler = webpack(config)
bundler.run((err, stats) => {
let assets = stats.toJson().assets
let name
for (let i = 0; i < assets.length; i++) {
if (assets[i].name.startsWith('main')) {
name = assets[i].name
break
}
}
fs.stat(config.buildTemplatePath, (err, stats) => {
if (err) {
fs.mkdirSync(config.buildTemplatePath)
}
writeTemplate(name)
})
})
手动调用 webpack 的 API，获取打包后的文件名，通过 writeTemplate 更新 html 代码。完整代码猛戳 gitst。
③ 从 Webpack 到 Snowpack, 编译速度提升十倍以上——TRPG Engine迁移小记
原文地址: http://moonrailgun.com/posts/74598ef5/
TRPG Engine 经过长久以来的迭代，项目已经显得非常臃肿了。数分钟的全量编译, 每次按下保存都会触发一次 10s 到 1m 不等的增量编译让我苦不堪言, 庞大的依赖使其每一次编译都会涉及很多文件和很多包，长时的编译时间大大降低了开发效率与迭代速度。
经过一段时间的考察，我选择了 Snowpack 作为解决方案。与 Webpack 不同的是，除了第一次的全量编译以外， Snowpack 的增量编译不会涉及到庞大的 node_moles 文件夹, 准确来说只会编译变更文件本身。甚至于如果没有对依赖进行变更，下次的全量编译会直接动用之前编译的文件缓存，不需要花时间等待 node_moles 的编译。
为什么会这么快？这是由于 Snowpack 本身的实现与设计哲学有关的。相比 Webpack , Snowpack 利用了现代浏览器的本身的 mole 系统，跳过复杂的模型之间的组织编译过程而只关注于变更文件本身的编译，这样当然快了。
拿 Snowpack 官方的一张图来说:
snowpack 的最我译单位是文件，而 webpack 的最我译单位为 chunk , 而 chunk 还需要额外的计算, 不论是编译部分还是编译后的组装部分。snowpack的设计逻辑天生决定了她的速度。
优化前(使用 webpack ):
全量编译:
增量编译:
全量请求用时:
优化后(使用 snowpack ):
全量编译:
增量编译:
(看不到编译用时，但是体感在1s内. 而且该效果在电脑运行其他应用时更加显着)
全量请求用时:
以上测试是保证电脑在空闲时间，且保存与操作内容为同一文件
该用时已经是平时操作的最快时间，为此我的MBR重启了一次强制清空了swap空间, 实际表现会更加显着
因为文件依赖于浏览器的耗时，而浏览器需要串行请求依赖，因此耗时会更加长
但实际使用中使用snowpack会更加优秀。因为其相比webpack会大大节约电脑资源。在webpack编译时会占用大量的电脑资源，会影响到其他操作
TRPG Engine 算是非常经典的 Webpack 应用了, 使用了各种Loader。光通用配置就有250+行，各种优化配置，各种 alias。等等长时间迭代积攒下来的配置，因此毫不意外的会遇到很多问题与坑。
以下是我遇到的问题与解决方案:
Snowpack虽然作为一个新兴的打包工具，目前尚不是非常完善, 功能也没有webpack这样丰富与齐全。但是它的新的打包设计对于有一定规模的前端应用还是非常优秀的。能极大提升开发效率。不失为一种好的解决方案。当然最后输出还是需要使用webpack对其进行一定的优化，毕竟原生的mole支持目前浏览器的支持度还没有达到覆盖一个理想的地步 https://caniuse.com/es6-mole
最后这是我最后提交的 pr
④ webpack-打包优化方案
分析打包文件
要优化，先分析。我们先要知道到底是哪里拖慢我们的打包速度呢？
可以利用 webpack-bundle-analyzer 插件来分析我们打包后生成的文件
修改 webpack.prod.conf.js 文件
simple-progress-webpack-plugin 可以显示打包百分比
修改 webpack.prod.conf.js 文件
效果如下：
资源与依赖包的控制
通过上面进度可以看到，打包过程中，卡顿在压缩的地方过长，当项目越来越臃肿的时候，我们要需要对项目静态资源以及依赖包进行整理，
项目里面使用 ElementUI 和 Echarts 都是全部引用挂在 Vue.prototype 上，现都改为按需引用。
预处理各种文件时指定匹配目录后， webpack 解析文件时就不会循环查找其他目录，加快解析速度。
webpack 执行预处理文件时单线程的，我们可以使用 happypack 来多线程处理文件。
修改 webpack.base.js 文件
babel-plugin-dynamic-import-node 插件是使 import() 替换成 require 编译
修改 .babelrc 文件
注意 ：使用插件 build 后没有 chunk files 文件。
通过 DllPlugin 插件分离出第三方包
使用 add-asset-html-webpack-plugin 动态添加 dll.js 到 html 。
需要注意
项目经过以上优化，打包从 30 分钟，到 2 分钟不到，整体还有优化空间，可以使用其他 cdn 等优化方式。
⑤ 前端构建工具webpack有什么缺陷
配置多入口时，没有glob的方式，需要额外处理。
目录结构复杂时，file-loder里面的path功能太弱，很多时候无法自定义构建后的目录结构，只能放在一个目录下。
源码比较复杂，遇到问题看源码，要花很长时间。
如果没有 babel， webpack 对 ES2015+ 的语法是不接受的，会提示用指定 loader。这意味着，在支持部分 ES2015 语法的 firefox 与 chrome 浏览器中能直接跑的代码，无法用 webpack 编译。
⑥ 我们还能在哪些方面进行webpack性能优化
Bigo前端组计算平台前端组基于amis框架，参考之前的文章：https%3A%2F%2Fgithub.com%2Fbigo-frontend%2Fblog%2Fissues%2F17 ；有很好的研发效率提升，但是构建速度却很慢，亟需进行优化。优化之后达到了将webpack构建速度提升80%左右的一个成绩，以下是优化前后的对比
团队做了3件事情来达到这样的一个效果：
基于这次优化做了功课，看了一些资料，看看还有哪些可以优化的地方。
官网的定义：
webpack is a static mole bundler for modern JavaScript applications. When webpack processes your application, it internally builds a dependency graph which maps every mole your project needs and generates one or more bundles.
也就是说 webpack 是一个用于现代 JavaScript 应用程序的静态模块打包工具，从入口出发，找到入口文件所有的依赖，生成浏览器可以用的bundle文件。webpack的出现使得前端的工程化更加地丰富。从webpack在2013的第一次release(v1.0.0-beta2)开始，至今已经有8、9年的 历史 了，是一个相当成熟的工具，其生态也比较完善，所以前端圈用webpack也是非常地广泛。
尽量用较新的版本，新版本相较之前都会有一定的性能提升和优化，包括Node和Webpack。要注意的是 Node.js v8.9.10 - v9.11.1 ES6的 Set 和 Map 会有性能回退问题，现在LTS的node已经是 v14.16.0 ，所以假设 Node 版本已经较新，并且用的是 WP4 ( webpack4 )。目前还不建议对求稳的或者已经很庞大的项目立即升级到 WP5 ，其一是因为webpack生态里面并不一定所有的插件都能跟的上最新的版本，可能会出现兼容性的问题；其二由于webpack5还并未被广泛地应用，到新版本的稳定和成熟还是需要一定的时间，为避免不必要的bug，建议暂时使用 webpack4 。
对于开发者来说，每次在build的时候不希望花费较长的时间，优化构建速度能够减少开发成本；对于用户而言，优化bundle文件的数量和大小能减少用户的流失率，提升用户体验。所以webpack的性能优化是一个非常关键的技术手段。
webpack构建大概可分为 loader解析 -> 依赖搜索 -> 打包 等三个阶段，就这三个阶段我们分别展开阐述如何去优化。
loader解析：
依赖搜索：
打包: Smaller = Faster
当然需要在 index.html 里面引入cdn依赖，否则在runtime无法找到相应的模块： 。
开发环境* *：** 同样地，生产环境有些配置也不适用于开发环境，比如 TerserPlugin 就不需要，因为在开发环境中压缩代码是没有意义的；devTools的最佳实践是 eval-cheap-mole-source-map ，我现在的项目比较轻量，但是也能看出对比：
虽然是不到1000ms的差距，苍蝇肉也是肉不是？而且将来代码量越来越庞大的时候，差距就更明显了。
当然还有其他的可以优化的方法，比如使用ES mole，能更好地利用webpack的tree shaking功能；Dll，为更改不频繁的代码生成单独的编译结果，但却是一个配置比较复杂的过程；还有对图片的压缩等等。以上是对于webpack4性能优化基本的配置，期待webpack5成熟稳定的那一天。
⑦ vue编译打包速度优化
1、首先在config文件夹下配置webpack.dll.config.js(内容如下)，要打包的模块的数组可以将一些较大的依赖放进vendor中
2、在package.json的scripts加上
3、运行npm run dll就可以生成vendor-manifest.json和vendor.dll.js
4、然后在index.html中引入vendor.dll.js
然后就可以正常的进行编译打包，会发现将更多的依赖放到vendor，打包速度越快
优化前
优化后
大概平均可以节省三分之一的时间。参考 webpack中文网