While back-forward cache is already implemented in various browsers and affects many parts of the web platform, its behavior and effects haven't been properly reflected in the relevant specifications. This document contains the outline of the web-exposed changes for our implementation, and we are looking forward to working with Safari and Firefox in order to align our implementations and adjust the specs accordingly.
Implementing a back-forward cache with the right security and privacy properties is a non-trivial endeavor, especially given Chrome’s multi-process architecture. Consequently, before fully committing to doing so, we wanted to confirm that the value of this feature would outweigh its cost. To do so, we have been running an experiment in collaboration with Google Search using a minimally scoped version of the feature to verify its viability and infer how big of a difference such a feature would make on user experiences across the web. What we’ve been able to observe through this experiment gave us the confidence to continue investing in this feature. Here is our plan:
Increase the size of the experiment with Google Search to further confirm some of the movement on key metrics and inform our roadmap of features and user journeys to support
Launch BFCache for cross-origin navigations in M86
Add support for same-origin navigations in a following milestone
Add support for more features to further increase BFCache’s hit rate, and add support for desktop platforms
Work with Safari and Firefox, improve interop and standardize the behaviour.
Link to “Intent to Implement” discussion
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Initially back-forward cache will be supported only on Android as the UX flow on Android is centered around history navigation, while on desktops tabs play a much bigger role, therefore Android will benefit more from having a back-forward cache. Desktop-specific features (including extensions) mean that there is a non-trivial cost for launching on desktop, which we will address after launching this feature on Android.
We will not support Android WebView as the cost of integrating WebView embedding APIs with back-forward cache is too high, while history navigation optimisations have limited benefit for WebView given its nature.
DevTools can be connected only to the active pages, and pages in the cache are frozen and can’t be inspected. However, if a tab has an active DevTools connection, the entirety of the page execution can be seen in DevTools, including pageshow() handlers.
We are also planning on exposing the reasons why the page wasn’t restored from the back-forward cache via DevTools to give web developers information about how they can optimise their websites.
Interoperability and Compatibility
We will start with a cautious approach of not caching pages when faced with uncertainty (for example, when a page is using a non-trivial API like WebSocket [more examples]), which reduces the compat risk. The only major change is that unload() handler will not fire when the page is stored in the back-forward cache, but this matches Safari’s behaviour, thereby minimizing compat risk.
Web developers can disable bfcache for a given page by serving the main resource with Cache-Control: no-store header. We are gathering feedback from web developers and working with other browser vendors to introduce an explicit JS-based opt-out.
Enterprise policy for disabling back-forward cache will also be available.
N/A. Back-forward cache does not expose any API surface directly.
Back-forward cache will work without any developer activation, but web developers can make their pages bfcache-friendly with some extra work. This would further increase the cache hit rate and improve the user experience. We'll be working with partners and interested parties on this, as well as publish guidance on web.dev.
At the moment Chromium’s implementation of back-forward cache mostly relies on the Chromium browser tests and checks that the page is not cached in the presence of a given feature.
We will work with other browser vendors to align on the desired behaviour for each feature and will upstream the relevant tests to WPT [bug] when an agreement on the desired behaviour is reached.
Entry on the feature dashboard
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALHg4n%3DF0SqnL5iWfNDOvzgJb1O0n2LpsQTCEmx7KE2SyPH7%2Bw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh%3DAT-Sv-OUFBsCKD4G015cC4C%3DSTSKNAXS%3DyN2_ODn5A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_ULveSk_P1UWcaBwjCdWWV%3DnRh%2BM31skKu6ZUZLpDt7A%40mail.gmail.com.
Hi all,This I2S only mentions cross-site back-forward cache (where we only cache pages when doing a cross-site navigation, but not same-site navigation). We've been running experiments for same-site navigation support since August, and we think we're ready to ship same-site navigation support for back-forward cache now. Do we need a separate I2S for that? The web-exposed concerns should be covered by the original I2S here already :)