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

拆分的理由

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

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

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

合并的理由

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

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

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

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

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

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

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