Comparing reaction-time scores across devices is useful, but only if the comparison is controlled. A faster score on one setup can come from your nervous system, your display, your input device, the browser, or the audio path. The job is to isolate one variable at a time.
Start from the reaction time test hub, then decide whether your question is visual, audio, or input-specific.
The golden rule: change one thing
If you change monitor, mouse, browser, refresh rate, desk height, and time of day at once, the result is not interpretable. Change one variable and keep the rest of the session boring.
Good comparisons:
| Comparison | Keep constant | |---|---| | 60 Hz vs 240 Hz monitor | Same mouse, browser, desk, test mode | | Wired mouse vs wireless mouse | Same monitor, refresh rate, browser | | Keyboard vs mouse | Same display and browser | | Phone vs desktop | Treat as separate categories | | Wired headphones vs Bluetooth | Same browser and input device |
For display-specific work, read monitor refresh rate and reaction time. For input stack context, read input lag vs reaction time.
A practical comparison protocol
Use a repeated, alternating protocol:
- Warm up with one discarded session.
- Run one clean session on setup A.
- Run one clean session on setup B.
- Repeat until each setup has at least three clean sessions.
- Compare session medians and spreads.
- Retest on another day if the gap is small.
Alternating matters because fatigue and attention drift during a session. If you run all of setup A while fresh and all of setup B while tired, the device comparison is polluted.
What counts as a real difference?
A device change is convincing when the median shift is bigger than the confidence band and repeats across sessions. A one-session 3 ms gap is usually not worth celebrating. A repeated 20 ms gap with similar spread deserves attention.
If the faster device also creates more false starts or a wider spread, the setup may be pushing you toward guessing. Use the false-start and anticipation guide before calling that improvement.
Do not compare phone scores directly with desktop scores
Touch input is a different physical action than a mouse click or keyboard press. It uses a larger target, a different finger movement, a touchscreen event path, and often a different refresh-rate profile. A phone can be excellent for same-phone tracking, but it is not a clean replacement for a desktop mouse baseline.
For that specific question, use keyboard vs mouse vs touch reaction time and mobile vs desktop reaction time tests.
Audio comparisons need extra caution
Audio device comparisons are especially easy to misread. Browser audio can schedule a cue, but the web page cannot directly observe the physical delay in the headset, speaker, Bluetooth codec, or TV soundbar. Treat audio comparisons as same-setup practical baselines unless you have calibrated external equipment.
For output-path detail, read wired vs wireless audio latency and the audio reaction time measurement guide.
Sources & context
The browser records input timing through event timestamps. MDN documents the Event timeStamp property, and the W3C Pointer Events specification describes the shared event model for mouse, pen, and touch inputs. PulsarMS uses those browser-observed inputs, so device comparisons should be interpreted as full setup comparisons rather than pure human physiology. How we measure sets out which parts of each setup the browser can actually timestamp.