thorst
commented
9 years ago Sounds sweet.
Ill dig into these and see what I come out with. We are due for a new version.
Thanks for the tip.
Sent from !MyComputer;
On Jan 21, 2015, at 12:14 AM, Paul Irish notifications@github.com wrote:
First of all, everything is my fault. Sorry.
Second of all, I think we can improve the performance of this script. :)
We currently bind to all of these events to judge if a user is active:
events: "mousemove keydown wheel DOMMouseScroll mousewheel mousedown touchstart touchmove MSPointerDown MSPointerMove" This makes sense in a way because we really want to know if the user does anything, sure. But…
The key issue here is that in many cases the browser cannot update the UI until the event handler has finished. So the user's scroll, mousemove, or touch is completely held up while it waits for our script to finish before actually getting closer to showing the user the outcome from that interaction.
This is described really well in this video:
https://www.youtube.com/watch?v=YyQYhhy1dZI#t=945 watch from 15:45 until 25:00
At the end, you can see a shot of the "show scroll bottlenecks" feature in devtools where this script triggers a bunch:
touch
The touch events are unnecessary because a touch will end up triggering mousedown anyway. https://patrickhlauke.github.io/touch/tests/results/ has all the details
the original list:
mousemove keydown wheel DOMMouseScroll mousewheel mousedown touchstart touchmove MSPointerDown MSPointerMove If we remove superfluous events that we can catch with another binding:
mousemove keydown wheel DOMMouseScroll mousewheel mousedown touchstart touchmove MSPointerDown MSPointerMove scroll
Binding to mousewheel, mousescroll is not great, as Nat & Tom offer in that video above. Resig offered similar advice in 2011 (see best practices). A better approach is polling for changes in scrollTop.
page visibility API
it's got great support and is a very simple indicator of "idle", so we could turn off polling then.
So then we're left with..
mousemove keydown wheel DOMMouseScroll mousewheel mousedown touchstart touchmove MSPointerDown MSPointerMove (and a page-visibility-aware scrollTop polling loop)
I think that's a fine list: mousedown mousemove keydown. We won't regress how well we monitor idle/active and we'll speed up all interactions with the pages considerably.
@thorst how does that sound to you?
— Reply to this email directly or view it on GitHub.
paulirish
First of all, everything is my fault. Sorry.
Second of all, I think we can improve the performance of this script. :)
We currently bind to all of these events to judge if a user is active:
This makes sense in a way because we really want to know if the user does anything, sure. But…
The key issue here is that in many cases the browser cannot update the UI until the event handler has finished. So the user's scroll, mousemove, or touch is completely held up while it waits for our script to finish before actually getting closer to showing the user the outcome from that interaction.
This is described really well in this video:
https://www.youtube.com/watch?v=YyQYhhy1dZI#t=945 watch from 15:45 until 25:00
At the end, you can see a shot of the "show scroll bottlenecks" feature in devtools where this script triggers a bunch:
Chrome's touch maestro Rick Byers also gave a long explanation of why touch handlers wreck performance: https://plus.google.com/+RickByers/posts/cmzrtyBYPQc?e=-RedirectToSandbox
touch
The touch events are unnecessary because a touch will end up triggering
mousedownanyway. https://patrickhlauke.github.io/touch/tests/results/ has all the detailsthe original list:
If we remove superfluous events that we can catch with another binding:
touchstarttouchmoveMSPointerDownMSPointerMovescroll
Binding to mousewheel, mousescroll is not great, as Nat & Tom offer in that video above. Resig offered similar advice in 2011 (see best practices). A better approach is polling for changes in
scrollTop.page visibility API
it's got great support and is a very simple indicator of "idle", so we could turn off polling then.
So then we're left with..
mousemove keydown
wheelDOMMouseScrollmousewheelmousedowntouchstarttouchmoveMSPointerDownMSPointerMove(and a page-visibility-aware scrollTop polling loop)I think that's a fine list:
mousedown mousemove keydown. We won't regress how well we monitor idle/active and we'll speed up all interactions with the pages considerably.@thorst how does that sound to you?