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

[Rakina Zata Amni]

Contact emails

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

Explainer

[explainer] - same as cross-site I2S, see “Summary” for why we’re shipping separately

Spec

We have been working with other browser vendors on specifying various aspects that are affected by the back-forward cache - see meta-bug. Additionally, this document [same as the one listed in cross-site I2S] contains the outline of the web-exposed behaviour for our implementation. 

Summary

We want to add support for putting pages in the back-forward cache after same-site navigations. We have previously shipped back-forward cache with only cross-site navigations supported [see I2S]. Since then, we have implemented and experimented with same-site navigation support, and are ready to ship it now.

The reason why we shipped separately was because some architectural changes in Chromium are required to support making a page fully independent from the next page in the same tab after a same-site navigation [relevant docs: 1, 2, 3, 4, 5]. For cross-site navigations, we didn’t need to do as much work due to Site Isolation: most things in Chromium code already expect pages in the same tab to be completely independent after cross-site navigations.

Web-exposed behaviour with this addition is the same as when only cross-site navigation is supported. Some web-platform features do have interesting interactions that are possible only with same-site or same-origin pages, e.g. localStorage is shared between all windows with the same origin. However, as pages in the back-forward cache are “frozen”, no changes in other pages will affect the page until it gets restored from the back-forward cache. Anything trying to access or communicate with a page in the back-forward cache will result in the back-forward cached page getting evicted, e.g. ServiceWorker’s postMessage().

As noted in the “Risks” section below, the only major change for back-forward cache in general is the fact that we won’t dispatch unload events on navigation when the page gets stored in the back-forward cache. We expect this to affect same-site cases more than cross-site cases, but the risk should be low because this matches Safari's behaviour.

Link to “Intent to Prototype” blink-dev discussion

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

Cross-site back-forward cache I2S: https://groups.google.com/a/chromium.org/g/bfcache-dev/c/tFxnLR8pLW4/m/twZiKKAXBQAJ 

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

[same as cross-site I2S]

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

Support for DevTools is planned and currently being implemented. With this addition, web developers can see a list of reasons why their page is not eligible for bfcache.

Risks

[mostly same as cross-site I2S]

Interoperability and Compatibility

Medium.

Gecko: Shipped

WebKit: Shipped

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. We expect this to affect same-site cases more than cross-site cases,  but this matches Safari’s behaviour, thereby minimizing compat risk. We've also updated the HTML spec recently to allow this

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 opt-out mechanism.

Enterprise policy for disabling back-forward cache is also 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.

[same as cross-site I2S]

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

--
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/CACPC1r44davHtw261NT4Z%3Dc1C-SQc7UvTOrnyoMmc29o_%2Bdisg%40mail.gmail.com.

[Manuel Rego Casasnovas]

> On Thu, Nov 19, 2020 at 7:08 AM Rakina Zata Amni <rak...@chromium.org
> <mailto:rak...@chromium.org>> wrote:
> As noted in the “Risks” section below, the only major change for
> back-forward cache in general is the fact that we won’t dispatch
> unload events on navigation when the page gets stored in the
> back-forward cache. We expect this to affect same-site cases more
> than cross-site cases, but the risk should be low because this
> matches Safari's behaviour.

It's mentioned this matches Safari's behavior, but what happens with
Firefox? The interop sections mentions it's shipped in both, but nothing
regarding Firefox is mentioned, only Safari.

Please could you clarify that?

Thanks,
Rego

[Rakina Zata Amni]

Firefox's behavior is to not cache pages with beforeunload/unload handlers, so it's not hitting this problem at all. Some relevant links: spec issue & PR, unload + bfcache doc, Chromium's overall bfcache web-exposed behavior doc. Let me know if more clarification is needed!

 

Thanks,
  Rego

[Rick Byers]

LGTM2

Thank you for continuing to drive alignment with Safari and Firefox and improve the spec and WPT situation. 

Rick

--

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/CACPC1r7r4BzbaggyMLEzObu51CGSST29iQVRpkTU1_ePRN5Skw%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-BaDQkEOPJNyQYMK%3DXgndggtDBRYmM%3DNhLdjVzP_tFcQ%40mail.gmail.com.