core(mpfid): add max LoAFs to debugdata #15684
Conversation
| {"args":{"data":{"blockingDuration":1139.261,"duration":1199.518,"numScripts":1,"renderDuration":14.777,"styleAndLayoutDuration":13.034}},"cat":"devtools.timeline","id2":{"local":"0x13b00174d98"},"name":"LongAnimationFrame","ph":"b","pid":31161,"scope":"devtools.timeline","tid":259,"ts":8703546175}, | ||
| {"args":{},"cat":"devtools.timeline","id2":{"local":"0x13b00174d98"},"name":"LongAnimationFrame","ph":"e","pid":31161,"scope":"devtools.timeline","tid":259,"ts":8704745693}, |
There was a problem hiding this comment.
These events are fake to avoid the big disruption of updating the sample trace, but the times are based on the actual MPFID long task, so the LoAF being added to the trace is plausible.
| @@ -61,6 +108,11 @@ class MaxPotentialFID extends Audit { | |||
| settings: context.settings, URL: artifacts.URL}; | |||
| const metricResult = await ComputedFid.request(metricComputationData, context); | |||
|
|
|||
| const processedTrace = await ProcessedTrace.request(trace, context); | |||
| const processedNavigation = await ProcessedNavigation.request(trace, context); | |||
| const details = MaxPotentialFID.getLongAnimationFrameDetails(processedTrace, | |||
There was a problem hiding this comment.
I'm fine with sticking this in debug data. What's the reasoning for putting it in MPFID as opposed to TBT though?
There was a problem hiding this comment.
What's the reasoning for putting it in MPFID as opposed to TBT though?
It made sense without thinking about it too much, but I don't think I can make a solid case for it. Happy to move it if it seems more logical there.
There was a problem hiding this comment.
Meh I think it's fine. TBT is just where my brain went since that's an official metric.
As a first step to evaluating where Long Animation Frames (LoAF) will be a better measure of main-thread blocking than long tasks, this PR adds the longest LoAFs (after FCP) by
durationandblockingDurationto the debug data of themax-potential-fidhidden audit.No visible changes. The primary purpose is to have the data in HTTP Archive for querying and comparing to other metrics like MPFID and TBT.
Tests are minimal because we have fairly minimal tests for MPFID in the first place (e.g. no smoke tests). Happy to add more if it seems necessary.