Intent to Ship: Cross-site back-forward cache on Android

[Alexander Timin]

Contact emails

bfcac...@chromium.org, alt...@chromium.org, har...@chromium.org, kenji...@google.com 

Explainer

[explainer]

Spec

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.

Summary

Back-forward cache is a browser feature which improves the user experience by keeping a page alive after the user navigates away from it and reuses it for session history navigation (browser back/forward buttons, history.back(), etc) to make the navigation instant. The pages in the cache are frozen and do not run any javascript.

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

• Short term:

• Launch BFCache for cross-origin navigations in M86

• Add support for same-origin navigations in a following milestone

• Longer term:

• 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

https://groups.google.com/a/chromium.org/g/chromium-dev/c/LoFLIabBwxM/m/RiUaCenFAQAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No.

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.

Demo link

back-forward-cache-tester.glitch.me

Debuggability

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. 

Risks

Interoperability and Compatibility

Medium.

Gecko: Shipping

WebKit: Shipping

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.

Ergonomics

N/A. Back-forward cache does not expose any API surface directly.

Activation

Mostly N/A.

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. 

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

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

https://www.chromestatus.com/feature/5815270035685376

[Yoav Weiss]

LGTM1

There's an ongoing conversation at the WebPerfWG about ways in which we could expose metrics from BF cached pages to developers. But as this is already shipped by other browsers, that conversation is not a blocker to shipping the feature.

--
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.

[Rick Byers]

Thank you for all the attention to detail you've put into how this gets exposed to developers and explained in specs. Given the state in other browsers and that this is limited just to Android where unload is already unreliable, I'm confident this is a significant step forward in interop with a reasonable compat risk (and a substantial user experience benefit to boot!). Paying back all the platform debt around this space with total spec and test coverage will be an ongoing journey, but I have confidence in the team to continue to iterate towards that ideal.

Given the reliance on unload handlers in some desktop enterprise applications, a separate intent will be necessary to weigh the compat risks if/when you feel ready to expand to desktop platforms.

LGTM2

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.

[Chris Harrelson]

LGTM3

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.

[Rakina Zata Amni]

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 :)

[Yoav Weiss]

We discussed this at the API owner meeting, and it seems better to send a new intent, so that it'd be clear to developers and the world that BFCache support is expanded from its current form to also cover the same-site case.

It's also not immediately clear that the compatibility risk of same-site case is of the same profile as the cross-site case, and if our behavior there matches the behavior of Safari and Firefox, that already shipped the same. That seems like something that would be good to discuss on the new intent.

[Rakina Zata Amni]

OK then, posted a new I2S just now. Thanks! :)