[go: nahoru, domu]
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

add viewport audit as perf diagnostic for FID #12884

Open
3 of 4 tasks
brendankenny opened this issue Aug 9, 2021 · 5 comments
Open
3 of 4 tasks

add viewport audit as perf diagnostic for FID #12884

brendankenny opened this issue Aug 9, 2021 · 5 comments
Assignees
@alexnj
Labels
breaking P1.5

Comments

@brendankenny
Copy link
Member
brendankenny commented Aug 9, 2021 •
edited by alexnj
Loading

Double tap to zoom has a significant impact on FID since the browser waits for 300ms after a touch to see if a second one is coming before responding. DTZ occurrences were reduced in 2013 when an explicit mobile meta viewport disabled the 300ms delay and then again in Chrome 91 (in May 2021) when DTZ was disabled with any mobile-equivalent meta viewport as well. This check is now roughly equivalent to our viewport audit.

However, there are still a decent number of sites out there that aren't setting a mobile viewport, have terrible FID as a result, and Lighthouse has no knowledge of this happening because input isn't simulated and the DTZ delay comes from the browser, not from main thread blocking.

From the July 2021 HTTP Archive run, roughly 2M out of 7M sites had both a LH perf score without error and CrUX URL-level CWV data. 10% of sites in that group failed viewport, and the large majority of them had excellent TBT but 250ms-300ms FID via CrUX (2.5-3x the 100ms "good" threshold).

These sites tend to be simpler and score well on LCP and CLS both in LH and CrUX, as well as on TBT. As a result, sites without a mobile viewport actually make up roughly half of the sites that score 90+ in Lighthouse but fail one of the three CWV (FID, in this case). It's possible a decent number of these sites are older and were never updated to work well on phones and the owners will never see the advice, but adding viewport as an diagnostic is also an easy way to remove this Lighthouse FID blindspot.

Possible actions (complete in #12972)

  • Add viewport to diagnostics
  • Possibly add DTZ/FID explanation to audit description
  • Add viewport to tbtRelevantAudits so it's filtered there

one question: is it weird to have a TBT-relevant audit when it's actually FID-relevant and TBT may be super green?

edit: in discussion we agreed to do roughly all 3 checkboxes.

  • we also discussed making this affect perf score. we see 3 possible ways that could happen:
  1. Add to perf score (10% as an example)
  2. adjust TBT to include viewport signal
  3. add metric that includes this, like max-potential-fid, etc.
@brendankenny
Copy link
Member Author
brendankenny commented Aug 10, 2021 •
edited
Loading

we also discussed making this affect perf score. we see 3 possible ways that could happen

I hadn't thought about adjusting the perf score before today's discussion but it's making more and more sense to me. For HTTP Archive sites this is the top reason Lighthouse is giving green performance but the site is failing FID (spectacularly), so it makes total sense for the site to score worse when we know that's the case.

Add to perf score (10% as an example)

this makes a certain amount of sense, but it also doesn't seem to be great to give everyone an auto +10 boost just for including a meta viewport tag

adjust TBT to include viewport signal

if we did something like tbtValue = Math.max(actualTbtValue, hasViewport ? 0 : 300) it would be super ugly and would require buy in from anyone who cares about the TBT definition (which may not be many these days)...but would avoid the free 10 points issue and makes a certain kind of sense, especially if we moved to some kind of windowed TBT.

add metric that includes this, like max-potential-fid, etc.

adding back mp-fid seems a lot harder to me, especially when thinking about score weighting against the other long task metrics to get coverage but not over represent things in the final score...but knowing @patrickhulce and @paulirish, y'all probably have a compelling new version of (or new reason for!) mp-fid you've been keeping in your back pocket for just such an occasion, so I look forward to any discussion :)

@patrickhulce
Copy link
Collaborator

it also doesn't seem to be great to give everyone an auto +10 boost just for including a meta viewport tag

Agreed.

adding back mp-fid

I like this option the most. I was sad to see it go to begin with. It is a simple, direct attempt to surface a FID-like number, and captures the severity of the experience in a way that TBT does not. If TTI goes away, Max Potential FID is definitely what I would want to fill-in in the interim. I think the biggest challenge here is naming in a way that doesn't suggest it is true FID or that FID can never be higher than this number.

if we did something like tbtValue = Math.max(actualTbtValue, hasViewport ? 0 : 300) it would be super ugly and would require buy in from anyone who cares about the TBT definition (which may not be many these days)...but would avoid the free 10 points issue and makes a certain kind of sense, especially if we moved to some kind of windowed TBT.

This is the hacky option I could get behind in the short term, but definitely not thrilled about.

@patrickhulce
Copy link
Collaborator

Btw, I was auto-assigned this for issue triage. Is anyone else interested in picking this up or shall I implement the viewport piece for now?

@brendankenny
Copy link
Member Author

adding back mp-fid

I like this option the most. I was sad to see it go to begin with. It is a simple, direct attempt to surface a FID-like number, and captures the severity of the experience in a way that TBT does not. If TTI goes away, Max Potential FID is definitely what I would want to fill-in in the interim. I think the biggest challenge here is naming in a way that doesn't suggest it is true FID or that FID can never be higher than this number.

I'm totally on board, we'll just have to stake out a good bit of time pre-v9 (or whenever it would happen) to do it right.

Btw, I was auto-assigned this for issue triage. Is anyone else interested in picking this up or shall I implement the viewport piece for now?

SGTM!

@patrickhulce patrickhulce mentioned this issue Aug 23, 2021
Merged
@patrickhulce patrickhulce removed their assignment Aug 24, 2021
@connorjclark connorjclark added 10.0 and removed 9.0 labels Nov 1, 2021
@alexnj alexnj assigned alexnj and unassigned brendankenny Aug 25, 2022
@alexnj
Copy link
Member
alexnj commented Aug 29, 2022

Summary from the discussion today: This would make sense to be a part of the prioritized audit/opportunities redesign/refactor.

@paulirish paulirish removed the 10.0 label Sep 12, 2022
@tunetheweb tunetheweb mentioned this issue Jul 13, 2023
Closed
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@alexnj alexnj

Labels
breaking P1.5
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@paulirish @brendankenny @alexnj @patrickhulce @connorjclark @devtools-bot