requestAnimationFrame and Frame Scheduling

## What "one frame" means A browser does not repaint after every line of JavaScript. It produces *frames*: at a cadence set by the display, it stops accepting new work for that turn, recalculates style, lays out boxes, paints them, and hands the result to the compositor to be shown on screen. On a typical 60 Hz display that happens roughly every 16.7 ms; on a 120 Hz display roughly every 8.3 ms. Animating means changing something exactly once per frame, so what you want is a scheduling primitive that fires once per frame — no more, no less. ## What requestAnimationFrame actually does `requestAnimationFrame(callback)` adds `callback` to the document's list of animation frame callbacks and returns a positive integer handle. The next time the browser decides to produce a frame, it runs every callback on that list, passing each one the frame's start timestamp, and then continues into style recalculation, layout, paint and compositing for that same frame. The registration lasts for exactly one frame, so a continuous animation re-registers from inside its own callback: ```js function draw(timestamp) { // update state, write to the DOM requestAnimationFrame(draw); // book the next frame } requestAnimationFrame(draw); ``` Two properties follow from where the callback sits. First, it is invoked in step with the display rather than with a clock of your choosing. Second, it runs at the last moment where a DOM write still lands in the frame the user is about to see — the write is picked up by the style and layout passes that immediately follow. ## Why a 16 ms timer cannot line up `setInterval(draw, 16)` promises only "not sooner than 16 ms". The delay is measured from the timer's own bookkeeping, and it has no knowledge of the display's refresh signal. Sixteen and 16.7 are different numbers, so the two rhythms beat against each other: periodically the timer fires twice within one frame interval (the first draw is overwritten and never seen) and periodically it fires zero times (the same pixels are shown twice). The arithmetic in your animation is perfectly smooth and the motion still looks like it hitches. On top of that, timer callbacks are ordinary tasks queued behind everything else the page is doing. Under load they bunch up, so you may run several draws between two paints. Every draw but the last is wasted work, and the wasted work is what pushed the frame late in the first place. ## Refresh rate is not a constant Hardcoding 16 also bakes in an assumption about the hardware. High-refresh phones and monitors run at 90, 120 or 144 Hz, external displays and power-saving modes change the rate at runtime, and variable-refresh displays change it continuously. A rAF loop follows whatever the current rate is; a fixed interval either starves the display or over-produces. This is also why an animation should compute movement from elapsed time rather than adding a fixed number of pixels each callback — otherwise it literally runs twice as fast on a 120 Hz screen. ## Hidden pages When a tab is backgrounded or the page is otherwise not being rendered, the browser stops producing frames for it, and animation frame callbacks stop being invoked. A self-rescheduling rAF loop therefore parks itself with no extra code. Timers behave differently: browsers throttle them heavily in background tabs, but they do keep firing, so a `setInterval` animation goes on computing and mutating the DOM for a page nobody is looking at. ## What requestAnimationFrame does not promise It is not a promise of 60 fps, and it is not a budget enforcer. If the callback plus the style, layout and paint work that follows it cannot finish before the next display deadline, the frame is simply late and the user sees a lower rate. rAF also gives you no isolation: it runs on the main thread, in the same turn as everything else, so a long task elsewhere on the page delays it just as surely. ## When a timer is still the right tool Use a timer for anything that is not visual: polling, retry backoff, debouncing, session timeouts, a clock that ticks once a second. Those want wall-clock spacing, not display cadence, and they should keep working when the page is hidden. Reach for `requestAnimationFrame` only when the point of the callback is to change what is on screen for the next frame.