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. 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.
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 https://docs.google.com/document/d/1_jKAyTvMN2xEDmqttozWDIWGfhSwecaDrkHZ0dWkOns/edit#heading=h.fbdd8nwxr7v4. 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.
Oct 15 2015,
Oct 15 2015,
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 http://rbyers.github.io/scroll-latency.html
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.
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?
Jun 14 2016,
Downgrading to P2.
Sep 23 2016,
We talked about this in the webperf meeting at TPAC today. n8s@ talked about how useful the timestamp-based technique (see http://rbyers.github.io/scroll-latency.html) 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.
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.
Sep 26 2016,
Sep 27 2016,
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).
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.
Oct 3 2016,
May 17 2017,
May 17 2017,
> Eg. in Gecko, some wheel events are cancelable but still don't block scrolling. I filed this here https://bugzilla.mozilla.org/show_bug.cgi?id=1356293 . It doesn't appear to be implemented at all.
Aug 25 2017,
(100 day update) This is now covered by the event timing proposal, Tim - could you update the bug?
Aug 28 2017,
Aug 28 2017,
Sep 12 2017,
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: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit For any questions, please contact owencm, sshruthi, larforge
Jan 4 2018,
This is still on the backlog.
Apr 23 2018,
Update: I am actively implementing it - crbug/823744 is tracking the implementation.
This is under origin trial.
@npm, you are actively working on it, right?
Blocking on impl bug.
Sign in to add a comment