Why Your Browser Score Is Slower Than a Laboratory One
The same task, measured two ways, produced a 65 ms difference in published research. That gap is larger than most of the differences people visit reaction time sites to investigate, and almost nobody mentions it.
There is a persistent habit in this genre: a site publishes a "typical" figure, usually a median scraped from another site or asserted without a source, and readers are invited to compare their own score against it. We have removed that habit from this site. Instead this article explains where the gap comes from, with the arithmetic you can check yourself.
The measurement that started this
The clearest evidence comes from a study that ran the same population through two apparatuses. In 94 college football players, mean reaction time was:
| Apparatus | Mean | Variability (SD) |
|---|---|---|
| Falling meter stick | 203 ms | ±20 ms |
| Computerized battery | 268 ms | ±44 ms |
| Difference | 65 ms | 2.2× the spread |
Source: Eckner et al. (2010). The two conditions correlated at r = 0.445 — they were measuring the same underlying trait, just not the same number.
Note the second column. The computerised measure was not just slower; it was more variable, with more than twice the standard deviation. A measurement that wanders that much between identical trials is not a more precise instrument. It is a noisier one.
Where the extra 65 ms goes
A browser measurement has to survive several stages that laboratory apparatus either removes or controls. Each one costs time, and they do not all cost the same amount.
| Stage | Who owns it | Can a page fix it? |
|---|---|---|
| Input device transport (Bluetooth, wireless) | Your hardware | Partly — see latency compensation |
| Frame scheduling and compositing | Browser and GPU | No |
| Panel refresh — the time before the signal is physically visible | Your display | No — invisible to a web page |
| Background tab throttling, GC pauses, other tabs | Your system | By avoidance — close tabs |
| Button travel — the physical distance your finger must cover | You, and ergonomics | By positioning the button well |
The uncomfortable entry is the third one. Display latency is invisible to any measurement taken inside a page: by the time your code runs, it has no idea how many milliseconds remain before the pixels change. We can tell you your input delay. We cannot tell you your display delay, and we do not pretend otherwise.
The arithmetic, so you can check it
Take a plausible setup and see how the parts accumulate. Suppose a 60 Hz panel — the kind in many laptops — which refreshes every 16.7 ms. A signal committed just after a refresh must wait for the next one, so display latency alone contributes 0 to 16.7 ms, averaging about 8.3 ms.
Add a Bluetooth keyboard with a modest 30 ms of transport delay, and average browser scheduling overhead of roughly 5 ms. That is about 43 ms of apparatus overhead on top of the physiological time. Which is most of the way to the 65 ms the study reports — and it arrives without a single one of those milliseconds being a fact about your reflexes.
The practical consequence: a 250 ms browser score on a mediocre setup may well represent a physiological reaction closer to 210 ms. Both numbers are correct. They answer different questions, and only one of them is about your nervous system.
What this site measures, precisely
Our score is the elapsed time from the point the code commits the stimulus to the point the browser receives your response event, read fromperformance.now(). That is a real, defensible quantity — it excludes your device's transport delay (which the probe measures and optionally subtracts) and it includes display and scheduling overhead (which it cannot remove).
We deliberately do not reconstruct your score from physics. In a real ruler-drop test you catch a falling stick and the distance is converted to a time. Here, the on-screen ruler is animated by the same clock that records you, with a deliberately non-physical ease, so the centimetre figure isderived from your measured time rather than the other way round. Themethodology page has the full detail.
So what is a browser test actually good for?
More than the scepticism above suggests, for one specific purpose: tracking yourself. A laboratory test is more precise per session, but a browser test is available on demand, costs nothing, and can be repeated in identical conditions indefinitely — which is precisely what detecting a 5 ms change requires.
Noise that is constant across sessions cancels out when you compare two sessions on the same setup. Apparatus overhead that is stable is a fixed offset. Neither harms a before-and-after comparison. Both completely invalidate a comparison against somebody else's published number.
Get a baseline worth comparing
Wired mouse, high-refresh display, heavy tabs closed, first attempt discarded, five rounds averaged. Run that setup every time and the number means something.
Source: Eckner, Kutcher & Richardson (2010), Journal of Athletic Training 45(4), 327–332. Display-latency figures in this article are illustrative arithmetic from the 60 Hz refresh interval, not measurements taken from your device. Every number this site states has its own method noted on thesources page.