关于缓存和 Chrome 的“新版刷新”
在读本文前你要确保读过我的上篇文章《扼杀 304，Cache-Control: immutable》，因为本文是接着上文写的。上文说到，在现代 Web 上，“条件请求/304 响应”绝大多数都是浪费资源，因为绝大多数静态资源都是永恒不变的，因此 Firefox 实现了 Cache-Control: immutable 来让开发者们控制用户浏览器的刷新行为，即在刷新时不要对这些资源文件进行条件请求（缓存不过期的前提下）。
Chrome 至今迟迟没有实现 Cache-Control: immutable，难道 Chrome 不想让自己的网页在刷新时展现的更快？不是的，其实 Chrome 的开发人员也早已注意到了这个问题。早在 2015 年底，他们就开发出了一种新的刷新行为，称之为 new reload/faster reload/non-validating reload，这种新的刷新和以前传统的刷新有个区别，那就是在刷新页面时，只对页面本身的资源文件进行条件请求（如果缓存了的话），页面里引用的各种子资源文件，只要缓存不过期，就直接读取缓存。也就是说，“你们开发者压根不用去加什么 Cache-Control: immutable 响应头了，我 Chrome 直接改成刷新不发条件请求就得了”。
Chrome 在 2015 年底只针对安卓端的 Chrome for Android 中的下拉刷新开启了这种新的刷新，下面是当时的 commit log：
Make pull to refresh not perform regular reload (with cache revalidation)
Pull-to-refresh action on Android is currently handled as a
regular reload, which causes revalidation of cached contents,
however the action would usually imply that the user wants to
refresh the 'contents' rather than reloading everything (e.g.
to reset the page contents when something's screwed up).
这段话中说到，用户刷新一个页面通常都不是为了重新请求每个资源文件看是不是过期了，而仅仅是为了重置一下页面的状态，所以要做这个优化。下面是当时测试效果的对比演示，左旧右新：
可以看到，左侧有明显的加载白屏阶段，而右侧没有。
在 16 年 5 月份，Chrome 把该刷新行为应用到了 PC 端，从 Chrome 54 开始默认启用。我写了一个测试 demo，在 Chrome 54 之前，刷新这个 demo 后效果是这样的：
所有的资源都会被发起条件请求从而返回 304 响应，而在 Chrome 54 里，刷新这个 demo 后效果成了：
只有页面本身被发起了条件请求，所有引用的子资源都直接读取了缓存，也就是说，实际上刷新这个页面只触发了一个 HTTP 请求。
额外小技巧
从 Chrome 56 开始，你可以通过网络面板新增的 is:from-cache 过滤条件来过滤出直接读取缓存的请求（即没有发送真实的 HTTP 请求的请求），还可以利用它的反向过滤找出发送了真实请求的请求，像下面这样（还是上面的 demo）：
这个过滤条件是我向 Chrome 提议的。
不知道你们注意过没有，除刷新外，常规加载一个网页的途径有两种，最常见的一种是通过点击其他页面的超链接（包括浏览器书签）进入当前页面，还有一种是在浏览器地址栏上输入网址并回车（高级用户），这两者在发送请求上也是有区别的。前者是不会发起任何条件请求的（除非缓存过期），而后者是会为页面资源本身发起条件请求的（你可以用上面的 demo 做测试），Chrome 新的这个刷新机制其实就是把刷新改得和在地址栏回车一样了。鉴于现如今的大多页面都是动态页面（没有 Cache-Control/Expires/Last-modified 响应头），不会被缓存，所以如今这三者在 Chrome 上的差别已经很小了。
如果你已经升级到了 Chrome 的最新版，没法找到 Chrome 54 之前的版本来做对比测试，可以试试通过停用 chrome://flags/#enable-non-validating-reload-on-normal-reload 选项来切回老版的刷新，不过这个选项在 Chrome 56 里已经被彻底删除了：
读到这里，有同学就想问了，“难道 Chrome 这样做不违反 HTTP 协议吗？”。并没有，HTTP 协议只会规定客户端应该怎么发一个条件请求，服务器应该怎么响应这个条件请求，但不会规定应用程序何时应该发送条件请求。
那 location.reload() 呢，也会改成新版刷新吗？从 Chrome 56 开始 location.reload() 也会使用新版刷新。HTML 规范并没有明确的说明 location.reload() 应该如何对待缓存，只略略提到了一句：
User agents may allow the user to explicitly override any caches when reloading.
这句话应该是给 Firefox 的 location.reload(true) 准备的。
那对用户来说，这个改动向后兼容吗？从我注意到 Chrome 的这个改动后，一直以为这是 Chrome 的 bug，但提 bug 后被告知这是有意的。我当时觉的这个改动太激进了，毕竟打破了二十年多年的浏览器传统，一定会有用户反馈不兼容问题的。但直到这个改动进入稳定版后，也没有一个人反馈。。。仿佛全世界只有我一个人注意到了这个改动。
但对开发者来说，其实这个改动的确是有点不向后兼容的。比如某个带有特定版本号的资源在发布到 daily 环境后，是可以不换版本号（URL）反复覆盖式更新的，但你在浏览器里刷新却看不到效果，只能借助于开发者工具的 Disable cache 功能。不过最终用户是没这个问题的，因为线上是无法覆盖式发布的。
所以现在我的看法变了，Firefox 和其他浏览器应该变的像 Chrome 一样，Cache-Control: immutable 已经几乎没有价值了（除非我漏掉了某个点），能让所有的网页变的更快，为什么不呢。
俗话说的好，“前端有三宝，清缓存、清 cookie、换个浏览器”。以后在 Chrome 里单纯的刷新是真的不行了，要教用户怎么“强制刷新/跳过缓存刷新”了。
可以看到自己公司 CDN 日志的同学们，可以看看最近 304 响应的占比有没有大幅减少，不过国内的话也许需要等国产浏览器的内核更新后才行。
