ReactScore
Methodology

How we measure

No hand-waving. Here is precisely how the timer works, what it can and cannot measure, and the size of the error you should keep in mind.

Updated 31 May 2026

The clock

We time every reaction with performance.now(), the browser's high-resolution monotonic clock. It is accurate to a fraction of a millisecond and, unlike the ordinary wall-clock, it cannot jump backwards if your system time changes mid-test. Human reaction times live in the hundreds of milliseconds, so the clock itself is never the limiting factor.

Catching the exact moment the stimulus appears

This is where most web tests get sloppy. When we turn the screen green, that change is not on your monitor instantly. It is painted at the end of the current animation frame and only becomes light you can see at the next screen refresh. So we do not start the clock when our code schedules the change. We start it on the animation frame the change is actually presented in, using requestAnimationFrame. It is the closest a browser can get to timing from photons rather than from JavaScript.

Reading your input

We listen for pointerdown and keydown (space or enter), not the click event, because click fires noticeably later. Where the browser provides it, we use the event's own hardware timestamp instead of reading the clock inside our handler, which shaves off another small, variable delay. On touch screens we set touch-action: manipulation so there is no 300 ms tap delay.

Scoring: five tries, median, no guesses

You take five attempts. We report the median, not the mean, because reaction times are right-skewed: one slow, distracted click would drag an average around, while the median shrugs it off. We also trim attempts more than two standard deviations from your own spread, and we reject anything under 100 ms outright. Nobody reacts that fast; a sub-100 ms result means you anticipated and guessed, not that you reacted.

The honest part: device lag

Your score is not pure biology, and we will not pretend it is. Three things outside your control add time to every web reaction test:

  • Display refresh. A 60 Hz monitor only updates every ~16.7 ms, so the green can sit finished for up to a frame before you see it. Faster (120/144 Hz) screens cut this down.
  • Input pipeline. The OS, browser and mouse each add a little; wireless and Bluetooth devices add more.
  • Background load. A busy CPU or a heavy browser tab can stretch frame timing.

Together this is usually 10–50 ms. We measure your display's refresh rate at the start of each test, estimate the overhead (about half a refresh interval plus a small input allowance), and show you a device-lag-corrected figure next to your raw one. We are explicit that this is an estimate. Truly measuring end-to-end latency needs a high-speed camera pointed at your screen; what we offer is an honest correction, not a fake precision.

How to read your number

Because of that overhead, online scores run higher than the textbook figures. The median web result is about 273 ms; simple visual reaction in a lab is closer to 200–250 ms. Both are correct. They are just measured on different equipment. When you compare yourself to other people online, the web number is the fair one, because they are on imperfect screens too.

What this is not

ReactScore is built for curiosity, training and friendly competition. It is not a medical instrument. A slow score after a bad night's sleep is meaningless; a consistent, dramatic change over time is a conversation for a doctor, not a web page. We never diagnose anything.

References

The reference figures on this page are drawn from public datasets and peer-reviewed research: