All rAF callbacks always run in the same or next frame of work

Any rAFs queued in your event handlers will be executed in the ​same frame​.
Any rAFs queued in a rAF will be executed in the next frame​. (Same for any queued within IntersectionObserver or ResizeObserver callbacks.)

All rAFs that are queued will be executed in the intended frame.

Every rAF you request will run

rAFs aren’t throttled for you if they take too long to execute.

Let’s say there’s 5 callbacks queued up, and they’ll each take ~100 ms. The browser will not distribute them amongst many frames. It’ll try to run them all in the intended frame, even if it takes 500 ms. That means a pretty significant jank.

You may be asking, “why would there be FIVE animationFrame callbacks requested from within a single frame?” It can accidentally happen if you do 2 very reasonable things. 1) You request a new callback at the end of a rAF. 2) You request rAF callbacks from a input handlers. As a result, you’ve doubled/tripled your work each frame. Youch.

It’s up to you to coalesce rAFs on your own. So: if there’s a chance of multiple of the “same” callbacks firing within the same frame, then you must manage the scheduling/coalescing.

That said, Chrome (at least) will try to help some. If rAFs are hogging the main thread, the browser will start to throttle input events so that, hopefully, the contention will clear up.

And now this.. Two diagrams that help illustrate the lifecycle of events in a frame:

(Update Feb 2018. Jake Archibald recently gave a talk on the event loop which will almost definitely tickle your fancy:)

And for more implementation details, Sami’s Blink Scheduler talk from BlinkOn 3 is worth a watch, and you can poke around the Scheduler Overhaul resources in ds-hwang‘s Chromium-docs.

Addendum about the rAF timestamp

(added Feb 2018)

Many folks express confusion about the timestamp included as the first argument of the rAF callback. And for good reason.

The timestamp represents the beginning of the main thread frame that we’re currently in. This means that multiple different rAF callbacks can get back the exact same timestamp:

If that’s not very useful to you (you’re not alone), then feel free to grab performance.now() at the start of the callback and use that for your purposes.

1. Download and install the current version of node. (v6.3.0+ required)

2. Run node with the --inspect-brk flag:

# Break on the first statement of the script

▸ node --inspect-brk index.js

Next, you used to open the big chrome-devtools:// URL it spits out, but don’t. Now there’s a better way…

3. Open about:inspect in Chrome

It’ll redirect you to chrome://inspect quickly and you’ll see something like:

4. Click the Open dedicated DevTools for Node link.

You’ll get a popup window for debugging your node session.

But better than that, when you kill and restart node, the window will automatically reconnect to it. 🔁🔁💥

(Btw: the inspect link beneath the specific target will only apply for that session of node and won’t reconnect.)

In DevTools, now connected to Node, you’ll have all the Chrome DevTools features you’re used to:

• Complete breakpoint debugging, stepping w/ blackboxing
• Source maps for transpiled code
• LiveEdit: JavaScript hot-swap evaluation w/ V8
• Console evaluation with ES6 feature/object support and custom object formatting
• Sampling JavaScript profiler w/ flamechart
• Heap snapshot inspection, heap allocation timeline, allocation profiling
• Asynchronous stacks for native promises

To see this in action, here’s my demo during the 2017 Node Summit:

Lastly, there is now official documentation on debugging Node with the new protocol: https://nodejs.org/en/docs/inspector/