Input Lag vs Reaction Time: The Millisecond Stack

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.

WiredReflex 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:

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

Only some of these are observable from a web page. WiredReflex records the visual cue's requestAnimationFrame callback timestamp and the response's input-event timestamp. Neither directly measures the first photon, retina, nerve conduction, or switch contact physics. The displayed ± estimates browser timing resolution; it is not a statistical confidence interval or a bound on total device latency.

The latency path in an audio reaction test

Audio has a different stack:

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

The Web Audio API supports scheduled playback and an estimated output timestamp, not a physical measurement at your ear. 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:

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

Polling interval is not total click latency

Keep three quantities separate:

• Polling interval: time between report opportunities. Microsoft's USB endpoint documentation describes the bus polling interval, not the full button-to-app path.
• Total click latency: delay from a defined physical button event to a defined receiver, such as the host receiving a button report. Switch processing, firmware and transport belong here; benchmark numbers are comparable only when their start and end points match.
• Measured human response: the browser cue-to-input interval, which includes your response and uncalibrated display/input offsets. It is neither of the hardware quantities above.

Calculated example, not measured benchmark data: for perfectly regular reports, interval_ms = 1000 / polling_hz. If a button event becomes report-ready at a uniformly random point between reports and goes out on the next report, its modeled mean wait is half the interval.

The modeled mean-wait difference is 0.5 - 0.0625 = 0.4375 ms. That is not an observed score gain, a complete click-latency estimate, or a guarantee that a device achieves its advertised rate. For hardware selection rather than this timing model, use the mouse latency buying criteria.

Compare one setup change at a time

To compare two polling settings on the same mouse, use the visual reaction time test as a whole-setup comparison, not a mouse latency bench:

1. Label settings A and B. Record the mouse, firmware, connection, USB port, browser version, display refresh and power mode. Keep everything except polling fixed.
2. Do one practice run per setting. Then collect four five-trial runs in A-B-B-A order, rest, and repeat in B-A-A-B order. This is a practical starting protocol, not a statistical power guarantee.
3. Keep the same seated posture and finger position; leave the cursor inside the target. Record each run's median, spread, valid-trial count, false starts and displayed timing resolution. Do not discard a run just because its score is slow; note interruptions separately.
4. Compare all run medians by setting and inspect whether the direction repeats across both orders. If the difference changes sign or is small relative to the run-to-run spread, call the comparison inconclusive, not proof that the devices are identical.

Practice, fatigue and expectation still affect this unblinded comparison. Replacing the mouse also changes shape and actuation, so it cannot isolate polling. A repeatable browser-score difference describes this person and setup; isolating physical click latency needs an external, documented hardware measurement. Do not subtract the calculated polling wait from your score to infer neural reaction time.

How WiredReflex reduces false precision

WiredReflex uses wide randomized waits to make anticipation unprofitable. Audio mode uses 10 randomized sound cues and voids any cue clicked before onset, 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:

• Visual reaction time measurement guide
• Auditory reaction time measurement guide
• Monitor refresh rate and reaction time
• Reaction time score interpretation
• Reaction time test hub
• Browser reaction time test accuracy
• Mobile vs desktop reaction time tests

Bottom line

Reaction time is your response; input lag is the system around it. A browser score combines them. Keep the setup fixed to track yourself, change one factor to explore the setup, and use a hardware bench when you need a component's physical latency.

Sources & context

The primary specifications linked above explain browser timestamps, audio estimates and USB report scheduling. They are not mouse benchmarks or evidence of a particular person's score improvement. How we measure documents WiredReflex's timing boundary and resolution estimate; physical device offsets remain uncalibrated.