为什么Chrome不会在进行正常重新加载时重新验证内存缓存？＆＃34;

Question

首先，我在网上发现了一些资源here和here说同样的事情：

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

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

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

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

Here是有关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
• 铬团队介绍新的行为：https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html

Answer 2

浏览器缓存比简单的200和304更复杂，并注意标题中的服务器端指令，告诉他们如何处理每个特定站点的缓存。

我们可以使用各种标题（例如Cache-Control）调整浏览器缓存配置文件，具体设置过期前的时间，您可以告诉浏览器使用本地副本而不是请求新的副本，这些可以是在你不想改变的内容（即公司徽标）的情况下非常积极。通过执行类似Cache-Control: public, max-age=31536000

的操作

此外，您还可以设置Expires标题，这样您几乎可以像Cache-Control那样执行相同操作，但控制权稍微少一些。 只是设置浏览器认为资产失效并重新请求之前要经过的时间。虽然通过重新请求，如果未从服务器发回未修改的响应代码，我们仍然可以获得缓存结果。

许多Web服务器都启用了设置，允许对某些资产文件（js，图像，css）进行更积极的缓存，但不太积极地缓存内容文件。