| Rate | Frame time | Where you meet it | vs 60 Hz |
|---|
What is timed is how often the browser presents a frame. On an idle page that equals the display's refresh rate, but a busy machine, a power-saving profile or a browser that caps itself will all read lower than the monitor is capable of.
Browsers round performance.now() to defend against timing attacks — often
100 µs, sometimes 1 ms. At 240 Hz a frame is 4.17 ms, so on a 1 ms clock every individual
reading is 4 or 5 ms and never 4.17. Only the aggregate over many frames recovers it,
which is why this page will not show you a live per-frame number.
Miss a vsync and the interval doubles. Averaging those in reports a rate the monitor never ran at — a 240 Hz panel with 3% drops averages out near 232 Hz. The estimate here uses the median and discards the outliers, then counts them separately.
On a G-Sync or FreeSync panel the rate follows whatever is being drawn, so there may be no fixed number to report. When the intervals are spread too widely to call, this says variable rather than inventing an average nobody's hardware is running at.
There is no browser API that reports a monitor's refresh rate. What there is, is requestAnimationFrame — a callback the browser runs once per presented frame. Time enough of those and the rate falls out. The care is all in the statistics: the clock is deliberately coarse, some frames get missed, and a variable-refresh display may not have a single rate at all. Taking a plain average of the gaps between callbacks gets all three wrong at once.
A 240 Hz panel dropping 3% of frames: the raw average interval works out at 4.31 ms, which reads as 232 Hz — a monitor nobody sells. Take the median instead, keep only the intervals within 25% of it, and divide the count by the elapsed time across them, and the answer comes back 240 Hz with the dropped frames reported separately, which is the useful pair of facts.
Usually the browser window is on a different display, the machine is on a power-saving profile, or the browser is capping itself — some do on battery. It can also happen if the page is not the active tab. Try again with the window on the fast display and the laptop plugged in.
Yes, provided the browser is genuinely presenting that fast. The estimator works from total elapsed time across hundreds of frames rather than individual gaps, so a coarse clock averages out. What it cannot do is exceed what the browser presents — if the browser caps at 60, no measurement will find the panel's 500.
The rate corresponding to the slowest 1% of frames. A high average with a poor 1% low is what stutter feels like: the mean says smooth, the occasional long frame is what you actually notice.
Longer samples make the estimate steadier and are much better at catching occasional hitches — a 2-second run can easily miss a stutter that happens every ten seconds. For simply identifying the rate, 2 seconds is plenty at any refresh rate above 60 Hz.
That requestAnimationFrame fires once per presented frame, which is true in current browsers but is a browser behaviour rather than a guarantee. It measures the presentation rate of this page, not the display's capability: a browser that caps its frame rate, a background or occluded tab, a power-saving profile or a busy GPU will all read lower than the panel can do, and the tool cannot distinguish those from a genuinely slower monitor. Timestamps are quantised by the browser for security, so results are aggregates over many frames rather than per-frame measurements. On a variable-refresh display there may be no single correct answer to report. No result here should be taken as a hardware specification.
No changes to this tool’s own behaviour since the earliest archived release (v2.8). The full history for the site is in the changelog.