Proposal: add more main thread activity information to PerformanceEventTiming entry

[nhelfman]

Event timing performance entry provide timestamps which are useful to determine the following information:

1. Input delay - time until event handler start executing on main thread
2. Processing time - time it take to process event handlers bound to the event
3. Full duration - time from input event to next presented frame

The challenge for app developers is to determine additional missing main thread blocking activities which may occur as part of the input handling to next frame.

For example:

1. Regular Asyncs task (resulting from setTimeout, setInterval)
2. rAF callbacks
3. Micro tasks queue tasks callback execution
4. JS GC period
5. Rendering activity, such as: style, layout, composite, paint

Proposal: add additional information about other activities so that it will help app developers in analysing, troubleshooting and investigating performance issues.

[yoavweiss]

(4) and (5) were discussed at TPAC as part of JS Profiling. Would what's proposed there be enough to tackle your use case?

/cc @acomminos

RE (1), (2) and (3), can you expand on what parts are not covered by the current JS profiling API?

[nhelfman]

JS self profiling exposes or planned to expose this type of information as discussed. However there are multiple challenges regarding integrating between the event timing entries and js-profiler entries. Providing some stats for each event timing entry will enable performance engineers to simplify the analysis of slow user interactions.

There are some limitation with the js-profiler. Typically it does not run for the whole user session duration to minimize impact on users. It doesn't allow granularity of tasks shorter that 16ms (based on current security requirements).

Here is an example of addition info I was thinking could be helpful:

{
  rAF { count: 3, duration: 15 },
  timeout: { count: 6, duration: 30 }
  gc: { count: 2, duration 22 }
}

[noamr]

This feels a lot like w3c/longtasks#89, or at least very much related

[mmocny]

I agree with Noam that this feels like something that LoAF helps a lot with.

Event Timing adds a little bit of metadata specific to an event, and then overlaps with everything that happens within a frame (which may be long, or not). That frame will affect events, but also paints, etc.

[noamr]

I think LoAF covers this for now? Maybe this issue can be closed?

[yoavweiss]

nhelfman@ - what say you?

[nhelfman]

Seems reasonable.

It is not a complete solution since the Event Timing entry start time is the interaction time and the LoAF entry is the frame time so some heuristic would have to be done in order to match them.

Since both LoAF and Event Timing share the same user timeline I'm guessing it is may be possible to correlate between slow events and LoAF information (haven't tried).

[mmocny]

Final comment before closing:

• As discussed last week in Web Perf WG, I'd like to expose a few more timing to Event Timing
• One reason is this "alternativeToRenderTime" when you have cases like visibility-change, js Dialog, or just no-need-for-rendering
• But in order to redefine duration in terms of alternative, I'd like to expose renderTime explicitly, just as we do for Element timing
• Because of the value of LoAF, I'll use this opportunity to expose the "current Animation Frame end time" in the same way that LoAF defines it: Task end time when there is no rendering needed, main-thread Paint time when it is needed

Net/net, Event Timing and LoAF entries should have a timestamp that is directly comparable and it will make it easier to just groupBy(key) or something.