Open YIXUNFE opened 8 years ago
缓存对于我们前端来说是一个用于提高网页性能非常重要的工具。简单的“缓存”两字，其中包含了许多有趣的知识，其中对于缓存粗粒度的讨论也一直不绝于耳。
目前见过的缓存粗粒度分为三类：
下面让我们一起看看这三种方案的到底是如何处理生产环境下的缓存的。
这种做法相当的直白而且由来历史悠久，无论开发过程中的文件有多少个，整个打包成一个文件后在页面中引用。这样做带来的好处是可以最大的减少对资源的请求数，至今仍使用这种方法进行线上缓存处理的网站还有很多（特别是某些后端框架自带合并资源功能时）。然而这种方案的缺点也十分明显。
由于太粗放，开发环境中的一个文件被修改，就会导致整个页面的资源都将失效。客户端不得不因为一小部分的修改，而重新下载所有的内容，这是移动互联网大环境下不能被容忍的（流量就是钱，客户也是，公司也是）。
另外一点是对于开发人员来说维护困难。由于每个页面的业务逻辑都不相同，所以每个页面引用的资源文件也不会相同。但是当一个整站共用的文件出现了修改，那么整站的资源内容都要重新打包上传，如果不是某些框架或者工具为你处理的话，相信大家都会疯掉。
针对上述两个硬伤，马上出现了方案的改良版。将整站通用的资源打包一份，页面级的资源打包一份。页面上引用的资源数不再是一，而是二了。
改良后的方案，在遇到整站共用的内容发生修改时，仅仅重新打包整站共用资源即可，大大降低了维护成本。而遇到页面级逻辑发生修改时，用户也仅仅是重新下载新的页面级资源，相比以前好得多了。
所谓的三层架构，即将资源划分成 通用底层 - 通用组件层 - 页面级逻辑层 三层。相比上面一分为二的做法，这种方案将粗粒度稍微的多细分了一下，将整站通用资源分为了底层与组件层。这种方案在底层或组件层发生修改时可以更好的为用户节约流量。
通用底层 - 通用组件层 - 页面级逻辑层
上面的方案有点奔放，而这种方案就稍显别致了。将可细分的功能全部做为文件，并通过 hash 命名等手段在页面中引用。一旦一个功能做出修改，用户也仅仅需要下载该功能相关的资源。这对于大公司来说是有其必要性的。主要是因为大公司的网站 PV 量比较大，一个文件的修改都会消耗很多 CDN 上流量，所以要尽量控制所修改文件的大小。
这种方案是目前看过的最小粗粒度的方案，已经到了字符级别。通过向查询，当有内容发生修改时，服务器仅仅返回包裹修改内容的一些字符串，而并非整个文件。这个响应内容会被客户端接收并重新写入对应的修改处后生成新的本地缓存（基于 localStorage 方案）。
这个方案可以说是别致的让人诧异，最小化的减少因为修改而消耗的流量。
就介绍到这里了吧，下次有机会再讲讲各式各样的缓存方案吧。
浅谈前端缓存粗粒度
缓存对于我们前端来说是一个用于提高网页性能非常重要的工具。简单的“缓存”两字，其中包含了许多有趣的知识，其中对于缓存粗粒度的讨论也一直不绝于耳。
目前见过的缓存粗粒度分为三类：
下面让我们一起看看这三种方案的到底是如何处理生产环境下的缓存的。
以全部文件为最小单位
这种做法相当的直白而且由来历史悠久，无论开发过程中的文件有多少个，整个打包成一个文件后在页面中引用。这样做带来的好处是可以最大的减少对资源的请求数，至今仍使用这种方法进行线上缓存处理的网站还有很多（特别是某些后端框架自带合并资源功能时）。然而这种方案的缺点也十分明显。
由于太粗放，开发环境中的一个文件被修改，就会导致整个页面的资源都将失效。客户端不得不因为一小部分的修改，而重新下载所有的内容，这是移动互联网大环境下不能被容忍的（流量就是钱，客户也是，公司也是）。
另外一点是对于开发人员来说维护困难。由于每个页面的业务逻辑都不相同，所以每个页面引用的资源文件也不会相同。但是当一个整站共用的文件出现了修改，那么整站的资源内容都要重新打包上传，如果不是某些框架或者工具为你处理的话，相信大家都会疯掉。
改良版本一 —— 一分为二
针对上述两个硬伤，马上出现了方案的改良版。将整站通用的资源打包一份，页面级的资源打包一份。页面上引用的资源数不再是一，而是二了。
改良后的方案，在遇到整站共用的内容发生修改时，仅仅重新打包整站共用资源即可，大大降低了维护成本。而遇到页面级逻辑发生修改时，用户也仅仅是重新下载新的页面级资源，相比以前好得多了。
改良版本二 —— 三层架构
所谓的三层架构，即将资源划分成
通用底层 - 通用组件层 - 页面级逻辑层三层。相比上面一分为二的做法，这种方案将粗粒度稍微的多细分了一下，将整站通用资源分为了底层与组件层。这种方案在底层或组件层发生修改时可以更好的为用户节约流量。以单独文件为最小单位
上面的方案有点奔放，而这种方案就稍显别致了。将可细分的功能全部做为文件，并通过 hash 命名等手段在页面中引用。一旦一个功能做出修改，用户也仅仅需要下载该功能相关的资源。这对于大公司来说是有其必要性的。主要是因为大公司的网站 PV 量比较大，一个文件的修改都会消耗很多 CDN 上流量，所以要尽量控制所修改文件的大小。
以字符为最小单位
这种方案是目前看过的最小粗粒度的方案，已经到了字符级别。通过向查询，当有内容发生修改时，服务器仅仅返回包裹修改内容的一些字符串，而并非整个文件。这个响应内容会被客户端接收并重新写入对应的修改处后生成新的本地缓存（基于 localStorage 方案）。
这个方案可以说是别致的让人诧异，最小化的减少因为修改而消耗的流量。
就介绍到这里了吧，下次有机会再讲讲各式各样的缓存方案吧。
Thanks