FID should only be considered passing (green) when it's state is final

[addyosmani]

Feedback from Phil:

I wouldn't show a green 0.00 for FID prior to the first input. I'd show a gray "--" or something like that since 0.00 is a valid value after an input, and seeing green is confusing.

The fix here will be only considering FID to be passing when it's state is final.

[addyosmani]

@philipwalton

I implemented this change locally and ran into some questions and potentially, challenges, it opens up:

• If the overall badge is gray until after first input for FID, most tabs will display a gray icon until there is interaction with the page. While this is technically correct ("of course you need to interact for a FID value..."), it loses some of the "instant" benefit the extension offers of knowing your metric values are trending in the right direction. Given we do instantly change the badge to red if FID is below the threshold when you do interact...I wonder if that's sufficient?

• If we are displaying gray until after first input for FID, there's an argument the same should apply for CLS and LCP to wait until after their values are final. Similar to the above, this loses some of the benefit of the liveness benefit of the badge.

Thoughts?

[philipwalton]

• Given we do instantly change the badge to red if FID is below the threshold when you do interact...I wonder if that's sufficient?

That was my thought. It's more important to catch instances of poor performance than be validated for good performance (I think).

• If we are displaying gray until after first input for FID, there's an argument the same should apply for CLS and LCP to wait until after their values are final.

Hmmm, fair point, though you'll actually never get a final CLS value (it's only final once the page is unloading), so you definitely wouldn't want to do it for CLS.

Doing it for LCP would be OK since (after input) LCP is always final. So there's never a case where FID is final but LCP is not.

Given that you'll have to have the possibility of a green square changing to red due to additional layout shifts, maybe it's not so bad that it changes to red after input as well. I'll let you decide what you think is best :)

[dalmaer]

I think showing the latest "this is what we think" is probably OK.

However, could always add a setting that I would probably turn on: "Solidify color when final"

Then we have a lighter green that snaps to a the more solid green when final?

[addyosmani]

Then we have a lighter green that snaps to a the more solid green when final?

Were you thinking a lighter green pre-final and darker when final? This wouldn't take long to implement. Happy to if we think it will be intuitive to folks.

[philipwalton]

Then we have a lighter green that snaps to a the more solid green when final?

One issue with that, though, is the we'll never have a final value for CLS until the page starts unloading. This idea could work for individual metrics, but it wouldn't work for the aggregate color score.

[patrickhulce]

I definitely agree that I'd be nice if labels for uncomputed metrics were gray. In all situations we know that the metrics can't get better with time so once it passes the bad threshold we can obviously color it red even if it's not final, but labelling as green before we've collected the data feels a little dangerous. I think a striped approach could work too, just something to distinguish it from the "this is definitely a good metric" case.

[tunetheweb]

Think this is an old issue as it currently shows gray/“waiting for input” for FID and INP but leaves the overall status as Green if the other CWVs pass.

I think given it’s always a state in time measure, that’s fair enough and so we can close this?