Webpack打包优化🚀
Opened this issue · 0 comments
Webpack打包优化
Webpack 打包优化——体积
定位webpack体积大的原因
推荐使用webpack-bundle-analyzer--Webpack插件和CLI的实用程序。将内容展示为方便交互的直观树状图。
1、引入DLLPlugin、DllReferencePlugin
DllPlugin(打包后,user的配置文件)、Dll(打包后存放位置)提供了大幅度提高构建时间性能的方式拆分软件包的方法。原理:将特定的第三方NPM包模块提前构建,然后通过页面引入。不仅可以使得vendor文件大幅度减小,同时也极大的提高了构建的速度。
- Webpack Dll功能:避免第三方库在每次打包的时候,刷新vendor代码(发布新的版本,不需要重新打包第三方库)
dll 包就是一个纯粹的依赖库,它本身是不能执行的,用来给app引用的。将所有的包含的库的索引,写在一个manifest文件中,我们在引用这个库的时候,只需要读取这个文件即可。- 优点:
- dll打包后独立存在,只要其包含的库没有增、减,hash不会变化,因此线上的dll的代码不会随着版本的发布频繁更新。
- App部分修改后,只需要编译app部分的代码,dll不需要重新打包。
- 多个项目之间,如果使用相同的依赖库,就可以共用一个dll。
我们需要去建立一个dll的配置文件。entry,只包含第三方库。
2、外部引入模块(CDN)
浏览器的兼容问题,我们需要去使用babel转换,从而需要去引入babel-polyfill以确保兼容,之外还有moment、lodash都是很大的包,我们可以考虑外部的去引入文件,使用externals指定,webpack就可以使其不参与打包,但是依然可以在代码中通过CMD、AMD或者window/global全局的方式引入
// webpack 中予以指定
externals: {
'babel-polyfill': 'window'
}
<script src="//cdn.bootcss.com/babel-polyfill/7.0.0-alpha.15/polyfill.min.js"></script>
3. 让每个第三包“引用所值”
- 确定引入的必要性
- 避免类库引而不用
- 尽量使用模块化的引入
import _ from 'lodash'
export default {
cloneDeep: _.cloneDeep,
debounce: _.debounce,
throttle: _.throttle,
size: _.size,
pick: _.pick,
isEmpty: _.isEmpty
}
- 尽可能的引入更合适的包
4. 按需异步加载模块
/** Vue **/
import Foo from './Foo.vue';
// 改写
const Foo = () => import('./Foo.vue')
这样该组件的所依赖的其他的组件或者其他的模块,都会被自动的分割进对应的chunk里,实现异步加载,也支持把组件按组分块,将同组中组件,打包在同一个异步的chunk中。
在React里面我们,可以将路由按需加载,使用bundle-loader。
5. 生产环境,压缩混淆并且移除console
现在的中等的规模的开发,都要区分开发环境、测试环境、生产环境。我们可以在生产环境,压缩js文件以有效的减小包的体积,同时移除使用比较频繁的console
new webpack.optimize.UglifyJsPlugin({\
compress: {
warning: false,
drop_console: true,
pure_funcs: ['console.log']
},
sourceMap: false
})
Webpack打包优化——速度
1. 减少文件搜索范围
在使用实际项目开发中,为了提升开发效率,很明显你会使用很多成熟第三方库;即便自己写的代码,模块间相互引用,为了方便也会使用相对路径,或者别名(alias);这中间如果能使得 Webpack 更快寻找到目标,将对打包速度产生很是积极的影响。于此,我们需要做的即:减小文件搜索范围,从而提升速度;实现这一点,可以有如下两法:
- 配置resolve.modules
Webpack的resolve.module配置模版库(node_moduels)所在的位置,在js出现的import 'vue'的这样的做法不是相对、绝对路径的写法,会去node_modules目录下查找。默认的配置,会采用向上递归搜索的方式去寻找,但通常项目目录里只有一个 node_modules,且是在项目根目录,为了减少搜索范围,可以直接写明 node_modules 的全路径;同样,对于别名(alias)的配置,亦当如此
function resolve (dir) {
return path.join(__dirname, '..', dir)
}
resolve: {
// extensions 自动解析确定的扩展(不需要去待扩展名 import File from '../path/file')
extensions: ['.js', '.vue', '.json'],
// modules 告诉webpack解析模块时候应该搜索的目录。
modules: [
resolve('src'),
resolve('node_modules')
],
// alias创建import或者require的别名,来保证模块引入更简单
// 确保模块的直接的引入 import store from 'store';
alias: {
'vue$': 'vue/dist/vue.common.js',
'src': resolve('src'),
'assets': resolve('src/assets'),
'components': resolve('src/components'),
// ...
'store': resolve('src/store')
}
},
- 设置test&include&exclude
2. 增强代码压缩的工具
webpack默认提供UglifyJS插件,由于采用单线程压缩,速度颇慢。推荐采用webpack-parallel-uglify-plugin插件,使用UglifyJS插件,更加充分而合理的使用CPU资源,大大减少构建时间。
3. 使用Happypack来加速代码的构建
- 我们所认识的wenpack为了方便各种资源和类型的加载,设计了loader加载器的形式读取资源,受限制于nodejs的模型影响,所有的loader虽然async形式并且调用,但是还是在运行在单个node的线程中,以及在同一个事件循环中。当同时加载多个loader文件资源的时候,需要耗费大量的cpu运算的过程,node单线程毫无优势
- Happy处理的思路是:将原有的webpack对loader的执行过程,从单一的线程形式扩展为多进程模式,从而加速代码的构建。原本的流程保持不变,这样可以在不修改原有配置的基础上,来完成对编译过程的优化。还是使用之前的loaders方法
4. 设置babel的cacheDirectory为true
babel-loader很慢,所以不仅要使用exclude、include,尽可能准确的指定要转化内容的范畴,而且要充分利用缓存,进一步提升性能。babel-loader 提供了 cacheDirectory特定选项(默认 false):设置时,给定的目录将用于缓存加载器的结果。
未来的 Webpack 构建将尝试从缓存中读取,以避免在每次运行时运行潜在昂贵的 Babel 重新编译过程。如果值为空(loader: ‘babel-loader?cacheDirectory’)或true(loader: babel-loader?cacheDirectory=true),node_modules/.cache/babel-loader 则 node_modules 在任何根目录中找不到任何文件夹时,加载程序将使用默认缓存目录或回退到默认的OS临时文件目录。
rules: [
{
test: /\.js$/,
loader: 'babel-loader?cacheDirectory=true',
exclude: /node_modules/,
include: [resolve('src'), resolve('test')]
},
...
]
5. 设置noParse
如果你确定一个模块中,没有其他的新的依赖,我们就可以配置这个。Webpack将不在扫描这个文件中的依赖。这对于比较大型类库,将能促进性能表现。
module: {
noParse: /node_modules\/(element-ui\.js)/,
rules: [
{
...
}
}
6. 拷贝静态文件
在前面Webpack 打包优化之体积篇,引入 DllPlugin 和 DllReferencePlugin 来提前构建一些第三方库,来优化 Webpack 打包。而在生产环境时,就需要将提前构建好的包,同步到 dist 中;这里拷贝静态文件,你可以使用 copy-webpack-plugin 插件:把指定文件夹下的文件复制到指定的目录。