webpack打包体积优化
加载慢原因分析及解决
一个是打包体积的优化，另一个是代码层面的优化
1》首先通过Network面板发现vendor.js体积过大，网路良好情况下加载时间太长），vendor体积太大，加载花了3s？后来发现 js 没开启nginx压缩
2》通过 webpack-bundle-analyzer 来具体分析，进一步体积过大的原因，进一步进行打包优化
打包体积优化方案
1》开启gzip压缩
压缩原理：简单的理解就是将相同的内容，用两者之间的距离和相同内容的长度来替换后面的内容，从而使整个文件变小。所以文件中代码的重复率越高，那么压缩的效率就越高，使用 gzip 的收益也就越大
如何判断是否开启：
请求头：服务端会通过客户端发送的请求头中的 Accept-Encoding 字段来确定是否支持
Accept-Encoding:gzip, deflate, br响应头：表示当前资源会使用 gzip 压缩，提示客户端解压使用。
Content-Encoding:gzipnginx中开启gzip
http {
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}| 属性 | 说明 |
|---|---|
| gzip | on/off,是否开启gzip压缩 |
| gzip_types | 压缩哪些文件类型 |
| gzip_min_length | eg：10k;大于10k的文件才会进行压缩（小于10k可能压缩后反而变大） |
| gzip_buffers | 获取多少内存用于缓存压缩结果，eg: 16 8k 表示使用16个缓冲区，每个缓冲区大小为8KB |
| gzip_comp_level | 压缩比（1~9），越小压缩效果越差，但是越大处理越慢，所以一般取中间值 |
| gzip_static on | 优先匹配 gzip 文件来返回，如果没有就寻找相应资源进行 gzip 压缩再返回 |
优点：减小文件体积，页面加载更快
缺点 ：开启 gzip 后会额外的增加很多 cpu 的开销，会对服务器产生一定压力，（客户端解压也需要cpu开销不过客户端还好），这也是不建议把压缩率设置太高的原因。另外，对图片的压缩支持不太好，会出现体积变大或图片失真的问题
webpack开启gzip打包
通过插件compression-webpack-plugin来生成.gz文件
npm i -D compression-webpack-pluginwebpack增加配置
// 最好是先判断以下环境变量是否是生产环境的打包
const CompressionWebpackPlugin = require('compression-webpack-plugin')
if (process.env.NODE_ENV === 'production') {
webpackConfig.plugins.push(
new CompressionWebpackPlugin({
filename: '[path].gz[query]',
// 目标资源名称。 [file] 会被替换成原始资源。[path] 会被替换成原始资源的路径， [query] 会被替换成查询字符串。默认值是 "[path].gz[query]"。
algorithm: 'gzip',
// 算法，默认'gzip'
test: '\\.(js|css))$',
// 所有匹配该正则的资源都会被处理。默认值是全部资源。
// 这里只匹配了js、css文件
threshold: 10240,
//只有大小大于该值的资源会被处理。单位是 bytes。默认值是 0。
minRatio: 0.8
// 只有压缩率小于这个值的资源才会被处理。默认值是 0.8。
})
)
}添还需要在nginx配置gzip_static on;，这样nginx 会优先匹配 gzip 文件来返回，如果没有就寻找相应资源进行 gzip 压缩再返回
优点：减少了服务器压缩文件的压力
缺点：打包时间变长
2》代码压缩
对于js：terser-webpack-plugin
optimization: {
minimize: true,
,
},
minimizer: [
new TerserPlugin({
parallel: true, //开启并行压缩，可以加快构建速度
}),
],对于css： css-minimizer-webpack-plugin
optimization: {
minimizer: [new cssMinimizerPlugin({
parallel: true
}
)],
},3》分包优化
webpack5中splitChunks可以进行分包优化
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
echarts: {
name: 'chunk-echarts',
priority: 20,
test: /[\\/]node_modules[\\/]_?echarts(.*)/,
},
},
},
},4》通过cdn方式引入外部库
**externals **引入外部库, 无需webpack打包处理
externals: {
echarts: 'echarts',
},在html中引入
<script src="https://cdn.jsdelivr.net/npm/echarts@5.4.0/dist/echarts.min.js"></script>组件中无需引入，可以直接使用echarts
const myChart = echarts.init(dom)5》source-map
测试环境：
devtool: 'eval-cheap-module-source-map'生产环境：
devtool: false
devtool: "nosources-source-map"不同source-map的选择
false不会有sourcemap
eval- ：生成source-map,不会生成额外的 .map文件,而是在eval 函数内附加 source map推荐在开发环境中使用
inline-：不会生成 .map文件，但是会将SourceMap内联到原始文件中
hidden- ： source map 但是不会将其关联
nosources- sourcemap 中不带源码， 但会有准确的错误行列信息， 避免源码泄露
cheap- 忽略"列"信息，source map 只有"行"映射，可以加快打包速度
对于开发环境，通常希望更快速的 source map，需要添加到 bundle 中以增加体积为代价，但是对于生产环境，则希望更精准的 source map，需要从 bundle 中分离并独立存在
6》tree-shaking
在webpack5之前，如果一个文件中引用多个函数，却使用一个函数，那么多个函数都会被打包
但是webpack5能解析出依赖图谱，去除最终没有被使用的代码，生产模式下会进行 tree-shaking
复制代码webpack5是有自动的tree-shaking
7》路由懒加载
路由懒加载可以将不同的路由对应的内容打包到不同文件中，而且用户访问对应路由时才会加载相应的组件（静态导入时，所有路由组件都会被打包到同一个文件中）
为什么按需引入没有是打包体积减小反而更大？
在使用ant-design-vue的时候，发现按需引入组件，打包体积反而更大了
原因是一些公用的东西，依赖等，如果是一起打包，就只要引用打包一次，按需引入则每个组件需要引用一份，就会打包进去一次
对于只用了很少组件的第三方库，比如本测试的echarts，按需引入会有很明显的优化效果，但是如果使用了很多，按需引入不一定更好