Why does requestIdleCallback give me more than 16 ms of time

Question

I thought that our code gets about 16ms of time to execute, since the rendering rate is 60 fps, so 1000 /60 = ~16ms. However, if I run this in Chrome:

requestIdleCallback((deadline)=>{
    console.log(deadline.timeRemaining(), deadline.didTimeout)
});

timeRemaining gives me 49.9ms of time. Does it mean that Chrome doesn't re-render every 16ms? I assume that it's true in this case, if nothing changes there's no need to re-render.

Answer 1

The spec supports your assumption. In Start an idle period algorithm it says:

7. Let deadline be a time in the future until which the browser expects to remain idle. The user agent should choose deadline to ensure that no time-critical tasks will be delayed even if a callback runs for the whole time period from now to deadline. As such, it should be set to the minimum of: the closest timeout in the list of active timers as set via setTimeout and setInterval; the scheduled runtime for pending animation callbacks posted via requestAnimationFrame; pending internal timeouts such as deadlines to start rendering the next frame, process audio or any other internal task the user agent deems important.

(my emphasis)

So if there were an internal pending timeout to render the next frame, the deadline would have to be before then.