Google is introducing a significant change to Chrome’s Back/Forward Cache (BFCache) behavior, allowing web pages to be stored in the cache, even if a webmaster specifies not to store a page in the browser’s cache.
“bfcache is an in-memory cache that stores a complete snapshot of a page (including the JavaScript heap) as the user is navigating away,” explains Google’s web.dev site.
“With the entire page in memory, the browser can quickly and easily restore it if the user decides to return.”
Site admins can specify how their web pages are stored in a browser’s cache using the “Cache-control:” header. One option is to use the “Cache-control: no-store” header, which prevents the website response from being stored in the browser.
However, browsers have not been storing webpages in bfcache if they use this header, causing performance issues when users return to those pages using the back and forward browser buttons.
Google to ignore the “no-store” header for the bfcache
Google proposes that webpages should be stored in the BFCache even when the “Cache-control: no-store” header is present on HTTPS pages. This approach would increase the instances of instant back/forward navigations, resulting in a better experience.
Google engineer Fergal Daly says that the primary objective isn’t to prevent the restoration of pages containing sensitive data. Instead, the focus is to avoid restoring pages with sensitive data that the user should no longer have access to.
If there are no changes to cookies, the assumption is that the browser’s HTTP requests, and thus access decisions, remain consistent. The challenge lies in server-side changes resulting in loss of access.
For sites using technologies like EventSource to reflect changes to open pages, these updates will trigger eviction from BFCache or deliver events promptly upon restoration. For sites without immediate update mechanisms, there’s a risk that users may access outdated data, which the proposed BFCache behaviour could potentially exacerbate.
Google is working on addressing these concerns by rolling out the feature to test channels first and getting enough data to understand the impact.
Some have raised concerns that this change could break promises to web developers who assume that the “Cache-control: no-store” header means the browser will not cache the webpage.
“To me this seems to be touching a sensitive area and I’m not certain how this will play out in the real world,” commented Opera developer Daniel Bratell.
“Even if cache-control: no-store is being badly overused, and the numbers you list seem to indicate that is the case, hasn’t there been a promise to web developers that such a resource will be forever gone once the page is no longer shown, and is that a promise that can reasonably be broken?”
However, Daly says that this header only promises not to store a web page in the regular browser cache, not the bfcache.
“There is no explicit promise that CCNS prevents BFCaching. The CCNS header, or in general, all the Cache-control directives, are intended to control the HTTP caching, so the explicit promise is about HTTP cache,” explained Daly.
“BFCache is not part of the HTTP caching, and developers should not interpret the CCNS header as a promise that the page will not be BFCached.”
By redefining how BFCache interacts with the “Cache-control: no-store” directive, Google Chrome developers hope to create a more responsive browsing experience without compromising user security and privacy.
Source: www.bleepingcomputer.com