Intent to Ship: Back-forward cache for desktop
Minoru Chikamune
Contact emails
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
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
Privacy one-pager: BFCache Desktop: Privacy Explainer
Security one-pager: BFCache Desktop: Security Explainer
Is this feature fully tested by web-platform-tests?
We are actively making progress in the area.
Discussions on test framework APIs needed for BFCache tests are ongoing around WPT PR and WPT RFCs (86, 88-91).
We have more draft WPTs that will be ready for code review once the discussions on test framework is settled.
Tracking bug
Launch bug
Link to entry on the feature dashboard
Domenic Denicola
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
Privacy one-pager: BFCache Desktop: Privacy Explainer
Security one-pager: BFCache Desktop: Security Explainer
Is this feature fully tested by web-platform-tests?
We are actively making progress in the area.
Discussions on test framework APIs needed for BFCache tests are ongoing around WPT PR and WPT RFCs (86, 88-91).
We have more draft WPTs that will be ready for code review once the discussions on test framework is settled.
Tracking bug
Launch bug
Link to 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/CAEy%2BVDLEkNUVt%2Bk4u6w0xzL-XHovRqtq%2BUx6atJdeo0-rBZaUw%40mail.gmail.com.
Yoav Weiss
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
Minoru Chikamune
> That's a Google-only document. Can you please link to a public version of the explainer?
TAMURA, Kent
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_dJY4HC%2BNKOH62Eh4RRE-z6FnFXqXXEDBKPKJB49ZOiw%40mail.gmail.com.
Software Engineer, Google
Minoru Chikamune
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
Yoav Weiss
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_dJY4HC%2BNKOH62Eh4RRE-z6FnFXqXXEDBKPKJB49ZOiw%40mail.gmail.com.
--TAMURA Kent
Software Engineer, Google
Domenic Denicola
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.
--
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/CAM0wra_dJY4HC%2BNKOH62Eh4RRE-z6FnFXqXXEDBKPKJB49ZOiw%40mail.gmail.com.
--TAMURA Kent
Software Engineer, Google
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-WCeUjo237A3W8_qVk-GZipa3euhhPA3fcJe%3DPctyHXA%40mail.gmail.com.