requestAnimationFrame and Idle Callback

The Animation That Jitters

A developer builds a progress bar animation using setInterval:

let width = 0;
setInterval(() => {
  width += 1;
  bar.style.width = width + '%';
}, 16); // 16ms ≈ 60fps, right?

It looks fine on their fast MacBook. On a mid-range Android phone, the animation jitters. Sometimes it skips frames. Sometimes it runs too fast when the tab regains focus. The problem: setInterval has nothing to do with the browser's rendering pipeline.

requestAnimationFrame exists specifically to solve this. But most developers use it without understanding where it sits in the event loop — and that misunderstanding leads to subtle, hard-to-debug rendering bugs.

The Mental Model

Where rAF Lives in the Event Loop

Recall the event loop algorithm:

while (true) {
  task = pickNextTask();       // 1. Macrotask
  execute(task);
  drainMicrotasks();           // 2. Microtask checkpoint

  if (shouldRender()) {        // 3. Render step (≈ every 16.6ms)
    runRAFCallbacks();         // 3a. requestAnimationFrame
    style();                   // 3b. Recalculate styles
    layout();                  // 3c. Layout
    paint();                   // 3d. Paint
    composite();               // 3e. Composite
  }

  if (idle()) {
    runIdleCallbacks();        // 4. requestIdleCallback (if time permits)
  }
}

requestAnimationFrame callbacks run inside the render step, before style/layout/paint. This is a fundamentally different timing guarantee than setTimeout:

rAF Timing Guarantees

One batch per frame

When the render step runs, the browser processes ALL currently queued rAF callbacks. But callbacks registered during a rAF callback run in the next frame:

requestAnimationFrame(() => {
  console.log('Frame 1 - callback A');
  requestAnimationFrame(() => {
    console.log('Frame 2 - callback B');
  });
});

requestAnimationFrame(() => {
  console.log('Frame 1 - callback C');
});

Output across two frames:

• Frame 1: Frame 1 - callback A, Frame 1 - callback C
• Frame 2: Frame 2 - callback B

The browser takes a snapshot of the rAF queue at the start of each render step. New callbacks added during processing are deferred to the next frame. This prevents the same infinite-loop problem that microtasks have.

The double-rAF trick

Because rAF callbacks within rAF are deferred, nesting two rAFs guarantees at least one paint between them:

element.classList.add('starting-position');

requestAnimationFrame(() => {
  // First frame: starting-position is painted
  requestAnimationFrame(() => {
    // Second frame: now transition to the end
    element.classList.add('ending-position');
  });
});

This is essential for CSS transitions. The browser needs to paint the starting state before it can transition to the ending state. The double-rAF ensures that paint happens.

requestAnimationFrame for Smooth Animation

Now here's how you actually use rAF properly. The correct pattern uses a timestamp to calculate position, not fixed increments:

// Wrong: increment-based (speed varies with frame rate)
function animateBad() {
  position += 2; // 2px per frame... but frames aren't consistent
  element.style.transform = `translateX(${position}px)`;
  requestAnimationFrame(animateBad);
}

// Right: time-based (consistent speed regardless of frame rate)
let startTime = null;
const duration = 1000; // 1 second
const distance = 300;  // 300px

function animateGood(timestamp) {
  if (!startTime) startTime = timestamp;
  const elapsed = timestamp - startTime;
  const progress = Math.min(elapsed / duration, 1);

  // Apply easing
  const eased = easeOutCubic(progress);
  element.style.transform = `translateX(${eased * distance}px)`;

  if (progress < 1) {
    requestAnimationFrame(animateGood);
  }
}

function easeOutCubic(t) {
  return 1 - Math.pow(1 - t, 3);
}

requestAnimationFrame(animateGood);

The timestamp parameter is a DOMHighResTimeStamp — the same clock used by performance.now(). It's consistent and accurate to sub-millisecond precision.

requestIdleCallback: Non-Critical Work

And then there's the chill cousin of rAF. requestIdleCallback runs when the browser has idle time — after all tasks, microtasks, and rendering are done, and before the next frame is due.

requestIdleCallback((deadline) => {
  // deadline.timeRemaining() tells you how much idle time is left
  while (deadline.timeRemaining() > 0 && workQueue.length > 0) {
    processItem(workQueue.shift());
  }

  // If there's more work, schedule another idle callback
  if (workQueue.length > 0) {
    requestIdleCallback(processMore);
  }
});

The deadline object has:

• timeRemaining() — milliseconds of idle time left (usually 0-50ms)
• didTimeout — whether the callback was called because its timeout expired

When to Use requestIdleCallback

• Analytics tracking and telemetry
• Pre-fetching resources for future navigation
• Indexing/processing data that isn't immediately needed
• Non-critical DOM updates (e.g., lazy-loading below-the-fold images)
• Cache warming

When NOT to Use It

• Anything the user is waiting for
• DOM changes that affect the current viewport
• Time-sensitive operations (it may run 50ms+ after you schedule it)
• Animations (use rAF)

// Good: send analytics during idle time
requestIdleCallback(() => {
  sendAnalyticsEvent('page_view', { path: location.pathname });
});

// Bad: update visible UI during idle time
requestIdleCallback(() => {
  element.textContent = 'Updated!'; // user might see a delayed pop-in
});

Production Scenario: Virtualized List Prefetching

Here's a real-world use case that shows rIC at its best. A dashboard shows a table with 10,000 rows but only renders ~50 visible rows (virtualization). You want to pre-render rows that are just outside the viewport for smooth scrolling:

function prefetchNearbyRows(visibleRange) {
  const { start, end } = visibleRange;
  const prefetchRange = {
    start: Math.max(0, start - 20),
    end: Math.min(totalRows, end + 20),
  };

  // Schedule prefetching during idle time — don't block scrolling
  requestIdleCallback((deadline) => {
    let i = prefetchRange.start;
    while (i < prefetchRange.end && deadline.timeRemaining() > 2) {
      prerenderRow(i);
      i++;
    }
    if (i < prefetchRange.end) {
      // More rows to prefetch — schedule another idle callback
      requestIdleCallback((dl) => prefetchBatch(i, prefetchRange.end, dl));
    }
  }, { timeout: 200 }); // Guarantee it runs within 200ms
}

The timeout option ensures the callback fires even if the browser never has idle time (e.g., during continuous scrolling). When didTimeout is true, timeRemaining() returns 0, so your code should do minimal work.

How rAF, rIC, and the Event Loop Interact

The exact order of timeout vs rAF depends on whether the browser schedules a render step before or after processing the timer task. In most browsers, the timer runs first, then rAF fires at the next paint. The key guarantee: sync is always first, promise always before any task or render callback.

Common Mistakes

Challenge: rAF Ordering

Challenge: Animation Frame Timing

console.log('A');

requestAnimationFrame(() => {
  console.log('B');
});

Promise.resolve().then(() => console.log('C'));

requestAnimationFrame(() => {
  console.log('D');
});

setTimeout(() => console.log('E'), 0);

console.log('F');

Key Rules