New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Task

Blocked on:
issue 823744

issue 521307

Sign in to add a comment

Issue 543598: Ship Event Timing API

Reported by, Oct 15 2015 Project Member

Issue description

We're converging on defining some sort of PerformanceTimeline API for developers to get visibility into scroll performance.  In particular, to be aware of any long delays in scrolling caused by blocking on event listeners.

EDIT: doc here

In particular, we want an API that will give developers visibility into the performance improvements possible by adopting passive event listeners (  issue 489802  ).

igrigorik@ and rbyers@ are working on the spec, miletus@ will work on an implementation.

See   issue 521307   for some discussion of the larger issue here.

Comment 1 by, Oct 15 2015

Blocking: chromium:521307

Comment 2 by, Oct 15 2015

Labels: Cr-Blink-PerformanceAPIs

Comment 3 by, Feb 18 2016

It's not really clear what we're going to do here - waiting on some sort of generic perf violation reporting strategy (bug?).  

In the meantime, you can more-or-less measure this by using event timestamps (issue 543598) - see

Comment 4 by, Apr 21 2016

igrigorik@: Do we consider this a P1 (for current milestone) or should we be lowering the priority for this as it likely won't happen for sometime.

Comment 5 by, Apr 22 2016

I don't think we have consensus on what this should look like. 

Rick has a couple of prototypes that leverage rAF polling, and I think they're reasonable v1's for us try on some sites.. and they do not require any browser API's. Once we have some experience with these, we can revisit surfacing something in the perf timeline.

Rick, does that sound reasonable?

Comment 6 by, Jun 14 2016

Labels: -Pri-1 Pri-2
Downgrading to P2.

Comment 7 by, Sep 23 2016

Owner: ----
Status: Available (was: Assigned)
We talked about this in the webperf meeting at TPAC today.  n8s@ talked about how useful the timestamp-based technique (see 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  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.

Comment 8 by, Sep 24 2016

Another (related) idea from TPAC webperf meeting: in Long Tasks API potentially indicate "blocked" input events if the long task actually blocked input. Scroll could be a special case of this.

Comment 9 by, Sep 26 2016


Comment 10 by, Sep 27 2016

Labels: DevRel-Facebook

Comment 11 by, Sep 27 2016

Dumb question -- would it make sense to actually log the latency of any event (scroll events included). Basically it seems like this would standardize the interaction logging chrome devtools is doing today (which logs the latency of both scroll events and other things like click).

Comment 12 by, Sep 28 2016

Re #8: I think the use cases are a little different.  Long tasks describes things that MAY cause user responsiveness issues (expected responsiveness).  This is talking about precisely describing what the user actually SAW in terms of one type of responsiveness.  They're correlated but I can see use cases for both.  No objection to also having LongTasks indicate events that were blocked by the task, but I think we should do this as well.

One concrete example: it's possible to have many short tasks that together block scrolling, none of which is a long task itself (should be rare in Chrome's scheduler implementation, but not impossible and certainly not guaranteed to be rare across all browsers).

Re #11: It's an interesting question - not stupid at all, but I think it's hard to think of this as "the latency of a scroll event".  "scroll" events indicate that a scroll has occurred, but say nothing of what triggered the scroll.  Eg. say a user drags their finger while JS is running, and after a few ms that JS task changes scrollTop.  A single scroll event will be produced that includes the results of both changes.  How would we define that event's "latency"?

We could certainly expand this to multiple types of input though (related to but not directly associated with input events).  Eg. 'InputBlockingLatency' with some inputtype that can be "scroll", "click" (both mouse, touchscreen tap and enter key), etc.  The trouble there is that the ideal values are so different, you shouldn't really be comparing them.  For scenarios like "click" you've got ~150ms or so to respond without the user feeling like it's slow.  For scroll you've got probably 16-32ms.

Another generic option is to do esprehn's proposal of having an input observer API (similar to IntersectionObserver) that lets you collect batches of input records (including something about their latency) asynchronously after the fact.

All together, from our experience monitoring input metrics in Chrome, I personally think scroll is special and important enough that it makes the most sense to have a scroll-specific API in addition to whatever other general mechanisms we introduce.  But there are lots of other ways this could be spun that I'd be OK with.

Comment 13 by, Oct 3 2016

Status: Assigned (was: Available)

Comment 14 by, May 17 2017


Comment 15 by, May 17 2017

> Eg. in Gecko, some wheel events are cancelable but still don't block scrolling.

I filed this here . It doesn't appear to be implemented at all.

Comment 16 by, Aug 25 2017

(100 day update)
This is now covered by the event timing proposal, Tim - could you update the bug?

Comment 17 by, Aug 28 2017

Description: Show this description

Comment 18 by, Aug 28 2017

Summary: Ship Event Timing API (was: Ship new PerformanceTimeline API for scroll blocking latency)

Comment 19 by, Sep 12 2017

Labels: migrated-launch-owp Type-Task
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here:

For any questions, please contact owencm, sshruthi, larforge

Comment 20 by, Jan 4 2018

This is still on the backlog.

Comment 21 by, Apr 23 2018

Blockedon: 823744
Update: I am actively implementing it - crbug/823744 is tracking the implementation.

Comment 22 by, Aug 2

This is under origin trial.

Comment 23 by, Nov 16

@npm, you are actively working on it, right?

Comment 24 by, Nov 30

Blocking on impl bug.

Comment 25 by, Jan 21


Sign in to add a comment