Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new audit: bfcache eligibility #13960

Closed
paulirish opened this issue May 4, 2022 · 6 comments
Closed

new audit: bfcache eligibility #13960

paulirish opened this issue May 4, 2022 · 6 comments

Comments

@paulirish
Copy link
Member

paulirish commented May 4, 2022

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:

image

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?

@brendankenny
Copy link
Member

brendankenny commented May 4, 2022

@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
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Member

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
Copy link
Collaborator

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.

@adamraine adamraine mentioned this issue Oct 24, 2022
3 tasks
@connorjclark
Copy link
Collaborator

docs tracked in #14586

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment