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 already shipped this feature for android. We want to start experimenting with back-forward cache on desktop environments.
We are currently preparing for one. We’ll update this thread once we start.
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.
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.
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.
See these one-pagers
Privacy one-pager: BFCache Desktop: Privacy Explainer
Security one-pager: BFCache Desktop: Security Explainer
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..
We’d like to start an experimental rollout from M92, and expand the coverage as we go.
Any risks when the experiment finishes?
We already shipped this feature for Android.
This time, we want to extend its support for all the desktop platforms.
We are actively working on this (WHATWG), and we will file a PR soon.
Cross-site Intent-to-Ship for Android
Same-site Intent-to-Ship for Android
Link to entry on the feature dashboard
Thanks for expanding the BFCache to Desktop!Are we talking about a gradual roll-out here, or an 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.
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.