Intent to Experiment: Back-forward cache for desktop

[Minoru Chikamune]

Contact emails

bfcac...@chromium.org

Explainer

https://docs.google.com/document/d/1PmUFTxTJN4n-WyWry4tQ96t5P9XXkgwFo9CiNeslZEg/edit

Specification

BFCache is an already existing concept in HTML spec. The BFCache eligibility is referred to as “document salvageable state” [spec], and the navigation steps like “unloading a document” [spec] refers to BFCache as “keep document alive in a session history entry”.

Design docs

https://docs.google.com/document/d/1jwzZx_hUqca6ALmK2G1aNcykhWM1Bh79zRZlUg5KKjQ/edit

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.

We already shipped this feature for android. We want to start experimenting with back-forward cache on desktop environments.

Blink component

UI>Browser>Navigation>BFCache

Search tags

bfcache

TAG review

We are currently preparing for one. We’ll update this thread once we start.

Risks

Interoperability and Compatibility

Medium.

Gecko: Shipping

WebKit: Shipping

To reduce compatibility risk, 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]). The only major developer-facing difference for pages stored in the back-forward cache is that unload() handler will not fire. However, this is consistent with Safari’s behaviour, which should minimize compat risk.

Web developers can disable bfcache for a given page by serving the main resource with Cache-Control: no-store header. That said, we believe that this approach is sub-optimal, and we are looking for feedback from web developers on an explicit JS-based opt-out designed in collaboration with other browser vendors.

An enterprise policy for disabling back-forward cache will also be available.

Ergonomics

N/A. Websites don’t have to do anything (i.e. they will benefit from BFCache automatically).

In the very initial experimental rollouts, we plan to limit BFCache eligibility to pages that have explicitly opted-in via the BFCache-Opt-In header [explainer]. 

This restriction will be removed in a future rollout, as soon as we confirm the absence of stability regressions.

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 have published guidance on https://web.dev/bfcache/. Also we'll be working with partners and interested parties on this.

Security

See these one-pagers

• Privacy one-pager: BFCache Desktop: Privacy Explainer

• Security one-pager: BFCache Desktop: Security Explainer

Goals for experimentation

To gather statistics about BFCache stability and collect performance data. We also would like to get data on the reasons for which pages were excluded from being eligible to BFCache. This will help us prioritize our work to maximize BFCache’s impact..

Experimental timeline

We’d like to start an experimental rollout from M92, and expand the coverage as we go.

Any risks when the experiment finishes?

No.

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

We already shipped this feature for Android.

This time, we want to extend its support for all the desktop platforms.

Is this feature fully tested by web-platform-tests?

We are actively working on this (WHATWG), and we will file a PR soon.

Tracking bug

https://crbug.com/1171298

Launch bug

https://crbug.com/1196523

Links to previous Intent discussions

Intent-to-implement https://groups.google.com/a/chromium.org/g/chromium-dev/c/LoFLIabBwxM/m/zO9IcamEBAAJ

Cross-site Intent-to-Ship for Android

https://groups.google.com/a/chromium.org/g/chromium-dev/c/GL9gvgOIfTc/m/uh88OlmjAAAJ

Same-site Intent-to-Ship for Android

https://groups.google.com/a/chromium.org/g/blink-dev/c/XS9VnYQoaQE/m/ZODtCQs5BQAJ

Link to entry on the feature dashboard

https://chromestatus.com/feature/6279906713403392

[Yoav Weiss]

Thanks for expanding the BFCache to Desktop!

Are we talking about a gradual roll-out here, or an Origin Trial?

[Kouhei Ueno]

On Fri, Apr 30, 2021 at 3:59 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for expanding the BFCache to Desktop!

Are we talking about a gradual roll-out here, or an Origin Trial?

Sorry for the confusion.

We are talking about the gradual roll-out here. We are not using Origin Trial.

 

--
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/d7524d08-ca8a-4006-a78f-20cb8586993fn%40chromium.org.

--

kouhei

[Yoav Weiss]

Thanks for clarifying!

What do you have in mind in terms of percentages and timelines?

For an Origin Trial, we typically have start and end milestones. This case is different, so I'd like to understand what you had in mind on the above dimensions.

[Mike West]

Pinging for Yoav's question around timeline. :)

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU14KJGZgEkDoFhX9_47b3yf_NwOc2dBy6OCHntfWE7ig%40mail.gmail.com.

[Kouhei Ueno]

Apologies for the delay. We are in the middle of the holiday week in Japan.

> What do you have in mind in terms of percentages and timelines?

> For an Origin Trial, we typically have start and end milestones. This case is different, so I'd like to understand what you had in mind on the above dimensions.

The aggressive estimate is 6mo, and the conservative estimate is 12mo.

We are planning to enable BFCache by default (100%, with a separate Intent-To-Ship) as soon as it stabilizes for simple websites we are confident of, which doesn't use any of the sensitive features like those referred from this file [cs].

For the pages interacting with the web platform features which may be affected (the unload handler is a good example), we plan to roll out BFCache gradually, to prevent breakage. 

--

kouhei

[Yoav Weiss]

As a typical OT can run for 6 milestones (which is roughly 9 months), that timeline sounds in the same order of magnitude. The fact that the feature is already shipped in some platforms and is not an explicit API that the web can rely on also helps.

LGTM to experiment in those timelines.