Will 144Hz actually make your reaction time faster?
“60Hz is 16.7ms, 144Hz is 6.9ms, so you gain 10ms.” That calculation circulates everywhere. The arithmetic is right. What is usually wrong is what the number means.
What 1000 ÷ refresh rate tells you
60Hz means the screen redraws 60 times a second. 1000 ÷ 60 ≈ 16.7. That is the interval between picture changes.
The key point: it is an interval, not a delay. How long you actually wait depends on when the new picture becomes ready.
- Ready just before a refresh → almost no wait (close to 0ms)
- Ready just after a refresh → the full wait until the next turn (16.7ms)
- If readiness times are spread evenly across the refresh cycle → the average is about half of it (roughly 8ms)
That third line carries an assumption: readiness has to land independently of the refresh cycle for the average to be half. Our test randomises the intervals between stimuli, which gets close to that, but it is not something we verified.
Granting the assumption, 60Hz → 144Hz cuts an average of about 8ms to under half that. A full 16.7ms does not vanish every round.
And this wait is different every time. A lower refresh rate does not just make your numbers slower — it makes them bounce around more. Same ability, wider spread.
What refresh rate does not touch
Between the screen turning green and your score appearing, refresh rate governs one segment. The rest stays where it was.
| Segment | Raising the refresh rate |
|---|---|
| Waiting for the next frame | Shrinks |
| Panel physically changing color | Separate panel spec |
| Eye → brain → finger | Unchanged (the largest share) |
| Mouse / keyboard processing | Unchanged |
| Browser receiving the input | Unchanged |
The human segment takes over 200ms; refresh rate buys back single-digit milliseconds. If the difference felt large, that is usually motion smoothness, not reaction time.
What FlowScore actually times
Our test uses the clock the browser reports. It decides “green now” on the browser’s signal that it is time to paint (requestAnimationFrame), then measures the gap to the moment your tap arrives.
Here is the honest part. We cannot time the instant the panel actually emits light. That needs a photosensor on the glass; a browser has no way to know it. So our numbers carry “command received → pixels actually bright” as an unknown share.
That share is not a fixed number. It differs by hardware (which is why changing hardware changes it wholesale), and even on one machine parts of it — frame waiting among them — differ round to round. Either way, we cannot see it.
This is why “compare only on the same equipment” is the rule.
So should you buy one?
This guide will not answer that. It will give you the basis to answer it yourself.
- If you spend your time tracking moving targets in competitive games, refresh rate pays off in how often the screen updates, not in reaction time. That gain is hard to convert into milliseconds.
- If your goal is a better test score, the calculation above suggests single-digit milliseconds on average, plus less of the spread that comes from frame waiting. How much it actually moves, you find out by switching and measuring.
- Either way, measure at least ten times on your current setup before you switch. Without that history there is nothing to compare against afterwards.
What the real latency of any specific product is, this guide cannot say. That requires photosensor measurements of that exact hardware.
In short
- 1000 ÷ Hz is an interval, not a delay. The real wait averages about half of it.
- Refresh rate shrinks one link in the chain. The human link is far larger.
- Low refresh rate makes results bounce more. That spread matters as much as the average.
- Browser timing excludes the moment the panel lights up — which is why you compare within one setup only.