Click steadily 10 times. We compare each click's timestamp to the moment it's processed to estimate input latency.
A mouse polling at 1000Hz reports its state every millisecond, which sounds instant. It is not. Between your finger pressing the button and a pixel changing, the signal crosses the switch and survives the debounce. Then it queues at the USB port and waits its turn through the operating system and the game, and only then does the monitor light the pixel. The mouse latency test estimates one slice of that chain, the gap between your physical click and the browser receiving the event.
No browser test can replace a rig with a high speed camera and a photodiode, and anyone claiming otherwise is selling something. What a browser test can do is measure your system as you actually use it and catch configuration mistakes. It also hands you a number you can compare against your own machine after every change. That is worth having.
Click repeatedly and the engine compares the timestamp the browser attaches to each pointerdown against its own processing clock, then reports the average gap. The figure covers the path from the electrical signal through the mouse firmware and its debounce. From there it crosses USB into the OS input queue and lands in the browser's event loop. In ClackLab the result appears as a millisecond readout with your best and average side by side.
The absolute number depends on your whole stack, and that is the point. The same mouse measures differently on a quiet desktop and a laptop running a compile job, because input events queue behind whatever the machine is busy doing. Compare like with like. Same machine, same browser, or the number means nothing.
Numbers, so the abstraction ends. The switch closes in under 1ms. Firmware debounce waits 4 to 8ms in a typical gaming mouse, since it must mask the contact bounce described in the double click test guide. USB polling adds 1ms at 1000Hz and 8ms at 125Hz, the gap the polling rate test estimates. The OS and the browser event loop add a few more, and scheduling delays can spike that under load.
Add the display and the picture completes. A 60Hz panel spends 16.7ms per frame and a 144Hz panel spends 6.9ms, so the click to photon total lands somewhere between 30 and 70ms on a healthy system. This is why one upgrade rarely fixes a lag feel. A 1000Hz mouse paired with a 60Hz monitor still waits on the panel for most of the delay. The chain improves at its slowest link, so measure before spending.
Close the noise first. Chrome throttles background tabs to roughly one timer tick per second. A test left in a background window reads like a broken mouse, and that applies to any timing tool run in a browser. Plug the receiver or cable straight into the machine, since cheap hubs add buffering. Quit the download and the compile job. On a laptop, run the test twice. Give battery saver and performance mode one run each, because power plans throttle USB and CPU response aggressively.
Sample size matters. Twenty clicks is a sniff test, a hundred is a reading. Fast deliberate clicking, around five per second, gives the event loop room to clear between presses and produces the honest floor number. Frantic 12 CPS hammering shows you the delay under the exact load a game fight creates. Both readings are real, and they answer different questions.
On a mid range gaming setup the test lands around 10 to 30ms of browser side latency, and on a tuned one it pushes lower. A reading that jumps past 50ms under load is a queue building somewhere. The prime suspect is browser tabs in the background. A power saver plan follows, then a hub in the path. The last suspect is a wireless mouse dropping into a battery saving poll rate. Work down that list and retest after each change, one variable at a time.
Do not chase zero. Sub 5ms readings on a stock system usually mean the measurement caught a lucky scheduling tick, not that your input chain broke physics. The trend line is the product. A machine that reads 15ms today and 15ms next week under the same load is healthy. A machine whose number doubles after a driver update just told you exactly which update to roll back.
Run the mouse latency test and click steadily for a hundred presses, then read the average gap in milliseconds. Test on the same machine and browser whenever you compare, since the number reflects your whole setup. Rerun it after every hardware or driver change to catch regressions early.
Between 10 and 30ms browser side is normal on a mid range gaming setup, and below 10ms is excellent, which usually needs performance mode and a clean USB path. Above 50ms means a queue is building, and background tabs or battery saver plans are the first suspects.
Up to a point. The test sees the gap between the browser receiving the event and finishing its processing. The switch and the wire before it stay invisible. It cannot replace a camera and photodiode rig, and it does not need to, because config mistakes show up in the part it does see.
Modern 2.4GHz gaming mice add roughly 1ms over wired, which no human notices. Bluetooth adds more and sleeps to save power, so it can spike into tens of milliseconds after idle. Use the dongle for play and Bluetooth for the couch.
No. The monitor sits after the measurement window, so the test reads the same on 60Hz and 240Hz panels. Your click to photon delay still falls with a faster panel, and knowing which half of the chain you improved is exactly why the two measurements exist separately.
The polling rate test estimates your mouse's USB report rate in Hz. Mouse CPS grades click speed and rhythm, and the reaction time test measures the wetware sitting upstream of all of it. That component contributes more milliseconds than anything else on this page.