vue-cli 打包优化
随着项目越来越大,打包的速度也变的很慢,甚至出现了node内存溢出,今天来一起学习一下打包的一些优化
node内存溢出
有些时候,打包或者编译会报这个错误: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
是因为Node是基于V8引擎,我们的64位电脑只能支持到1.4G的内存,超过这个就会报错,解决方法如下
cnpm install -g increase-memory-limit 全局安装increase-memory-limit
进入项目文件夹,运行:increase-memory-limit
如果还是不行,在packjson中修改build命令
"build": "node --max_old_space_size=8192 build/build.js"
如果是多人合作的项目,也可以直接将increase-memory-limit配置到文件当中,做法如下
npm install increase-memory-limit -S
npm install cross-env -S
在packjson中添加命令"fix-memory-limit": "cross-env LIMIT=8192 increase-memory-limit"
直接运行 npm run fix-memory-limit
就可以了
可以在/node_modules/.bin/文件中看到,文件被修改了运行内存
使用HappyPack多进程进行loader处理
优化原理:
- 由于运行在 Node.js 之上的 Webpack 是单线程模型的,所以 Webpack 需要处理的事情只能一件一件地做,不能多件事一起做。
- 而 HappyPack 的处理思路是:将原有的 webpack 对 loader 的执行过程,从单一进程的形式扩展多进程模式,从而加速代码构建。
cnpm i happypack -S
安装插件
修改build/webpack.base.conf.js
文件
1 | const HappyPack = require('happypack'); |
如果报错的话,说明当前使用的webpack版本没有自带os,需要自己安装
npm i webpack-parallel-uglify-plugin -D
npm i os -D
配置loader的 include & exclude
优化原理
- webpack 的 loaders 里的每个子项都可以有 include 和 exclude 属性:
- include:导入的文件将由加载程序转换的路径或文件数组(把要处理的目录包括进来)
- exclude:不能满足的条件(排除不处理的目录)
- 我们可以使用 include 更精确地指定要处理的目录,这可以减少不必要的遍历,从而减少性能损失。
- 同时使用 exclude 对于已经明确知道的,不需要处理的目录,予以排除,从而进一步提升性能。
打开 build/webpack.base.conf.js 文件,添加如下 include , exclude 配置:
1 | module: { |
配置 resolve.modules
优化原理:
- webpack 的 resolve.modules 是用来配置模块库(即 node_modules)所在的位置。当 js 里出现 import ‘vue’ 这样不是相对、也不是绝对路径的写法时,它便会到 node_modules 目录下去找。
- 在默认配置下,webpack 会采用向上递归搜索的方式去寻找。但通常项目目录里只有一个 node_modules,且是在项目根目录。为了减少搜索范围,可我们以直接写明 node_modules 的全路径。
修改build/webpack.base.conf.js
文件
1 | module.exports = { |
查看打包后的文件体积
打包的时候 npm run build --report
使用webpack-parallel-uglify-plugin多线程压缩JS
优化原理:
- 默认情况下 webpack 使用 UglifyJS 插件进行代码压缩,但由于其采用单线程压缩,速度很慢。
- 我们可以改用 webpack-parallel-uglify-plugin 插件,它可以并行运行 UglifyJS 插件,从而更加充分、合理的使用 CPU 资源,从而大大减少构建时间。
npm i webpack-parallel-uglify-plugin
安装
修改build/webpack.prod.conf.js
文件
1 | const ParallelUglifyPlugin = require('webpack-parallel-uglify-plugin'); |
warnings 有一些webpack的版本是放在compress里面的
可能打包后会报错:
ERROR in Encountered an error while minifying static/js/vendor.js:
Maximum call stack size exceeded
不要紧,是因为vendor.js这个文件太大了,导致压缩失败,继续往下走,后面把第三方库抽离出来后就不会报错了
去除map文件,并开启gzip打包
cnpm install --save-dev compression-webpack-plugin@1.1.11
安装,这里一定要带版本号安装,否则会报错
在config/index中修改
1 | build: { |
dev中的配置也可以稍微修改一选
1 | devtool: 'eval'(最快速度) |
使用 DllPlugin 和 DllReferencePlugin 预编译资源模块
优化原理:
- 我们的项目依赖中通常会引用大量的 npm 包,而这些包在正常的开发过程中并不会进行修改,但是在每一次构建过程中却需要反复的将其解析,而下面介绍的两个插件就是用来规避此类损耗的:
- DllPlugin 插件:作用是预先编译一些模块。
- DllReferencePlugin 插件:它的所用则是把这些预先编译好的模块引用起来。
- 注意:DllPlugin 必须要在 DllReferencePlugin 执行前先执行一次,dll 这个概念应该也是借鉴了 windows 程序开发中的 dll 文件的设计理念。
实践:
新建一个配置文件,比如build/webpack.dll.conf.js
1 | const path = require('path') |
vendor里面就是第三方库
编辑 package.json 文件,添加一条编译命令
1 | "dll": "webpack --config build/webpack.dll.conf.js" |
npm run dll 成功以后,static下会有dll.vendor.js,根目录下会有vendor.manifest.json
ok,到这里,抽离依赖库的事情就完成了,那么接下来问题就是怎么引用呢,怎么在dev和build跑呢?
这里补了一点dll和commonsChunk概念上的区别,commonsChunk之所以慢和大,是因为每次run的时候,都会去做一次打包,而实际上我们不会一直去更新我们引用的依赖库,所以dll的做法就等于是,事先先打包好依赖库,然后只对每次都修改的js做打包。
好了,继续
修改build/webpack.dev.conf.js 和 build/webpack.prod.conf.js, 添加DllReferencePlugin的配置
1 | const webpack = require('webpack'); |
最后再index.html中添加<script src="/static/js/vendor.dll.js"></script>
到这里,vue打包优化配置基本结束