为什么Chrome在执行“正常重新加载”时不重新验证内存中的缓存？ [英] Why doesn't Chrome re-validate in-memory cache when doing a "normal reload?"

问题描述

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

First, I found some resources online here and here saying about the same thing:

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

For a normal/soft reload, the browser will re-validate the cache, checking to see if the files are modified.

我在Chrome上对其进行了测试。我有一个网页 index.html ，该网页在 body 的末尾加载了一些JavaScript文件。当点击刷新按钮（软/正常）时，在网络面板上，我看到 index.html 是 304未修改 ，这很好。但是，所有的javascript文件都是从内存缓存加载的，状态码为200。没有重新验证！

I tested it on Chrome. I have a webpage index.html which loads a few javascript files in the end of body. When hitting the refresh button (soft/normal), from the network panel I saw index.html was 304 Not Modified, which was good. However, all the javascript files were loaded from memory cache with status code 200. No revalidation!

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

Then I tried modifying one of the javascript files. Did the soft reload. And guess what? That file was still loaded from memory cache!

为什么Chrome会这样做？

Why does Chrome do this? Doesn't that defeat the purpose of the refresh button?

此处是有关Chrome内存缓存的更多信息。

Here is more information about Chrome's memory cache.

推荐答案

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

This is a relatively new behaviour which was introduced in 2017 by Chrome browser.

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

The well-known behaviour of browsers is to revalidate cached resource when the user refreshes the page (either by using CTRL+R combination or dedicated refresh button) by sending If-Modified-Since or If-None-Match header. It works for all resources obtained by GET request: stylesheets, scripts, htmls etc. This leads to tons of HTTP requests that in the majority of cases end with 304 Not Modifiedresponses.

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

The most popular websites are the ones with constantly changing content, so their users tend to refresh them habitually to get the latest news, tweets, videos and posts. It's not hard to imagine how many unnecessary requests were made every second and as it is said that the best request is the one never made, Facebook decided to address this problem and asked Chrome and Firefox to find a solution together.

Chrome 提出了上述解决方案。

Chrome came up with the described solution.

而不是使每个子资源无效，它仅检查HTML文档是否已更改。如果没有，则意味着很可能其他所有内容也都未修改，因此它是从浏览器的缓存中返回的。当每个资源都有内容寻址的URL 时，这种方法最有效；例如，URL包含文件内容的哈希值。用户始终可以通过执行强制刷新来克服这种行为。

Instead of invalidating each subresource, it only checks if the HTML document changed. If it didn't, it means that it's very likely that everything else also wasn't modified, so it's returned from browser's cache. This works best when each resource has content addressed URL; for example, URL contains a hash of the content of the file. Users can always overcome this behaviour by performing a hard refresh.

Firefox 的解决方案为开发人员提供了更多控制权，并且这是一个好方法由所有浏览器供应商实施。那就是新的 Cache-control 指令：不可变。

您可以找到更多信息关于此内容： https://developer.mozilla.org / pl / docs / Web / HTTP / Headers / Cache-Control＃Revalidation_and_reloading

Firefox's solution gives more control to developers, and it's on a good way to be implemented by all browser vendors. That is the new Cache-control directive: immutable.
You can find more information about it here: 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.htm l

• Facebook's article about the motivation behind proposed change, numbers, comparisons: https://code.fb.com/web/this-browser-tweak-saved-60-of-requests-to-facebook/?utm_source=codedot_rss_feed
• Chromium team introducing new behaviour: https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html

这篇关于为什么Chrome在执行“正常重新加载”时不重新验证内存中的缓存？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！