Reading your results honestly
These tests measure the part of the input chain the browser can actually see. That is a useful slice — but it is only a slice. Here is what each number means and where it stops being trustworthy.
What each number means
Dispatch delay
The gap between the timestamp the browser stamped on the event and the moment your handler actually ran. This is queueing: main-thread work, garbage collection, other listeners.
Healthy: under ~2 ms. Above ~10 ms means the page is busy.
Paint delay
Time from your handler finishing to the next frame appearing. Bounded by your refresh rate — on a 60 Hz display it will rarely dip under ~8 ms, and averages around half a frame.
Total response
Dispatch + paint: the in-browser round trip from event to pixel. This is the closest thing to “what the page felt like”, and the number worth comparing between browsers or before/after closing background tabs.
Jitter (σ)
Standard deviation across samples. Consistency matters more than raw speed — a steady 12 ms feels better than a range of 3–40 ms.
Reaction time
Your biology plus the system. Typical adults land at 200–300 ms for visual cues. Subtract your measured total response to isolate the human portion, roughly.
Pointer sample rate
How many move events per second the browser delivers. A 1000 Hz mouse often reports ~120–250 Hz here because events are coalesced to the frame rate. Coalesced-event counts reveal the hidden ones.
Limitations of browser-based measurement
Switch actuation, USB polling, OS input stack and driver buffering all happen before the browser gets involved. Expect 5–20 ms of real latency that these tests can never observe.
Frame compositing, GPU queueing, monitor scaler and pixel response happen after paint. End-to-end click-to-photon latency is typically 2–4× what you see here.
Browsers quantise performance.now() and event timestamps to mitigate side-channel attacks. Resolution can be as coarse as 0.1 ms, or worse without cross-origin isolation.
Chromium, Firefox and Safari stamp events at different points in their pipelines. Compare results within one browser, not across them.
Other tabs, extensions, screen recording and thermal throttling all show up as jitter. Run tests twice before believing a bad result.
Held keys are repeated by the OS at its own rate, and pointer acceleration reshapes movement data. Neither reflects device capability.
Getting a clean run
- 01Close other tabs and pause downloads, video calls and screen recorders.
- 02Plug the laptop in — power saving caps CPU and refresh rate.
- 03Collect at least 40 samples; medians below that are noise.
- 04Repeat the run and compare medians. Differences under 2 ms are not real.
- 05Change one variable at a time: browser, cable, polling rate, display mode.