Prelude

…I got nothing.

Actual Notes :D

  • requestIdleCallback allows you to schedule actions during any remaining time at the end of a frame or when a user is inactive.

  • This is different from requestAnimationFrame in that rAF occurs before painting.

  • The sequence of events is as follows:

    1. execute JS from task queue
    2. rAF
    3. style calculations, layout, and paint (collectively called a frame commit)
    4. requestIdleCallback (or anywhere between the first 3 steps if the user is idle)

  • You cannot tell how much time the first 3 steps will take up, so there is no guarantee that there will be any remaining time to allocate to your requestIdleCallback’s. This means that only non-essential work should be executed using requestIdleCallback.

  • To ensure that this non-essential work gets done eventually, you can set a timeout when calling requestIdleCallback. When this timeout is reached, the browser WILL execute the callback passed to requestIdleCallback.

  • It is important to not apply any DOM changes when using requestIdleCallback because the callback may be executed at the end of frame, i.e. after the frame has been committed. This means that if there are any layout reads in the next frame (e.g. getBoundingClientRect), the layout needs to be recalculated via a forced synchronous layout. When you need to make a DOM update, schedule the update via a requestAnimationFrame callback. This also ensures that the time needed for the DOM changes doesn’t cross the browser deadline prescribed to the requestIdleCallback.

  • What is a forced synchronous layout? This is an extra layout operation that is caused when there are DOM changes from JavaScript and those changes are subsequently read. The extra layout operation is necessary because the DOM changes from JS invalidate the layout calculation from the previous frame.

Useful references