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.

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

Add more LoAF diagnostics to the INP attribution object #559

Open
5 of 21 tasks
rviscomi opened this issue Oct 30, 2024 · 1 comment
Open
5 of 21 tasks

Add more LoAF diagnostics to the INP attribution object #559

rviscomi opened this issue Oct 30, 2024 · 1 comment

Comments

@rviscomi
Copy link
Member

Currently, web-vitals provides the raw LoAF entries in the INP attribution object, which consumers of the library need to parse themselves to extract useful diagnostic info about the interaction. To make the attribution object more readily consumable, web-vitals should pre-process a core set of useful LoAF-based diagnostics.

After experimenting with different INP diagnostics, this is the subset that I've found to be most useful, including some existing metrics:

  • Overview of how time during the interaction was spent
    • INP duration
    • INP phase durations
    • Interaction time
    • Total style and layout duration
    • Total forced style and layout duration
    • Script duration grouped by invoker type and INP phase
  • Details about the slowest script entry during the interaction
    • Corresponding INP phase
    • Total duration
    • Compile duration
    • Execution duration
    • Forced style and layout duration
    • Pause duration
    • Invoker type
    • Invoker name
    • Source URL
    • Source function
    • Source character position
  • Details about the interaction itself
    • Interaction target
    • Interaction type
  • Additional metadata
    • Number of LoAF entries
    • Number of LoAF script entries

Diagnostics in bold are the ones I think every site owner should be looking at, with the rest considered nice to have. All of the unchecked items represent the ones I'm proposing we add first-class support for in web-vitals. These could be added directly to the attribution object, or contained within some nested object like loafAttribution.

web-vitals should only report the durations that occur during the interaction. A script could already be running at the moment a user interacts, but the only relevant time for attribution purposes is the time since the interaction started. Similarly, any scripts that have already finished executing before the interaction should be completely ignored from all INP diagnostics, even if they happen to occur within the same LoAF entry as the interaction.

The attribution object might look something like this:

inp.attribution = {
  loafAttribution: {
    totalLoafEntries: 1,
    totalLoafScriptEntries: 2,
    totalStyleAndLayoutDuration: 30,
    totalForcedStyleAndLayoutDuration: 50,
    totalDurationsPerPhase: {
      inputDelay: {
        'classic-script': 100
      },
      processingDuration: {
        'event-listener': 200
      }
    },
    slowestScript: {
      phase: 'processingDuration',
      duration: 200,
      compileDuration: 10,
      executionDuration: 190,
      forcedStyleAndLayoutDuration: 50,
      pauseDuration: 0,
      invokerType: 'event-listener',
      invoker: 'BUTTON.onclick',
      sourceURL: 'https://example.com/script.js',
      sourceFunctionName: null,
      sourceCharPosition: -1,
      entry: [PerformanceScriptTiming object]
    }
  }
  ...
}
@tunetheweb
Copy link
Member

@rviscomi I've opened #574 with an implementation of this.

One thing is that I did not include most of the fields in the slowestScript section and instead point that to the given script object as most are simple look ups of that. I did add a separate slowestScriptPhase since that is not included.

I also added a totalScriptDuration as thought that was helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants