By Eric, BlinkBench Founder · Last reviewed: July 2026
A monitor does not show you things the moment they happen. It redraws itself on a fixed clock — sixty times a second on most screens — and nothing that happens between two redraws is visible until the next one arrives. That is not a defect, and it is not something a faster computer fixes. It is what a display is.
Which means the instant a reaction time test decides to turn the panel green is not the instant you could possibly have seen it turn green. There is a gap. The gap is small, it is unavoidable, and it is part of every reaction time you have ever measured in a browser. Here is how big it is.
The arithmetic
A screen running at H hertz redraws every 1000/H milliseconds. At 60 Hz that is one frame every 16.7 ms.
A stimulus becomes ready at some arbitrary moment inside that window — the code has no way to aim for a frame boundary, and no reason to. If the moment is uniformly distributed across the frame, then the wait before the pixel actually changes is uniformly distributed too: anywhere from zero (you got lucky, the frame was about to draw) to one full frame period (you got unlucky, you just missed it). The average is half a frame.
That is the whole derivation. There is no measurement in it, no calibration, and nothing specific to this site — it follows from the refresh rate alone, which is why it is the one part of the apparatus we are willing to put a number on.
| Refresh rate | Frame period | Average delay | Worst case |
|---|---|---|---|
| 60 Hz | 16.7 ms | 8.3 ms | 16.7 ms |
| 75 Hz | 13.3 ms | 6.7 ms | 13.3 ms |
| 120 Hz | 8.3 ms | 4.2 ms | 8.3 ms |
| 144 Hz | 6.9 ms | 3.5 ms | 6.9 ms |
| 240 Hz | 4.2 ms | 2.1 ms | 4.2 ms |
Computed from the refresh rate by lib/apparatus.js — the same code that writes the apparatus statement on every timing test here.
What that does to a score
A typical simple reaction time is somewhere around a quarter of a second, so on a 60 Hz screen the display is contributing roughly 8.3 ms to a ~250 ms result. Call it three percent. On its own that is not the difference between a good score and a bad one.
The comparison that matters is between screens. Moving from 60 Hz to 240 Hz cuts the average onset delay from 8.3 ms to 2.1 ms — about 6.3 ms off your reaction time, handed to you by the hardware, without you getting any faster. On the leaderboards these tests publish, 6.3 ms is a lot of places.
So when someone tells you they average 180 ms, the first honest question is not whether they are lying. It is what they are sitting in front of.
Why we don't just subtract it
The obvious move is to measure your refresh rate, take half a frame off your score, and print the corrected number. We deliberately don't, and the reason is that the display is the part of the problem we can see.
Between the pixel changing and your click being timestamped there is also: the physical response time of the panel, your eye and your nervous system, the switch in your mouse, the polling interval of the USB or Bluetooth link, the operating system's event queue, and the browser's own event timing. Every one of those adds delay. Not one of them is measurable from inside a web page.
A “corrected” number that removes only the measurable piece is more misleading than the raw one, because it looks precise. It quietly claims the rest of the chain is zero. So the reaction time test here reports what it actually timed, states what your display could have contributed, and says plainly that the true equipment share is larger than that figure and cannot be pinned down.
For a sense of how much larger: when Woods and colleagues measured simple reaction time properly in 2015, they instrumented their own rig with external hardware and found 17.8 ms of equipment delay — 11.0 ms of monitor and 6.8 ms of mouse. Their mean of 231 ms became 213 ms once that was removed. They could do that because they had a photodiode and a signal generator. We have JavaScript.
Finding your own refresh rate
No browser API reports it, so the only way to find out is to time consecutive animation frames and take the median — which is what every test on this site does before it starts, and why the apparatus statement on your screen shows a figure specific to your screen rather than a stock 60 Hz.
If the measurement comes back implausible — a backgrounded tab, a machine under load — the tests report that they couldn't measure it rather than assuming 60. An assumed number is exactly the kind of thing this site exists not to print.