SPA 首屏加载性能优化之 vue-cli3 拆包配置

前言

现在已经是vue-cli3.x webpack4.x 的时代了，但是网上很多拆包配置还是一些比较低版本的。

本文主要是分享自己的拆包踩坑经验。

主要是用了webpack4 的 splitChunks 来进行拆包的配置以及在配置中的一些踩坑。

首屏加载的优化主要在于两个方面，一个是减小包的总体积，二是由于把依赖打包进去太大而要进行拆包处理，提高首屏的加载速度。

一、减小包体积

主要在于压缩和去掉无用的代码

压缩可以用webpack的一些插件，服务端gzip压缩

去掉无用代码有生产环境去掉 console，去掉 .map 文件

适用插件：UglifyJsPlugin、TerserPlugin等

二、拆包

1、分离第三方依赖包

（1）有利用 cdn 引入的，这样一来一些大一点的第三方依赖包就不打包进去。但考虑到cdn并不一定很稳定，如果是公司自己的cdn或者付费cdn可能用起来会比较放心点。

（2）利用 vue-router 的路由懒加载

const Home= resolve =>{require(['./components/home/index.vue'],resolve)}

如果路由很多，都用这个的话，打包出来会有很多文件。

这时候，如果后端项目模板文件是写死引入的js和css的话就不太好办了，当然如果是前后端完全分离部署的环境或者是后端每次修改模板文件or动态引入所有js和css的话，是没什么问题的。

然而，我本次遇到的是前者，所以是希望基本上打包出来的文件名很少有变化才好。

（3）所以本次用的是webpack4 的 splitChunks , 注意 webpack 4 把 CommonsChunk 废弃，用splitChunks来取代。

默认配置： https://webpack.docschina.org/plugins/split-chunks-plugin/

chunks: 表示哪些代码需要优化，有三个可选值：initial(初始块)、async(按需加载块)、all(全部块)，默认为async
minSize: 表示在压缩前的最小模块大小，默认为30000
minChunks: 表示被引用次数，默认为1
maxAsyncRequests: 按需加载时候最大的并行请求数，默认为5
maxInitialRequests: 一个入口最大的并行请求数，默认为3
automaticNameDelimiter: 命名连接符
name: 拆分出来块的名字，默认由块名和hash值自动生成
cacheGroups: 缓存组。缓存组的属性除上面所有属性外，还有test, priority, reuseExistingChunk
- test: 用于控制哪些模块被这个缓存组匹配到
- priority: 缓存组打包的先后优先级
- reuseExistingChunk: 如果当前代码块包含的模块已经有了，就不在产生一个新的代码块

在用它的时候，也遇到了一些配置问题，没有配置之前app.js 达2.3MB 之大，想要达到的效果是js拆成 4-5 个包，最好不要有超过1MB的包。

首先准备是把element-ui这个包拆出来，效果是拆出来了，但app.js还是有2MB，然后把echarts也拆出来之后，app.js还是有1.8MB，再增加配置，一直没有成功，只拆出来两个包。

最终的拆包配置，vue.config.js 中在 chainWebpack添加配置

 // 拆包

    config.optimization.splitChunks({

      chunks: 'all',

      maxInitialRequests: Infinity,

      minSize: 300000, // 依赖包超过300000bit将被单独打包

      automaticNameDelimiter:'-',

      cacheGroups: {

        vendor: {

          test: /[\\/]node_modules[\\/]/,

          name(module) {

            const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1];

            return `chunk.${packageName.replace('@', '')}`;

          },

          priority:10

        }

      }

    })

用这种就可以，设置minSize，根据项目情况来，最终是大于它的依赖包就会被拆出来，这种的好处就在于，如果要自己去判断拆那个出来，有可能并不是很清楚哪些包比较大，哪些比较小，这种就会帮你判断，而且如果不是引入一些新的比较大的包，服务端的模板配置基本可以不怎么变。

参考：

https://juejin.im/post/5b99b9cd6fb9a05cff32007a

https://blog.csdn.net/weixin_34160277/article/details/86720033