Sooo…three years later and I’m finally getting around to posting something. I’ve always kept a strong pipeline of articles to read and conference talks to watch, but I eventually end up forgetting all the cool things I learn. I didn’t really take any notes or, if I did, they were always in my trusty moleskine which wasn’t really too searchable ): . Thus came the idea to use the blog as my notebook :D, so here we are…
DISCLAIMER: These notes are meant to be short and as jump off points for deeper refreshers when necessary
Actual notes :D
requestAnimationFrame allows you to schedule actions (e.g. animation) to occur with the next layout/paint cycle of the browser event loop
Animations scheduled using a timer (i.e.
setTimeout), should instead switch to using
requestAnimationFrameallows you to sync your animations with the refresh rate of the client’s monitor, thereby eliminating extra work that may be done or missed when using
setTimeoutwill be executed within the current frame. Put another way, you cannot be certain that your animation will execute before the next paint. This skip in animation work can cause jank for your users.
If the interval you set for
setTimeoutis less than the refresh rate of a user’s monitor, you may be doing more work than a user’s monitor can actually display to them
requestAnimationFrameis also battery friendly because it doesn’t run unless its browser window/tab is active.
A use case for
requestAnimationFrameare scroll/resize related animations, e.g. parallax effects.
rAFhelps avoid jank if you are doing expensive DOM mutations in your scroll event handlers