Click Latency Tester
Measure how quickly your browser processes mouse clicks and how long it takes for the screen to respond.
This tool runs a 20-click test and reports three things: how long your browser takes to receive each
click after the operating system dispatches it (Input Processing Delay), how long it
takes for a new frame to actually appear on your screen after the click (Click-to-Paint
Latency), and how consistent those timings are (Jitter). All measurements
are made using performance.now() and Event.timeStamp at high resolution.
Click the blue target whenever it appears. After 20 clicks you'll see a full statistical breakdown (min, median, 95th percentile, max and standard deviation) and a distribution histogram.
How this test works (methodology)
Input Processing Delay (IPD)
When you click, the operating system stamps the event with a timestamp and passes it to the browser.
The browser then schedules a JavaScript event handler to run. We compare event.timeStamp
(set by the browser when it received the event) with performance.now() measured inside
the event handler. The difference is the time the browser spent processing before your code saw the
click. Modern browsers typically report under 1 ms here; higher values suggest the main thread
was busy with other work.
Click-to-Paint Latency (CPL)
At the click handler we schedule a double requestAnimationFrame. The second rAF
callback fires after the frame containing the visual feedback has been committed. We measure the
time from the click until that second rAF, which approximates when a new frame was actually
presented. This is bounded by your display's refresh interval — roughly 16.7 ms on a 60 Hz
display, 8.3 ms on 120 Hz, and so on. We estimate your refresh rate by timing consecutive
frames during the test.
Jitter (standard deviation)
We report the standard deviation of the Input Processing Delay across all clicks. A low standard deviation means the browser is consistently fast; a high one means timings are uneven, which often indicates background tasks, thermal throttling, or a busy OS scheduler.
Refresh-rate estimation
Before the test begins we run 30 empty requestAnimationFrame callbacks and measure
the median interval between them. The inverse of that interval (rounded) is our refresh-rate
estimate. Browsers may cap rAF at 60 Hz in background tabs or on battery-saver settings, so
keep this tab focused during the test.
Event.timeStamp precision can also be reduced by browser privacy mitigations (typically
to 0.1 ms or 1 ms). Hardware-accurate testing requires external equipment such as a
high-speed camera or a logic analyser on the USB line.