Intent to Ship: Back-forward cache for desktop

163 views
Skip to first unread message

Minoru Chikamune

unread,
Aug 18, 2021, 9:14:57 AMAug 18
to blin...@chromium.org, bfcac...@chromium.org

Contact emails

bfcac...@chromium.org


Explainer

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


Specification [updated since Android I2S]

Back-forward cache (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”. We have been actively improving BFCache in standards through writing guidelines on how web platform features should interact with BFCache, filing and fixing current spec issues, and making it possible to test BFCache through WPTs (+ writing the WPTs).


Design docs [unchanged]

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 ship back-forward cache on desktop environments.


Link to “Intent to Experiment” blink-dev discussion

https://groups.google.com/a/chromium.org/g/bfcache-dev/c/6nKwd472yPI


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

No.


We already shipped this feature for Android.

We would like to proceed shipping of BFCache to Windows, Mac, Linux and Chrome OS platforms with this I2S.


We do not have active plans to 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.


Debuggability [unchanged]

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.


Blink component

UI>Browser>Navigation>BFCache


Search tags

bfcache


Risks

Interoperability and Compatibility [updated since Android I2S]

Interoperability - Low, given that we have been shipping it on Android, along with other vendors.


Gecko: Shipping

WebKit: Shipping

Chrome Android: Shipping


Since shipping on Android, we have made significant progress on the standardization front. The W3C TAG agreed to put BFCache considerations to their Design Principles guideline [pull, pull], so all future APIs will have BFCache support explicitly specified. The BFCache interaction is now part of OWP Security Review as well.


Compatibility - Low.


To minimize compatibility risk, we continue to take the cautious approach of not caching pages when faced with uncertainty.


Notable difference to the Android launch is unload handlers. For this release, we mitigated the risk by requiring the `BFCache-Opt-In: unload` response header specified by the page author to put pages with unload handlers to BFCache. We will not fire unload events when the page is BFCached. This was less of an issue on Android, since the unload handlers were not reliable on Android anyway. Desktop Chrome also didn’t guarantee the unload handler as well, but it is fired most of the time that many desktop websites rely on it. Again, we don’t BFCache such pages without the page authors’ consent in this release, but we might want to revisit this in the future (related: Firefox experiment). An enterprise policy for disabling back-forward cache is available.


Ergonomics [unchanged]

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


Activation [unchanged]

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 [new!]

See these one-pagers


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

We are actively making progress in the area.


Tracking bug

https://crbug.com/1171298


Launch bug

https://crbug.com/1196523


Link to entry on the feature dashboard

https://chromestatus.com/feature/6279906713403392


Domenic Denicola

unread,
Aug 18, 2021, 1:01:14 PMAug 18
to Minoru Chikamune, blin...@chromium.org, bfcac...@chromium.org
This header seems like a significant interop risk, as I'm not aware of any specification for it, or signals from other vendors.

It would be good to get a specification pull request written to HTML, appropriate WPT coverage, and ideally some agreement from other vendors that they want to go this route, before shipping.
 

Ergonomics [unchanged]

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


Activation [unchanged]

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 [new!]

See these one-pagers


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

We are actively making progress in the area.


Tracking bug

https://crbug.com/1171298


Launch bug

https://crbug.com/1196523


Link to entry on the feature dashboard

https://chromestatus.com/feature/6279906713403392


--
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/CAEy%2BVDLEkNUVt%2Bk4u6w0xzL-XHovRqtq%2BUx6atJdeo0-rBZaUw%40mail.gmail.com.

Yoav Weiss

unread,
Aug 18, 2021, 5:28:18 PMAug 18
to Minoru Chikamune, blink-dev, bfcac...@chromium.org
That's a Google-only document. Can you please link to a public version of the explainer?
 

Specification [updated since Android I2S]

Back-forward cache (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”. We have been actively improving BFCache in standards through writing guidelines on how web platform features should interact with BFCache, filing and fixing current spec issues, and making it possible to test BFCache through WPTs (+ writing the WPTs).


Design docs [unchanged]

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


Similarly, can you link to public docs?
 

Minoru Chikamune

unread,
Aug 23, 2021, 12:07:16 AMAug 23
to Yoav Weiss, blink-dev, bfcac...@chromium.org
Sorry for the late reply. For the public version of the documents (explainer and design docs),
Please refer to the following documents. 


> That's a Google-only document. Can you please link to a public version of the explainer?

TAMURA, Kent

unread,
Aug 23, 2021, 3:54:23 AMAug 23
to Domenic Denicola, Minoru Chikamune, blin...@chromium.org, bfcac...@chromium.org
I agree with Domenic.
What's the status of the standardization effort of the 'BFCache-Opt-In' header?




--
TAMURA Kent
Software Engineer, Google


Minoru Chikamune

unread,
Aug 23, 2021, 11:26:34 PMAug 23
to TAMURA, Kent, Domenic Denicola, blink-dev, bfcac...@chromium.org

We respect the API OWNER feedback that the status of BFCache-Opt-In header spec would cause more interoperability issues. We actually did plan on standardizing the header after Domenic raised a similar concern internally a while back, and already prepared the explainers etc for it, but it got accidentally dropped amidst the thick of things our team was doing to ensure the Desktop experiment goes smoothly. Then when the time came to draft our I2S, everyone thought the opt-in header had actually gone through the standardization process as planned before, and here we are. Apologies if this came off as not wanting to standardize something before shipping it, it’s definitely not our intention.

 

Now, let us retract the "BFCache-Opt-In" header part from the I2S. We would appreciate your reviews under the new condition. Specifically, we would like to request shipping a version of BFCache for Desktop that forbids all pages with an unload handler to enter BFCache.


The following paragraph from the original post:

Notable difference to the Android launch is unload handlers. For this release, we mitigated the risk by requiring the `BFCache-Opt-In: unload` response header specified by the page author to put pages with unload handlers to BFCache. We will not fire unload events when the page is BFCached. This was less of an issue on Android, since the unload handlers were not reliable on Android anyway. Desktop Chrome also didn’t guarantee the unload handler as well, but it is fired most of the time that many desktop websites rely on it. Again, we don’t BFCache such pages without the page authors’ consent in this release, but we might want to revisit this in the future (related: Firefox experiment). An enterprise policy for disabling back-forward cache is available.


Should now read:

  To mitigate the risk of breaking unload events, in this I2S, we would like to request shipping BFCache on Desktop which does not cache pages with unload handlers. (We plan to standardize and file a separate I2S for making pages with unload handlers BFCache-eligible in the future.)


chikamune@, kouhei@, and rakina@


TAMURA, Kent

unread,
Aug 24, 2021, 8:26:27 PMAug 24
to Minoru Chikamune, blink-dev, Domenic Denicola, bfcac...@chromium.org
Excluding the "BFCache-Opt-In" part sounds good.
LGTM1.

Yoav Weiss

unread,
Aug 26, 2021, 3:32:25 AMAug 26
to blink-dev, Kent Tamura, Domenic Denicola, bfcac...@chromium.org, Minoru Chikamune
LGTM2

I think that the header can be useful to help align BFCache behavior across engines. I'm looking forward to standardization efforts on that front.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.


--
TAMURA Kent
Software Engineer, Google


Domenic Denicola

unread,
Aug 26, 2021, 11:04:37 AMAug 26
to Yoav Weiss, blink-dev, Kent Tamura, Domenic Denicola, bfcac...@chromium.org, Minoru Chikamune
Non-owner LGTM; thanks for splitting the intent in that way! I look forward to reviewing the HTML spec PR for the header, and as HTML editor am really happy with the other bfcache standardization work the team has been doing.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

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


--
TAMURA Kent
Software Engineer, Google


Chris Harrelson

unread,
Aug 26, 2021, 11:08:42 AMAug 26
to Domenic Denicola, Yoav Weiss, blink-dev, Kent Tamura, bfcac...@chromium.org, Minoru Chikamune
Reply all
Reply to author
Forward
0 new messages