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