A canvas animation driven by requestAnimationFrame lurches far forward the instant the user switches back to the tab after a minute away. Why does it do that, and how do you keep it smooth?

## Two clocks that disagree A delta-time animation keeps two things: a running position, and the timestamp of the previous frame. Each callback computes `delta = now - previous` and integrates. That is the correct pattern, and it is correct precisely because the timestamp tracks real elapsed time rather than counting callbacks. The trouble is that frames are not produced continuously. When a document is not being rendered — a background tab, a minimised window, in some cases an entirely offscreen frame — the browser has no reason to run a rendering update, so animation frame callbacks are not invoked at all. Note the difference from timers: browsers *throttle* timers in background tabs but keep firing them, whereas frame callbacks are simply not called. The loop is suspended. The clock, however, is not suspended. The frame timestamp is milliseconds from the document's time origin, on the same monotonic clock `performance.now()` reads, and it keeps advancing through the whole background period. So on resume: ``` previous = 4200 // last frame before the tab was hidden now = 64200 // first frame after it became visible delta = 60000 // one minute, applied in a single step ``` Anything of the form `position += speed * delta` now teleports. Physics integrations do worse than teleport: a single 60-second step through a collision routine will tunnel straight through geometry, and any integrator with acceleration can produce nonsense velocities it never recovers from. ## The fix, in two parts **Clamp the delta.** Decide the largest step your simulation is willing to take and enforce it: ```js const MAX_DELTA = 32; // about two frames at 60 Hz function tick(now) { const delta = previous === null ? 0 : Math.min(now - previous, MAX_DELTA); previous = now; advance(delta); requestAnimationFrame(tick); } ``` This is one line and it makes the animation robust against every source of a large gap, not just backgrounding. It changes the semantics honestly: while frames are not being produced, animated time does not advance. For a decorative animation that is exactly what you want. **Or reset the reference.** If the animation must reflect real elapsed time — a countdown, a progress indicator tied to a real deadline — do not integrate at all. Recompute the position from a start timestamp and the current one, so a gap resolves to the correct *position* rather than to a giant step. The jump is then correct rather than a bug. For simulations that need both stability and real-time fidelity, the standard compromise is a fixed-step accumulator: add the raw delta to an accumulator, run fixed steps of, say, 16 ms while the accumulator allows, and cap the number of steps per frame so a huge gap cannot turn into thousands of iterations that block the main thread. ## Why not to special-case the tab It is tempting to wire up a visibility listener and reset `previous` when the page comes back. That works for this one cause, but the same enormous delta arrives from a long blocking task on the main thread, a major garbage-collection pause, the machine returning from sleep, or a devtools breakpoint. Clamping is cause-agnostic and needs no event plumbing, which is why it is the right default. A visibility-driven reset is a reasonable *addition* when the animation also needs to re-sync state on resume, not a substitute. ## While you are there: the first frame The same class of bug hides at the start of the loop. If `previous` is initialised to zero or left undefined, the first delta is either the whole time since the page loaded or `NaN`, and the animation starts with the same lurch. Seed `previous` from the first callback's own timestamp, or skip integration on the first frame. ## What good looks like in review Any per-frame integration should have three properties: the first frame cannot produce a garbage delta, an arbitrarily long gap cannot produce an arbitrarily long step, and the loop's own resume path does not depend on knowing *why* frames stopped. Code that has all three is immune to backgrounding without ever mentioning it.