背景

在版本更新迭代、新代码上线后，如果用户须要从新从服务器加载全副资源（js、css），必定会让页面关上变慢，这其实是没有必要的。

为了优化用户体验，进步页面关上速度，能够将js拆分成多个模块，每次有更新，用户只须要加载更新了的业务代码即可，这就是分包。

计划

一般来说，前端我的项目不论框架是什么，大多是基于webpack打包的，比方umi、next、nuxt、vue-cli，所以本文只基于webpack打包工具给出计划。

webpack4提供了 splitChunks 插件，就是用来做代码宰割的，具体应用办法能够查看官网文档。

比拟广泛的分包策略是依照体积大小、共用率、更新频率从新划分咱们的包，使其尽可能的利用浏览器缓存。

依据这一策略给出通用的分包计划，将js拆分成以下三个模块：

第三方依赖（node_modules）
UI库（antd、element-ui、cube-ui）
业务代码

因而，每次公布代码之后通常须要更新的只有3、而1和2间接从浏览器缓存中读取即可。

施行

以phoenix我的项目为例，目前的线上页面打包后的状况如下图：

通过剖析工具看看各个模块是什么：

umi.js：框架js
verdors.async.js：第三方依赖
layouts_index.async.js和p_discountDetail_index.async.js：业务代码
（疏忽bundle.min.js，这是sentry脚本）

在什么都不做的状况下umi其实曾经默认分包了，这是因为其内置的webpack提供了默认分包策略：

新的 chunk 是否被共享或者是来自 node_modules 的模块
新的 chunk 体积在压缩之前是否大于 30kb
按需加载 chunk 的并发申请数量小于等于 5 个
页面初始加载时的并发申请数量小于等于 3 个

应用上述计划对默认分包策略进行优化，将UI库提取进去，在配置文件（umirc.ts）中退出自定义分包代码：

config.optimization.splitChunks({  chunks: 'async',  minSize: 30000,  maxSize: 0,  minChunks: 1,  maxAsyncRequests: 5,  maxInitialRequests: 3,  automaticNameDelimiter: '~',  name: true,  cacheGroups: {      vendors: {        name: 'vendors',      test: /[\\/]node_modules[\\/]/,        priority: -10,        },    antdesigns: {      name: 'antdesigns',      test: /[\\/]node_modules[\\/]antd-mobile[\\/]/,      priority: -9,        }  }})

各个字段的示意的含意不再此赘述，可查看官网文档。次要看cacheGroups，把antd提取了进去。

再来看下打包之后的成果：

多了一个antdesigns.js，胜利将antd提取进去。

Q：其实这里能够思考一下，将antd提取到底合不适合？

A：phoenix我的项目是个多页面利用，目前页面数量不多，而antd也反对按需引入，将antd代码打包进各个页面的业务代码或者node_modules中也不会减少多少体积，而antd代码体积并不大，独自提取进去后须要多一次http链接，感觉没有必要。不过随着当前我的项目体积变大，也就不肯定了。所以各个我的项目还是要依据本身状况进行分包。

论断

分包是一个博弈的过程，是让 a bundle 大一点还是 b?

是让首次加载快一点还是让 cache 的利用率高一点？

但有一点要切记，拆包的时候不要过分的谋求颗粒化，什么都独自的打成一个 bundle，不然你一个页面可能须要加载十几个js文件，如果你还不是HTTP/2的状况下，申请的阻塞还是很显著的(受限于浏览器并发申请数)。

所以还是那句话资源的加载策略并没什么齐全的计划，都须要依据我的项目本身状况进行分包。

后续要做的

分包之后的下一步就是充沛应用浏览器缓存，首先须要把动态资源放到cdn上，再设置正当的缓存策略，只有chunk的hash没有扭转，都从浏览器缓存读取。

参考资料：https://panjiachen.github.io/...

文/小辰

关注得物技术，携手走向技术的云端