Frame Budget Calculator (60/90/120 fps)

Understanding the frame budget calculator — concept and principle

Smooth animation, scrolling and games require a new frame on every display refresh. The frame budget is the time available to produce each frame at a target frame rate. This calculator shows that budget, how much headroom your current per-frame work leaves, and the frame rate your work would allow. Front-end, game and graphics developers use it when profiling jank and dropped frames.

Budget = 1000 ÷ fps; 12 ms fits a 60 fps frame but overflows at 90 and 120 fps.

How it is calculated

Budget per frame (ms) = 1000 ÷ target fps.
Headroom (ms) = budget − your frame work. A negative value means the frame is over budget.
Achievable fps = the smaller of the target fps and 1000 ÷ your frame work, since you cannot render faster than the target refresh rate.

Frame work is the total time spent producing one frame, in milliseconds.

The principle

A second has 1000 milliseconds, so at 60 fps each frame gets 1000 ÷ 60 ≈ 16.67 ms; at 90 fps 11.11 ms; at 120 fps 8.33 ms; at 144 fps about 6.94 ms. If the work for a frame takes longer than that, the display shows the previous frame again and the motion stutters. In a browser, your JavaScript is not the only cost: style recalculation, layout, paint and compositing also need time, so a common rule is to leave roughly 4–6 ms of the 16.7 ms at 60 fps for the browser. Higher refresh rates shrink the budget, so code that is smooth at 60 Hz can drop frames on a 120 Hz screen.

Worked example

Inputs: target 60 fps, frame work 12 ms.
Budget: 1000 ÷ 60 = 16.67 ms (16.666…).
Headroom: 16.67 − 12 = 4.67 ms.
Possible rate from the work alone: 1000 ÷ 12 = 83.3 fps, which exceeds the target, so achievable fps = 60.

Each point is the calculator re-run with only “Target fps” changed; the gold point is the default example. Change the inputs above and this chart follows your numbers.

Target fps	Budget per frame (ms)
15	66.66666667
30	33.33333333
45	22.22222222
60	16.66666667
75	13.33333333
90	11.11111111
120	8.333333333

How to read the result

Positive headroom means your work fits, but in a browser only a few milliseconds of headroom may be needed for rendering, so 12 ms at 60 fps is acceptable while 15 ms is risky. Negative headroom means dropped frames; split long tasks, move work off the main thread, or animate only transform and opacity so the compositor can handle it. Profile on the slowest target device, not a fast development machine.

Common mistakes

Measuring the average frame time; occasional long frames cause visible stutter.
Ignoring browser rendering time and spending the full budget in scripts.
Reading 1000 ÷ work as the real frame rate with V-Sync on; frames are presented on refresh boundaries, so a 20 ms frame on a 60 Hz display typically shows at 30 fps rather than 50.

Keep in mind: The result is a simple timing budget. Real frame pacing also depends on GPU work, V-Sync, variable refresh, thermal throttling and garbage-collection pauses.

Frequently asked questions

Why is 16.7 ms the magic number?

Most displays refresh 60 times per second, and 1000 ÷ 60 ≈ 16.7 ms.

What budget do I have at 120 Hz?

About 8.33 ms per frame, half the 60 Hz budget.

How do I measure frame work in a browser?

Use the Performance panel in browser developer tools, which shows each frame and the long tasks inside it.

Sources: web.dev, "Measure performance with the RAIL model" (Google) · developer.chrome.com, "Rendering performance" guides

Checked 8 Nov 2026. Standard formulas and RFC/IEEE definitions, computed locally in your browser — nothing you type is sent anywhere.

Your numbers