new audit: bfcache eligibility

[paulirish]

Provide a basic description of the audit

Expose reasons why a page isn't a candidate for bfcache

https://web.dev/bfcache/

Basically exposing the same data that's in the BFCache Devtools panel:

How would the audit appear in the report?

When failing it'd list all the failing reasons with nice strings.

The reasons come from the protocol. This event provides them: Page.BackForwardCacheNotRestoredExplanationTree

(There are a lot of reasons. 123 of them!)

I didn't follow exactly how devtools triggers the right kind of navigation/reload that will get this event. But... presumably something.

It appears the panel does:

1. Page.navigate('chrome://terms')
2. wait for Page.FrameNavigated
3. Page.navigateToHistoryEntry
4. read this Page.BackForwardCacheNotRestoredExplanationTree event

How is this audit different from existing ones?

@brendankenny did an unload handler one. I recall him saying we werent ready for more bfcachey things... but don't recall specifics.

What % of developers/pages will this impact?

All pages can benefit from bfcache.

How is the new audit making a better web for end users?

Faster navigations. (close to zero TTFBs)

What is the resourcing situation?

LH core team.

Any other links or documentation that we should check out?

• https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/panels/application/components/BackForwardCacheView.ts
• https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/panels/application/components/BackForwardCacheStrings.ts
• 1198552 - Support bfcache feature team - chromium
• 1288158 - Show bfcache blocking reasons in DevTools in frame tree structure - chromium

[brendankenny]

@brendankenny did an unload handler one. I recall him saying we werent ready for more bfcachey things... but don't recall specifics.

I think there were two big things:

• bfcache criteria wasn't stable and wasn't consistent cross-browser. I think that's settled a lot as Chrome desktop and mobile bfcache have reached parity and Chrome has expanded support for most of the conditions that Firefox and Safari already supported (all three still differ but I believe there's a pretty large intersection now)
• static analysis is difficult and by far the most effective/easiest way to test bfcache is to do an actual navigation. I believe that's how the DT panel does it (see the message at the top):

to trigger back/forward cache, use Chrome's back/forward buttons, or use the test button below to automatically navigate away and back.

[connorjclark]

I assume all these reasons have their own translated strings in CDT frontend. We should probably take the time to figure out how to reuse this stuff across protocol frontends. Was it documented anywhere why we can't do i18n over the protocol? #13961 shows how duplicating strings looks.

[adamraine]

static analysis is difficult and by far the most effective/easiest way to test bfcache is to do an actual navigation. I believe that's how the DT panel does it (see the message at the top):

If we need to test an actual navigation, then we could just attach this to navigation mode and only make it applicable in a user flow step that triggers a navigation via back/forward buttons. We could also cancel #13904 and add another "pass" that exercises the bfcache stuff.

[addyosmani]

Unsure if it was linked earlier, but you may also be interested in the BFCache Not Restored Reasons list maintained by Yuzu and the BFCache team.

[connorjclark]

we'll do the about:blank (or chrome://terms ??) -> back in a gatherer that runs last, but also will exclude this in user flows (for now).

in the future, perhaps user flows will have a flag, or the gatherer will at least run (by default) but w/o the navigation so that it can collect whatever back navigations the user scripts.

[connorjclark]

docs tracked in #14586