requestAnimationFrame Timing

Where rAF Fires in the Event Loop

Let's clear up the biggest misconception right away: requestAnimationFrame is not a timer. It is a rendering lifecycle hook — the browser calls your callback once per frame, at a very specific point in the frame pipeline:

┌─────────── Event Loop Iteration ───────────┐
│                                             │
│  1. Macrotask (setTimeout, I/O, events)     │
│  2. Microtask queue drains (Promises, etc.) │
│  3. Rendering pipeline begins:              │
│     a. requestAnimationFrame callbacks ←──── HERE
│     b. Style recalculation                  │
│     c. Layout                               │
│     d. Paint                                │
│     e. Composite                            │
│  4. requestIdleCallback (if time remains)   │
│                                             │
└─────────────────────────────────────────────┘

rAF fires after microtasks drain and before the browser calculates styles and layout. This is the ideal time for DOM mutations that should be reflected in the next visual frame — the browser processes your changes immediately after, in the same frame.

The DOMHighResTimeStamp

Every rAF callback receives a gift: a high-resolution timestamp marking when the current batch of rAF callbacks began, measured in milliseconds from the page's time origin:

function animate(timestamp) {
  // timestamp: DOMHighResTimeStamp (e.g., 1042.567)
  // Same value for ALL rAF callbacks in this frame

  const elapsed = timestamp - startTime;
  const progress = Math.min(elapsed / duration, 1);

  element.style.transform = `translateX(${progress * 300}px)`;

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

const startTime = performance.now();
requestAnimationFrame(animate);

rAF vs setTimeout for Animations

You might be wondering: "Can't I just use setTimeout(fn, 16) and get basically the same thing?" You can try. But here is why it falls apart.

setTimeout Problems

// ❌ setTimeout-based animation
function animate() {
  element.style.transform = `translateX(${x++}px)`;
  setTimeout(animate, 16); // ~60fps... in theory
}

Issues:

1. Not synchronized to display refresh: setTimeout fires relative to when it was set, not the display's vsync. Timing drift causes frames to be skipped or doubled.
2. Minimum 4ms clamp: Nested setTimeout has a minimum ~4ms delay (HTML spec), causing drift away from 16.67ms.
3. Background tab behavior: setTimeout fires at reduced rate (~1/second) in background tabs but still runs, wasting CPU.
4. No frame coordination: Multiple setTimeout-based animations drift out of sync with each other.

rAF Advantages

// ✅ rAF-based animation
function animate(timestamp) {
  element.style.transform = `translateX(${x++}px)`;
  requestAnimationFrame(animate);
}
requestAnimationFrame(animate);

1. Vsync-aligned: Fires exactly once per display refresh (60Hz, 120Hz, 144Hz — adapts automatically)
2. Automatic pausing: Does not fire when the tab is in the background (zero CPU waste)
3. Coordinated timing: All rAF callbacks in a frame execute together, before a single style/layout/paint pass
4. Precise timestamp: Microsecond-resolution DOMHighResTimeStamp for consistent animation math

The Double-rAF Trick

This one is a classic. Sometimes you need to run code after the browser has painted the current frame — not before paint (where rAF runs), but after. The double-rAF trick is the go-to workaround, scheduling code for the frame after the next paint:

// Runs before paint (normal rAF)
requestAnimationFrame(() => {
  // This runs in frame N, before paint

  requestAnimationFrame(() => {
    // This runs in frame N+1, before paint
    // But frame N has already painted — so this is "after frame N's paint"
    measurePostPaintState();
  });
});

When You Need Double-rAF

Measuring layout after a style change:

// Apply style change
element.classList.add('expanded');

// Need to measure the result AFTER the browser has painted
requestAnimationFrame(() => {
  // Frame N: browser will paint the 'expanded' state
  requestAnimationFrame(() => {
    // Frame N+1: 'expanded' has been painted
    const height = element.offsetHeight; // Reflects painted state
    triggerAnimation(height);
  });
});

Ensuring a transition starts from the correct state:

// Insert element and ensure it starts at opacity 0
container.appendChild(element);
element.style.opacity = '0';

// Wait for the browser to paint opacity: 0
requestAnimationFrame(() => {
  requestAnimationFrame(() => {
    // Now transition from 0 to 1
    element.style.transition = 'opacity 0.3s';
    element.style.opacity = '1';
  });
});

requestAnimationFrame(() => {
  // Schedule a macrotask — fires after this frame's paint
  setTimeout(() => {
    // This is guaranteed to run after paint
    measureAfterPaint();
  }, 0);
});

cancelAnimationFrame

const id = requestAnimationFrame(animate);

// Cancel before the callback fires
cancelAnimationFrame(id);

Always cancel pending rAF callbacks when:

• A component unmounts (memory leak prevention)
• An animation is interrupted by a new one
• The user navigates away from the animated view

// React cleanup pattern
useEffect(() => {
  let rafId: number;

  function animate(timestamp: number) {
    // ... animation logic
    rafId = requestAnimationFrame(animate);
  }

  rafId = requestAnimationFrame(animate);

  return () => cancelAnimationFrame(rafId);
}, []);

Frame Timing Variability

Here is something that catches people off guard: rAF does not guarantee a consistent 16.67ms interval. Frame timing varies due to:

• Main thread work: A 30ms JavaScript task pushes the rAF callback later
• GC pauses: Garbage collection can delay frame rendering
• GPU back-pressure: If the GPU cannot composite fast enough, frames are delayed
• Display refresh rate: 120Hz gives 8.33ms intervals; 30Hz throttled tabs give 33.33ms

Always use the timestamp for animation calculations, never assume a fixed interval:

// ❌ Assumes fixed frame rate
function animate() {
  x += 5; // 5px per frame — speed depends on frame rate
  element.style.transform = `translateX(${x}px)`;
  requestAnimationFrame(animate);
}

// ✅ Time-based — consistent speed regardless of frame rate
function animate(timestamp) {
  const delta = timestamp - lastTimestamp;
  lastTimestamp = timestamp;

  x += speed * delta; // px per millisecond — frame rate independent
  element.style.transform = `translateX(${x}px)`;
  requestAnimationFrame(animate);
}

rAF in React

React uses rAF internally for scheduling, but you rarely interact with it directly:

• React's scheduler uses MessageChannel (not rAF) for work scheduling, but hooks into rAF for synchronizing state updates with the browser's render cycle
• Concurrent features (startTransition, useDeferredValue) use scheduler priorities that yield to rAF-timed rendering
• useEffect runs after paint (like double-rAF timing), making it the correct place for post-render measurements

// Direct rAF usage in React — for custom animations
function useAnimationFrame(callback: (deltaTime: number) => void) {
  const rafRef = useRef<number>(0);
  const previousTimeRef = useRef<number>(0);

  useEffect(() => {
    function animate(time: number) {
      if (previousTimeRef.current) {
        const delta = time - previousTimeRef.current;
        callback(delta);
      }
      previousTimeRef.current = time;
      rafRef.current = requestAnimationFrame(animate);
    }

    rafRef.current = requestAnimationFrame(animate);
    return () => cancelAnimationFrame(rafRef.current);
  }, [callback]);
}