What Your Browser Cannot Measure
A number is only useful if you know what it leaves out. This page lists every meaningful thing a browser-based test cannot measure, and how large each omission is.
We document our method on the methodology page. This is the companion: the error bars.
The six real limitations
Display latency
The gap between your code committing the stimulus and photons reaching your eyes.
Why it is out of reach: Unobservable. Page code runs before the panel refreshes, and there is no API that reports when pixels change.
0–17 ms on a 60 Hz panel; more at lower refresh rates
Input latency
The gap between a physical press and the browser receiving the event.
Why it is out of reach: Measurable, but only on average. It drifts within a session and the probe takes a median of a small sample.
10–100 ms on Bluetooth; near zero on wired
Browser scheduling
Frame scheduling, garbage collection, and time stolen by other tabs.
Why it is out of reach: Variable rather than constant, so no fixed correction would be right more than roughly half the time.
0 to tens of ms, unpredictable
Neural conduction separately
The time for a nerve impulse to travel and cross a synapse, as distinct from your whole response.
Why it is out of reach: Requires electrode or imaging equipment. A browser sees only your total elapsed time.
Not separable at all here
Attention and fatigue over time
Whether a given attempt reflected a stable internal state.
Why it is out of reach: Only visible as variance across attempts, never as a direct reading.
Unknown; not measured
Population position
How you compare to other users.
Why it is out of reach: Scores are never collected, so there is no dataset. Percentiles come from an assumed distribution.
Not measured — modelled instead
The one that dominates
Of those, only one is both large and trivially fixed: input latency on a wireless peripheral. A Bluetooth keyboard can add 20–100 ms of variable delay, and it varies frame to frame, which is worse than a constant offset because it adds noise as well as bias.
The practical hierarchy, then, for anyone whose score seems unexpectedly slow:
- Switch to a wired or built-in peripheral. Usually the single biggest available gain.
- Run the latency probe so any residual offset is at least measured.
- Close heavy tabs and pause downloads.
- Test when rested — fatigue is a real effect, not an excuse.
- Only then consider whether the number is genuinely yours.
What this does not undermine
Two of the strongest arguments for browser-based measurement survive all of the above:
- Noise that is stable across sessions cancels in a comparison. If your setup is unchanged, a constant apparatus offset shifts every reading by the same amount. Detecting a 5 ms change does not require a perfect instrument — it requires anunchanged one.
- Repeatability beats precision for personal tracking. A laboratory visit is more precise per session and vastly less available. For answering "did this change anything?", ten home sessions on one setup is stronger evidence than one session on good equipment.
So the honest summary is narrow and worth stating plainly: a browser reaction time is a sound instrument for measuring change in yourself, and an unsound basis for comparing yourself to a published figure for somebody else. Every comparison this site makes is with your own history.
Corrections and limits are published
When we have got something wrong, we fix the page and note it on thesources page rather than quietly editing. Several corrections are already listed there — including a claim about practice effects that the published data does not support, and a motorsport rule that has since changed.
If you find something we have missed,tell us.
See the full method
The methodology page documents every constant the code uses — the clock, the delay distribution, the response window, the scoring functions and the storage rules.
Sizes quoted for input latency and display latency are typical ranges for consumer hardware, not measurements from your device — this site cannot measure your display. Everything specific to this site\'s implementation is documented on themethodology page.