为什么 Chrome 在执行“正常重新加载”时不重新验证内存缓存？

Question

首先，我在网上找到了一些资源，这里和这里说的是同一件事：

对于正常/软重新加载，浏览器将重新验证缓存，检查文件是否被修改。

我在 Chrome 上测试过。我有一个网页index.html，它在body. 当点击刷新按钮（软/正常）时，我从网络面板看到的index.html是304 Not Modified，这很好。但是，所有 javascript 文件都加载from memory cache了状态代码 200。没有重新验证！

然后我尝试修改其中一个 javascript 文件。有没有软重载。你猜怎么着？该文件仍然是从内存缓存中加载的！

为什么 Chrome 会这样做？这不会破坏刷新按钮的目的吗？

以下是有关 Chrome 内存缓存的更多信息。

Answer 1

这是 Chrome 浏览器于 2017 年引入的一种相对较新的行为。

浏览器的众所周知的行为是在用户通过发送If-Modified-Since或If-None-Match标头刷新页面（通过使用 CTRL+R 组合或专用刷新按钮）时重新验证缓存的资源。它适用于通过 GET 请求获得的所有资源：样式表、脚本、html 等。这导致大量 HTTP 请求在大多数情况下以304 Not Modified响应结束。

最受欢迎的网站是那些内容不断变化的网站，因此他们的用户倾向于习惯性地刷新它们以获取最新的新闻、推文、视频和帖子。不难想象每秒钟有多少不必要的请求，而且据说最好的请求是从未提出过的请求，Facebook 决定解决这个问题，并要求 Chrome 和 Firefox 共同寻找解决方案。

Chrome提出了所描述的解决方案。

它不会使每个子资源失效，而是仅检查 HTML 文档是否发生更改。如果没有，这意味着很可能其他所有内容也没有被修改，所以它是从浏览器的缓存中返回的。当每个资源都有内容寻址的 URL时，这最有效；例如，URL 包含文件内容的散列。用户始终可以通过执行硬刷新来克服此行为。

Firefox的解决方案为开发人员提供了更多的控制权，并且是所有浏览器供应商都可以实施的好方法。那是新Cache-control指令：immutable.
您可以在此处找到有关它的更多信息：https : //developer.mozilla.org/pl/docs/Web/HTTP/Headers/Cache-Control#Revalidation_and_reloading

资源：

• Facebook 关于提议变更背后的动机、数字、比较的文章：https : //code.fb.com/web/this-browser-tweak-saved-60-of-requests-to-facebook/?utm_source=codedot_rss_feed
• Chromium 团队引入新行为：https : //blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html