Convert between target frames-per-second and the millisecond budget per frame, slice that budget into main-thread / style / paint / GPU phases, and measure your real frame time with requestAnimationFrame.
Allocate phases of a typical browser/game frame as percentages of your target budget. Anything over 100% spills into the next frame and causes jank.
| Phase | % | ms |
|---|
Sample requestAnimationFrame intervals on this page for 2 seconds and report the actual frame cadence. Run this in the same browser/tab where you want to test.
| Refresh / FPS | ms / frame | µs / frame | frames / sec | frames / hour |
|---|---|---|---|---|
| 24 fps | 41.667 | 41,667 | 24 | 86,400 |
| 30 fps | 33.333 | 33,333 | 30 | 108,000 |
| 60 fps | 16.667 | 16,667 | 60 | 216,000 |
| 72 fps · VR | 13.889 | 13,889 | 72 | 259,200 |
| 90 fps · VR | 11.111 | 11,111 | 90 | 324,000 |
| 120 fps | 8.333 | 8,333 | 120 | 432,000 |
| 144 Hz | 6.944 | 6,944 | 144 | 518,400 |
| 165 Hz | 6.061 | 6,061 | 165 | 594,000 |
| 240 Hz | 4.167 | 4,167 | 240 | 864,000 |
Web devs usually target 60 fps (16.67 ms) to match most monitors; mobile games on high-refresh phones aim for 120 fps (8.33 ms). VR headsets demand 72–120 fps to avoid motion sickness. Anything over your monitor's Hz only matters for input latency and frame pacing — it won't visually display more frames.