A browser-based reaction time test is accurate at measuring exactly one thing: the interval between its own visual go signal and the moment the browser receives your press, expressed as a non-negative whole millisecond. That number is real and reproducible, but it is not a pure measurement of your nervous system. Display refresh, compositor scheduling, browser task timing, operating-system input handling, mouse or keyboard transport, wireless conditions, and event dispatch all sit between your finger and the displayed result, so the score reflects the system as well as the person. The Reaction Time Test records the signal with performance.now in the same callback that flips the panel to green, then records the press with another performance.now reading, and rounds the difference. A deterministic test fixture proves an exact 234 ms case exists in code rather than relying only on self-consistent timing code. Because the included layers vary by device, a number that looks slow on one machine and fast on another can reflect the hardware path rather than the operator.
What "Accuracy" Means for a Browser Reaction Time Test
Two different ideas of accuracy matter for a reaction test. The first is reproducibility: if the conditions repeat, does the score repeat? Most well-built browser tools clear this bar. The second is isolation: does the score reflect only the human response time and nothing else? No general browser utility can promise that, because JavaScript cannot observe the physical instant a finger moved, a switch closed, a wireless packet left a device, or a display pixel emitted green light.
So the honest answer to are reaction time tests accurate depends on which sense you mean. They are accurate at timing a browser-to-event interval. They are not accurate as a stand-in for a calibrated hardware latency meter, a medical instrument, or a sports gate. The Reaction Time Test is explicit about this: it times the page's ready-state callback against the pointer or keyboard event the browser delivers, and it discloses that display, browser, operating system, and input-device delay can all contribute to the same displayed number.
What the Millisecond Number Actually Includes
Inside a single trial, the score is the rounded difference between two performance.now readings. Between your decision and that number, several independent layers can each add or remove milliseconds:
- Display refresh — the panel may not paint green until the next frame, so the visible cue can lag the readiness callback.
- Compositor and browser scheduling — the work that changes the panel and the work that registers a press run on the same task queue.
- Operating-system input handling — the OS captures the event and hands it to the focused process.
- Input-device transport — wired and wireless paths deliver the press at different speeds, and wireless conditions can vary run to run.
- Event dispatch — the browser routes the press to the page's listener.
None of these layers is under the test's control, and none is constant across machines. That is why two devices owned by the same person can produce different "reaction times" on the same morning, and why the page does not claim those paths are physically equivalent.
Run the Reaction Time Test the Same Way Every Time
For a run-to-run comparison to mean anything, the workflow has to stay constant. The Reaction Time Test is built for short, repeatable sessions under one set of device conditions.
- Select Start test, keep the panel visible, and wait without pressing while it displays the waiting message.
- Press the panel, Enter, or Space as soon as the panel turns green and displays PRESS NOW.
- Repeat under the same device conditions to compare the last five, best, and average values, then Reset all when you want a fresh slate.
The page uses a fresh randomized waiting period from 1,500 through 4,000 milliseconds on each trial. The changing delay makes it harder to anticipate the signal from a fixed rhythm. If you press before the panel turns green, the pending trial is cancelled, the panel reports Too soon, and no result is added — but earlier completed history stays on screen so you do not lose good data to a single false start.
Why the Same Person Gets Different Numbers
Even on one device, repeated trials do not collapse onto a single value. Most of that spread is real noise from the layers listed above, plus ordinary variation in human attention. A few conditions swing the result more than others:
| Condition | What it does | Direction of effect |
|---|---|---|
| Background tab | Browser throttles timers and reduces frame rate | Increases the score |
| Power-saving mode | Lowers CPU and display refresh | Increases the score |
| High CPU load | Delays the readiness callback and event dispatch | Increases the score |
| Remote desktop | Adds network and encoding delay between you and the browser | Substantially increases the score |
| Wireless input | Adds variable transport latency | Increases variance more than the mean |
| Variable refresh display | Green paint time drifts frame to frame | Increases variance |
| Focused foreground tab | Timers run at normal rate | Lower and more stable scores |
The qualitative point is the takeaway: hold as many of these conditions constant as you can before deciding that one trial is your "real" score.
When Comparisons Break Down
Comparing a foreground local browser with a streamed or remote session is the clearest case where the same person gets two unrelated numbers. The end-to-end system delay is no longer the same machine, so the test is no longer measuring the same interval. The same is true when you switch input devices, move the window between monitors with different refresh rates, or change browsers. The page accepts pointer presses and the Enter or Space key while focused, so the workflow can compare different browser-delivered input paths — but it does not claim those paths are physically equivalent.
For a practical comparison, use the same device, input method, browser, window position, and display mode. Complete several trials rather than treating one outlier as a conclusion. If you want to compare mouse and keyboard responses, reset between groups and label the conditions outside the page, because the widget deliberately stores no experiment notes.
What This Tool Deliberately Does Not Claim
The Reaction Time Test does not apply age tables, percentile rankings, pass or fail labels, sports benchmarks, or medical thresholds, and it does not make claims about alertness. Those interpretations require controlled protocols and appropriate expertise that a general browser utility does not provide. It also does not test hearing, diagnose neurological conditions, assess fitness to drive, recommend training, or certify competitive performance. JavaScript cannot isolate human response from display latency, device transport, or switch behavior, and the page is explicit about that limit. If safety, health, employment, accessibility, or purchasing decisions depend on reaction measurement, an appropriate controlled instrument and qualified guidance are required.
Making the Score More Useful
The page retains the last five completed trials and calculates a best and rounded average for that short local session. Best is the smallest value among the five retained trials; average is their arithmetic mean rounded to the nearest millisecond. Older results fall out after the fifth completed trial, so the summary describes only the visible recent window. All timing state remains in the current tab — there is no login, no upload, no leaderboard, and no history after reload.
Worked example using five completed trials: 234, 251, 248, 240, and 267 ms. The best is the minimum, 234 ms. The sum is 234 + 251 + 248 + 240 + 267 = 1,240 ms. Divide by 5 trials to get an average of 248 ms, which the page then rounds to the nearest whole millisecond.
Use that small window the same way across sessions: keep the browser foregrounded, keep the same input method, and reset between groups when conditions change. Treat the number as a measurement of your system plus your attention, not as a standalone verdict on your reflexes, and you will get a fair read on what reaction time tests actually time.