Gilberto: work on Chrome partnerships, CWVs, etc
…
… Many navigation types. Back_forward full navigation vs. back_forward_cache
… Possible to measure this in CrUX
… why should developers care about BFCache?
…
…
… hard to understand why BFCache didn’t work, understanding the reasons in an interoperable way, understand what they need to do, and properly measure
… Step 0 - understanding what improvements can be made
… Many blocking reasons
.. Need to also understand the actionability. Some issues are fixable by the developer, but there are also blocking reasons which aren’t (some APIs, e.g. sharedWorker which are incompatible with BFCache)
… Exposing this data can help both developers and browser vendors to help them increase BFCache at scale
…
… Cache-Control: no-store is pervasive and used to completely prevent BFCache in chrome. Added partial support in Chrome, but limited impact on the number of origins.
… Some CMS/platforms have CCNS headers on most responses, which seems wrong
… Some of them are not aware of it, and can easily remove it
… When BFCache started working on a large CMS, CLS collapsed
… for unload events, most usage is coming from 3Ps, but also older versions of jQuery
… Developers can block that using permission policy
… there are plans in Chrome to fully deprecate it (aiming for 1 year)
… WebSockets also prevent BFCache on Chrome, when held incorrectly. Most developers are *not* using it right (mainly 3Ps - chat widgets, support, AI), preventing BFCache even when the widget is not used
… The right thing to do is to close the connection on pagehide (and restore it on pageshow)
Jacob: does socket.io implement this?
Gilberto: great Q, but they don’t. Please thumb-up the issue
…
… Chrome fixed a bunch of related papercuts, and removed APIs from blocking BFCache
… Significant improvements at the HTTPArchive
…
… Saw significant improvements in Chromium based browsers
… Don’t know what did Safari do to get a 6.5% bump. Could be the sites that changed
… notRestoredReason - allows developers to collect this data from the wild
… Some differences with DevTools reporting (for privacy reasons)
… e.g. you don’t get reasons for cross-origin iframes
Nic: glad we have telemetry from RUM. Helpful for our customers to pippoint top offenders.
… Anything beyond it that can be even more helpful. What more can we do?
Gilberto: Sending the reason may help, but developers may not fully understand it. E.g. unload event handler could be present in many iframes, and also maybe not present in e.g. all ads
Nic: For WebSocket, the author could change the page to close the connection at pagehide?
Gilberto: it’s a fixable scenario. It used to be racy, but now that’s fixed and developers can handle it. But when it’s coming from a 3P, developers can’t do much
Barry: But APIs like shared workers mean that developers can’t handle it
Nic: So need evangelism + fixing libraries
Gilberto: There are efforts to make shared workers into BFCache compatible, which will turn it into fixa
Yoav: In terms of the reasons, I wanted to point out that unlike many of the other performance measurement tools, where tools can say improving perf for one browser is likely to improve performance for other browser. Unlike BFCache, where underlying behvioar is different for each browser, I think this is somewhere where different engines exposing this would be ideal. Offenders doing different things in different browsers
… In terms of reasons themselves, how many are standardized vs. implementation specific?
… Will two browsers expose same string in same scenario?
… Yes they should be used, not always same as exposed in Lighthouse, but they were merged into HMTL spec
Yoav: Fixed list, if another browser became relevant, they can align with the right string
Barry: wanted to say that Chrome data is population-biased. BFCache is different in different browsers. When other browsers implement, they may discover different reasons
… Unsure if this is collected internally in other browsers
Gilberto: RUMArchive data shows that there are significant opportunities. Working with Chrome engineering helped solve various APIs and make them compatible. Other vendors can find similar wins.
Nic: Any key requests from this group? What would you like this group to facilitate?
Gilberto: we cannot take for granted that developers understand BFCache. Asking folks for ideas to nudge developers away from the anti-patterns.
… Similar to what we did with LoAF and INP. May be possible to do something similar
NoamH: Was there any thinking around soft navigation and enabling it there?
Barry: It works for SPAs, but not inside the SPA. Inside the SPA those are typically quick, and handle outside of the browser’s knowledge. BFCache freezes the state and SPAs typically change the state
Gilberto: e.g. Youtube is an SPA, but have 10% BF navigation, so there is an opportunity for SPA external navigations.
… Pages that are e.g. listing tend to have significantly more BF navigation
… In terms of potential savings on infrastructure, it’s also worth considering
Yoav: Are there official positions from Mozilla or Apple?
Barry: I think there was OK being merged into HTML spec but no commitments towards implementation
Yoav: You need support but not necessarily implementation
Barry: browser vendor feedback improved the API’s privacy
Benjamin: BF cache is important, I can ask about the issues with Reasons
