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 插件：把指定文件夹下的文件复制到指定的目录。