浏览器缓存最佳实践

最佳实践

上来先说结论，缘由放在后面：

1. index.html 不作缓存，每次请求都获取最新版本
2. 使用 webpack 等 build 后的其余全部资源文件（包括 js、css 和图片等），都作强缓存（一个月打底，能够设置一年）

缘由

强缓存和协商缓存在社区已经被写烂了，都知道是怎么回事，这里就不作详细解释了，这里解释下为何说上面的是最佳实践。

咱们知道协商缓存其实也向服务端发起了一个请求，只不过最后通过一系列验证，结果就是不传输具体内容了，可是验证的过程也给后端形成了一些开销，因此咱们要尽可能减小这种开销。

那么把前端资源都用做强缓存就是最好的处理办法了，可是又面临一个问题『前端发版怎么更新』

这时候咱们须要注意 build 后的前端资源，如今各个脚手架默认都会把文件名字生成一段 hash 值
xxx.6ae44c4e.js这种。原来我一直不明白这样的意义在哪，如今明白了。

首先 index.html 不作缓存，因此当咱们发版之后浏览器会获取到最新的 index.html 文件，因为每次 build 以后生成的文件名字不一样，index.html 引入的前端的资源就不一样，旧的全部的资源文件包括 js、css 和图片等）都不会影响新发版的内容。

这样的话就作到了在不发版的状况下，每次刷新基本就一个 index.html 的资源还有一些接口请求，其他的全都是强缓存资源。发版以后能够立马更新，不会形成资源混乱。如今掘金和 segmentfault 都是采起的这种策略。

实践数据对比

和运维的同事商量了强缓存的优化，将 build 以后的 static 文件夹所有作了 add_header Cache-Control "max-age=30243600"，也就是强缓存 30 天的设置。

通过测试发现，由协商缓存到强缓存后，有以下变化：

类型	请求数	实际传输资源大小	传输完毕（Finish）	DOMContentLoaded	Load
协商缓存	631	168K	2.00s	447 ms	717 ms
强缓存	631	23K	1.43s	424 ms	704 ms

结果分析

首先，请求数量是同样的，彻底 Load 的时候差很少，Finish 的时间提高了 25%，传输的资源大小减小了 80% 以上，同时因为没有和服务端去进行协商，至关于对服务端也作了优化。这些都是在协商缓存的基础上作的优化对比，若是后端服务连协商缓存都没上的话，真的应该优化一下了。