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.

Sign up for GitHub

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

Jump to bottom

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
Assignees
@adamraine
Labels
10.0 new_audit P2

Comments

@paulirish
Copy link
Member

paulirish commented May 4, 2022 •
edited by connorjclark

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 •
edited

@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.

@tunetheweb tunetheweb mentioned this issue May 9, 2022
Open
@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 connorjclark mentioned this issue Oct 18, 2022
Merged
@paulirish paulirish assigned adamraine and unassigned paulirish Oct 21, 2022
@brendankenny brendankenny mentioned this issue Oct 24, 2022
Open
@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
Merged
3 tasks
@connorjclark
Copy link
Collaborator

docs tracked in #14586

@naveedahmed1 naveedahmed1 mentioned this issue Apr 13, 2023
Open
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adamraine adamraine

Labels
10.0 new_audit P2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@paulirish @addyosmani @brendankenny @connorjclark @adamraine @devtools-bot