资源请求合并和拆分-论 http 缓存与请求的一对一关联

[vevlins]

拆分的理由

• 防止其中部分更新必须导致的整体文件更新。这样可以保证缓存命中的几率，很好的减少二次加载耗费的时间。（核心原因）

• 减少单个文件大小，可以把首屏需要的必要文件单独提取出来，提高首屏的速度。

• 基于模块分解和工作任务分解的考虑。（通过现代打包工具，这个问题并不存在）

合并的理由

• 减少 http 请求数量，提高加载速度

这两种方案都是各有优点，在现行的技术框架下，以下思路是否是比较好的解决方案：

• 核心资源，非业务性质的代码（如基础库 react、loadsh 等）合并起来单独作为一个(提高缓存命中率)
• 首屏业务代码单独打一个文件（用来提升首屏的速度）
• 其他代码合并作为一个文件（懒加载）

但是这样还是没有能够解决** 部分更新必须导致的整体文件更新 **，除了一个 js 和多个 js 的情况，还有 js、css 的内联还是拆分这种情况。

我认为这种局面是由于 http 缓存和请求的一对一关系和前端缺乏对 http 缓存的控制能力造成的，我设想一种方案：实现一个资源内可以划分不同的 part，甚至于类似 git 的方式，可以请求修改部分取回来和现有的缓存结合修改，然后更新缓存。

当然这样还是没有解决在首次***减少单个文件大小，可以把首屏需要的必要文件单独提取出来，提高首屏的速度***。 那么发散一下，还是分开加载，但是加上一层实现合并请求更新和分派缓存更新。

对于以上的方案，是否有可行性，服务工作线程可以实现吗？

[htfy96]

cloudflare 的 CDN 在启用某个选项后可以实现 js 的增量更新。这种东西还是交给做 CDN 的搞一个单独的缓存层做比较好，不要放到业务逻辑里

[vevlins]

@htfy96 只在 cdn 层面应该不足以实现吧 这里的增量更新是客户端的增量更新吗

[htfy96]

@vevlins cloudflare 我记得可以把你 html 最后 include 的所有 script 标签替换成他的一个小的 loader.js 。这个 loader.js 第一次会全量拉下来你的 js 存在 localstorage 里，js 更新之后它会从 CF 服务器下载{当前版本->最新版本}的 diff，然后 patch localstorage 的版本

[vevlins]

@htfy96 谢谢