requestAnimationFrame FPS Meter & Easing Visualizer

Smooth animation on the web is a function of two independent things: how consistently the browser can paint new frames (frame rate), and how the value being animated changes over time (the easing curve). This snippet builds a real, working instrument for both — a genuine requestAnimationFrame-based FPS meter that measures actual frame-to-frame timing, paired with a bouncing ball whose motion is driven by selectable easing functions, so you can watch how easing shapes perceived motion while simultaneously monitoring whether the browser is actually hitting your target frame rate.

How requestAnimationFrame timing actually works

requestAnimationFrame(callback) schedules callback to run once, right before the browser's next repaint, and passes it a single argument: a high-resolution timestamp (in milliseconds, from the same clock as performance.now()) representing when that frame's paint cycle began. Critically, the browser does not guarantee a fixed interval between calls — it targets the display's refresh rate (typically 60Hz, but 90/120/144Hz on modern displays and variable-refresh setups), and it will skip frames entirely if the main thread is busy. This demo's loop(now) function captures that timestamp, computes delta = now - lastTime — the actual milliseconds elapsed since the previous frame — and that delta, not any fixed assumption, is the raw signal every FPS meter must be built from.

From frame delta to a stable FPS number

A single frame's instantaneous FPS (1000 / delta) is far too noisy to display directly — one slightly delayed frame would make the number jump wildly. This demo keeps a rolling window of the last 30 frame deltas in the frameSamples array, averages them, and only then converts to FPS: 1000 / avgDelta. This rolling-average technique is the same smoothing approach used by real browser DevTools performance panels and game engine debug overlays, and it's what makes the displayed number in this demo (and the <canvas>-drawn history graph beneath it) readable rather than flickering unusably between frames.

Using artificial load to see FPS actually drop

To make the meter's purpose concrete, this demo includes a "main-thread load" slider that runs a deliberately wasteful synchronous loop (burnCpu(), summing square roots for N iterations) inside the animation loop itself. Because requestAnimationFrame callbacks run on the main thread and block the next paint until they return, adding CPU work here directly delays subsequent frames — dragging the slider up is the fastest way to watch the FPS number and graph genuinely degrade from 60 toward 30 or lower in real time, demonstrating exactly why long synchronous JavaScript tasks are the primary cause of janky animation in real applications.

Easing functions: shaping progress, not position

An easing function is a pure mathematical mapping from linear time progress t (0 to 1) to eased progress (also typically 0 to 1, though bounce/back easings can briefly exceed that range). This demo implements four: linear (t => t, constant velocity — the "obviously not human-designed" baseline), easeInOutQuad (a quadratic curve that starts and ends slow, speeds up through the middle — the standard curve for most UI micro-interactions), easeOutBounce (a piecewise function simulating physical bounce decay, useful for playful confirmation animations), and a JS approximation of a cubic-bezier(.17,.67,.35,1.3) curve — the same control-point model CSS's cubic-bezier() timing function uses, here approximated by directly weighting the bezier control points against t rather than solving the parametric x(t) inversion a true bezier requires, which keeps the math approachable while still visibly demonstrating an overshoot curve.

Why frame timing and easing choice are linked in practice

An aggressive bounce or overshoot easing amplifies the visual cost of dropped frames — a linear animation missing a frame is barely perceptible, but a bounce animation missing frames near its peak velocity reads as an obvious stutter. This is precisely why this demo puts the FPS meter and the easing selector in the same view: understanding animation performance requires seeing both signals together, exactly as a developer profiling real jank in a production animation would.