When Will RequestAnimationFrame Be Executed?

Browser reads and runs a JavaScript file, the synchronous tasks written in the file immediately become in-mid-execution task, setTimeout callbacks become macrotasks, and promise ca

Solution 1:

It's basically its own thing. When the browser is about to repaint the page, which it does typically 60 times/second if not blocked by a running task, it will call all queued requestAnimationFrame callbacks just before doing so, and then do the repaint.

The spec doesn't say whether that can happen between the completion of a task (macrotask) and the processing of its scheduled microtasks, or only between (macro)tasks. So presumably that can vary browser to browser.

The old spec (now obsolete and superceded) described it in (macro)task terms, suggesting it would be between (macro)tasks, but things may have moved on from there.

The spec now says when this happens in the Event Loop Processing Model section. The shortened version with a lot of detail removed is:

1. Do the oldest (macro) task
2. Do microtasks
3. If this is a good time to render:
   1. Do some prep work
   2. Run requestAnimationFrame callbacks
   3. Render

Let's do a test:

const messages = [];
setTimeout(() => {
  // Schedule a microtask
  Promise.resolve().then(() => {
    log("microtask");
  });
  
  // Schedule animation frame callback
  requestAnimationFrame(() => {
    log("requestAnimationFrame");
  });
  
  // Schedule a (macro)task
  setTimeout(() => {
    log("(macro)task");
  }, 0);
  
  // Schedule a callback to dump the messages
  setTimeout(() => {
    messages.forEach(msg => {
      console.log(msg);
    });
  }, 200);

  // Busy-wait for a 10th of a second; the browser will be eager to repaint when this task completes
  const stop = Date.now() + 100;
  while (Date.now() < stop) {
  }
  
}, 100);

function log(msg) {
  messages.push(Date.now() + ": " + msg);
}

Sure enough, the results vary by browser:

• Chrome: microtask, requestAnimationFrame, (macro)task
• Firefox: microtask, (macro)task, requestAnimationFrame

(I reliably get the same results in repeated tests on those browsers. I don't have Edge handy...)

Now Chrome (and so presumably Chromium, Brave, and the new Edge), Firefox, iOS Safari, and Legacy Edge all do the same thing, which matches the spec: microtask, requestAnimationFrame, (macro)task.

Here's a version with the busy-wait up front, instead of at the end, in case it changes something:

const messages = [];
setTimeout(() => {
  // Busy-wait for a 10th of a second; the browser will be eager to repaint when this task completes
  const stop = Date.now() + 100;
  while (Date.now() < stop) {
  }
  
  // Schedule a microtask
  Promise.resolve().then(() => {
    log("microtask");
  });
  
  // Schedule animation frame callback
  requestAnimationFrame(() => {
    log("requestAnimationFrame");
  });
  
  // Schedule a (macro)task
  setTimeout(() => {
    log("(macro)task");
  }, 0);
  
  // Schedule a callback to dump the messages
  setTimeout(() => {
    messages.forEach(msg => {
      console.log(msg);
    });
  }, 200);

}, 100);

function log(msg) {
  messages.push(Date.now() + ": " + msg);
}

I reliably get microtask, requestAnimationFrame, (macro)task on both Chrome and Firefox with that change. I get the same results now as with the earlier snippet.

---

**Q1: **

Even though the browser has no repaint work, the requestAnimationFrame's callback will be excuted at the refresh rate (default 60 per second).

Provided nothing is blocking.

**Q2: **

That sentence means exactly, and only, what it says: Your callback will be called (along with any requestAnimationFrame callbacks that are queued up) immediately prior to drawing a frame. It doesn't mean that a frame is necessarily drawn every 60th of a second — because the thread may be busy doing other things.

Those callbacks will not interrupt other tasks. Again: If other tasks have the main UI thread busy, it's busy, and the framerate suffers.