Before you start
Understand the chain first. A click travels through the switch, the controller firmware, USB transport, the operating system, the browser event loop, your JavaScript, style and layout, the compositor, the display cable and finally the panel's own scan-out and response. A browser can observe only the middle portion of that list.
Decide what you are comparing. Latency measurements are useful for comparing two configurations on the same machine — two browsers, two refresh rates, power saver against performance mode. They are not useful for comparing against a published hardware figure.
Prepare the environment: close background tabs, keep the window still, put the tab in the foreground and disable any recording software. Every one of these shifts the paint boundary and inflates the tail of the distribution.
Run the check
Open the mouse latency test and click each target as it appears. Every pointerdown stores its event timestamp and schedules two animation frames; the second callback records the elapsed click-to-paint interval. Two frames are used because one is not enough to guarantee the paint has actually happened.
Collect at least twenty samples. The summary reports median, 95th percentile and median absolute deviation rather than a mean, because a single scheduling interruption would distort an average far more than it distorts a median.
Repeat the same procedure with the keyboard latency test. Comparing mouse and keyboard on the same machine isolates the input path, since everything after the event dispatch is shared between them.
For a repeat-rate question rather than a latency question, use the keyboard repeat rate test instead. It measures how frequently held-key repeat events arrive, which is a system setting and a fundamentally different measurement.
Now change exactly one condition and repeat. Switching a display from 60 Hz to 144 Hz, for example, should visibly move the median, and it is a good way to confirm that the measurement responds to real changes.
Read your result
Expect values well above what hardware reviews publish. A review measuring sensor-to-photon with a photodiode reports single-digit milliseconds; a browser measurement includes an entire rendering pipeline and will typically report considerably more. Both are correct measurements of different things.
Read the spread as seriously as the median. A tight distribution means the system is delivering frames consistently, which is often more important to how something feels than a slightly lower median with a long tail.
Refresh rate dominates. At 60 Hz a frame boundary arrives every 16.7 ms, so a large part of any measured value is simply waiting for the next frame. This is why higher refresh displays improve perceived responsiveness more than almost any input device change.
Measurement limits
The result includes browser dispatch, JavaScript, style, layout, paint and compositing. It excludes the switch, the firmware, USB transport, the display cable and the panel response, and there is no way for a page to observe any of those.
Timer resolution is deliberately reduced in browsers to mitigate timing attacks, so very small differences are not resolvable. Treat differences of a millisecond or two as noise unless they persist across many repeated runs.
Background activity is invisible but influential. Another tab doing work, a system update, or a power profile change will shift results without appearing anywhere in the measurement.
What to do next
If two configurations produce distributions that do not overlap, the difference is real and worth acting on. If they overlap, you have not measured a difference regardless of what the medians say.
If the median is high and the spread is wide, look at system load and refresh rate before considering input hardware. Those two account for the large majority of poor results.
If you are trying to reduce latency in a game, this measurement will not help directly. Use the game's own frame-time and latency tooling, because a browser's rendering path has almost nothing in common with a game engine's.
Symptom table
| Symptom | Likely layer | Next action |
|---|---|---|
| Values much higher than reviews | Rendering pipeline is included | Compare configurations, not published figures |
| Wide spread between samples | Background load or frame pacing | Close other tabs and repeat in the foreground |
| No change after a mouse upgrade | Refresh rate dominates the total | Compare 60 Hz against a higher refresh mode |
Common questions
Can a browser measure real input lag?
It can measure the click-to-paint portion accurately, which includes event dispatch and the whole rendering path. It cannot see the switch, USB transport or display response, so it is a slice of the chain rather than the whole of it.
Why is my browser latency result so much higher than a review?
Reviews measure sensor-to-photon with external hardware and exclude the browser. A page measurement includes JavaScript, layout, paint and compositing, so a larger number is expected and correct.
Does a higher refresh rate reduce input lag?
Meaningfully, yes. At 60 Hz a frame boundary arrives every 16.7 ms and much of any measured latency is spent waiting for it. Moving to 120 or 144 Hz reduces that waiting more than most input hardware changes do.