add `viewport` audit as perf diagnostic for FID

[brendankenny]

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)

• [x] Add viewport to diagnostics
• [x] Possibly add DTZ/FID explanation to audit description
• [x] 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]

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]

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]

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]

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!

[alexnj]

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