Surface blocked scroll events in Performance Timeline?

[igrigorik]

(discussed at TPAC 2016; rough notes and summary courtesy of @rbyers)

n8schloss@ talked about how useful the timestamp-based technique has been for them, and there was discussion about this being too hard and browser specific. Eg. in Gecko, some wheel events are cancelable but still don't block scrolling.

So we agreed that someone should propose a concrete API that basically just encapsulates the example in http://rbyers.github.io/scroll-latency.html. Here's a sketch for one possible idea:

• 'ScriptBlockingScrollTiming' entry in the timeline
• generated for every individual input-driven scroll update
• some way to differentiate "scroll start" from "scroll update" - when it makes sense (this will take some work to figure out, maybe want a third state for unknown, eg. for non-transactional clicky wheel)
• start/duration captures just the time the event spent queued waiting for the main thread, and in executing event handlers. When all relevant listeners are passive, this will be 0.
• May choose to report this only when duration >50ms - similar to long tasks API (solves the problem of stats like mean or 95th percentile being influenced by the rate of non-blocking events).

Next step is probably for someone (me, @tdresser, someone else?) to create a GitHub repo with a little explainer along these lines and run it by the web-perf group. Any takers? I think it should be relatively straight forward, and give us a nice pattern to build on for other forms of input latency.

Additional discussion: https://bugs.chromium.org/p/chromium/issues/detail?id=543598

[tdresser]

I'll write up an explainer.

[tdresser]

I've written up a doc outlining one possible Web Perf API for monitoring scroll performance which easily extends to providing performance and attribution information for scrolling and non-scrolling input scenarios.

Let me know if you've got any ideas by commenting either here or in the doc.

[igrigorik]

Awesome, thanks Tim! @toddreifsteck @bzbarsky @rniwa fyi.. and ptal at the above doc.

[rniwa]

How does this relate to the long task performance record? Should long task record be generalized instead to indicate what it blocked?

[tdresser]

There are some cases where both APIs will report a task.

There are other cases where this API will report slow event processing but there was no long task. For example, if a series of short tasks blocks an input event for a long time.

This API is heavily inspired by the long tasks API, but does address different needs.

[igrigorik]

Tim, it may be worth adding a section in the doc to explain the overlap and differences between these APIs. Conversely, if we have this.. do we still need "blocked input event" flag on LT? /cc @spanicker

[yoavweiss]

@tdresser - Are there cases where IL will fire an event, but LT will not?

[tdresser]

I've elaborated on this in the doc here - content pasted below.

There are some cases where both APIs will report a task. There are other cases where this API will report slow event processing but there was no long task, for example, if a series of short tasks blocks an input event for a long time. This API aims to complement the long tasks API, addressing different needs, through a consistent interface.

As a concrete example, consider the case where the user performs a click, while the main thread is busy. There are several tasks to execute:

1. Finish executing the current main thread task.
2. Execute mouse down handler.
3. Execute mouse up handler.
4. Execute click handler.

Each of these are separate tasks, but if the total duration of 1-4 is greater than the threshold, then we’ll report the click event as being handled slowly. If a single task out of 1-4 is longer than the long tasks threshold, then it will also appear through the long tasks API.

[yoavweiss]

@tdresser - apologies. I now see that I asked the opposite question of what I intended. I meant to ask if there are cases where Long Task fires, but there's no Input Latency event.

I guess that one case for that would be a scroll event where scrolling is handled off main thread. Are there other such events?

[tdresser]

Long tasks can fire for a variety of reasons without input - perhaps there's an ad rotation, the page is asynchronously loading some content, or has waited until the page is idle before doing some expensive computation.

[bzbarsky]

@igrigorik I'm probably not the right person at Mozilla to look over this, at least short-term.

@smaug----, do you know who would be?

[tdresser]

I've written a new explainer up here, with a somewhat more limited scope than my previous attempt.

A polyfill for much of the API can be found here.

There's a section on why the long tasks API isn't sufficient here.

[smaug----]

So what is this issue about? Scrolling or some generic input latency? Adding something scrolling (is it just wheel handling or any scrolling?) specific feels wrong, but generic input latency tracking way more useful.

What information can't be captured from events? Do we rather need some generic event handling timing information (probably not using PerformanceEntry API).

[tdresser]

Although this issue is specific to scrolling, the explainer I linked deals with the latency of all events (including those not triggered via input).

Regarding "what information can't be captured from events", see this section of the doc. Much of this information can be captured from events, but the performance overhead is prohibitive, and there are a few important use cases that can't be met without a dedicated event performance API.

[igrigorik]

This is now being incubated in: https://github.com/WICG/event-timing/

Closing this thread, let's direct the discussion to the WICG repo above.