Input lag and reaction time are often treated as the same thing. They are not. Reaction time is the human response after a stimulus. Input lag is device and system delay around that response. A web reaction test measures the combined path unless it explicitly separates the pieces it can observe.

PulsarMS exists because that distinction matters. A 190 ms score on a slow laptop and a 190 ms score on a high-refresh desktop do not mean exactly the same thing.

The latency path in a visual reaction test

A simple visual run includes:

The app schedules the stimulus.
The browser presents it on a frame.
The monitor scans out and pixels change.
Your eyes detect the change.
Your brain decides to respond.
Your finger moves.
The mouse or keyboard reports the input.
The browser receives the event.
The scoring code records the timestamp.

Only some of these are observable from a web page. PulsarMS can observe browser-side presentation and input timestamps. It cannot directly observe the first photon, retina, nerve conduction, or switch contact physics. That is why confidence bands matter.

The latency path in an audio reaction test

Audio has a different stack:

The app schedules a sound.
Web Audio places it on the audio timeline.
The operating system and device output the signal.
Speakers or headphones produce the sound.
Your ears detect it.
Your brain decides to respond.
Your finger moves.
The input device reports the event.
The browser receives the event.

The Web Audio API is built for precise audio scheduling, but it does not tell the page the exact physical output moment for every headset. Bluetooth, TV speakers, USB devices, and operating-system mixers can add hidden delay. See the audio reaction time test guide for that modality.

What you can control

The best way to reduce noise is to control the setup:

| Variable | Better baseline | |---|---| | Display | High-refresh monitor, game/low-lag mode | | Input | Wired or proven low-latency mouse/keyboard | | Audio | Wired output for baseline tests | | Browser | Foreground tab, no battery saver | | Environment | Same room, same posture, same time window | | Statistics | Median across clean trials, not best trial |

You do not need a perfect lab to learn something useful. You just need to avoid mixing many variables at once.

Why mouse polling is smaller than people think

Mouse polling can matter, but it is usually not the first bottleneck. Moving from a bad office mouse to a stable gaming mouse can help. Moving from a good 1 kHz mouse to an 8 kHz mouse may be hard to see in a simple reaction test because human variance is often larger than the polling change.

Spend attention in the right order: stable sleep, display refresh, clean input, and repeatable sessions. If you are shopping for hardware, read best gaming mouse for reaction time with that context.

How PulsarMS reduces false precision

PulsarMS uses wide randomized waits to make anticipation unprofitable. Audio mode uses 10 randomized sound cues and ignores pre-cue clicks so the cue itself remains the timing origin. It records visual refresh rate and audio output information where the browser can provide it. It also keeps the modality separate: visual scores and audio scores should not be merged into one vague "reflex" number.

It also connects to the rest of the measurement guides:

Bottom line

Reaction time is you. Input lag is the system around you. A serious test should help you tell the difference instead of hiding both inside a single number. Once you separate them, setup changes become easier to evaluate and training changes become easier to trust.

Sources & context

For browser timing background, see MDN's requestAnimationFrame and Web Audio API references. PulsarMS only claims the browser-observable parts of this stack; how we measure documents where that boundary sits and how the confidence band is built.

Input Lag vs Reaction Time: The Millisecond Stack