-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Support traces missing FCP #1634
Conversation
FYI. needs a rebase if you're not already aware. |
Thx. Rebased! |
"Use last fMPCandidate if no FMP is marked." This is a bit scary. If we take a 30 second trace, and FMP is 28 seconds, and we regress it by 3 seconds, we'll see FMP decrease, correct? |
Yes. :) I don't know how avoidable this is, since FMP is willing to consider new paints as FMP until an indeterminate time. On the other hand, this means we will report the 28s FMP as our FMP even if the detector is waiting around for other paints that end up with lower significance. (I'd wager this is far more likely, out here at 30 seconds in) In both cases, these are terrible numbers, so that's the key thing to communicate to the user. So IMO if we score a 28s FMP as 0.4/10 and a 31s FMP as 0.3/10, then it seems generally okay. (I just checked and right now any FMP after 13 seconds gets a score of <1 out of 100.) |
Yeah, that's probably reasonable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
really excited to banish that bug :) LGTM
Thanks airhorner for introducing this edgecase of a website without content. :)
Fixes #1567
I was able to remove the FMP tolerance bit we had before.
I've also verified that the pwmetrics-events bit works perfectly now with a trace missing fCP. :)