How to use this test
- Click inside the box. The panel flashes the instant the response is painted. Click at a relaxed pace rather than as fast as possible.
- Give it ten or more clicks. A single measurement is dominated by whichever frame happened to be next. The median across ten clicks is far more stable.
- Close other applications first. Background CPU and GPU load add milliseconds. For a comparable number, test on a quiet machine.
- Compare, do not absolutise. Use this to compare wired against wireless, or one browser against another, on the same machine. It is a relative instrument.
What is input lag?
Input lag is the delay between you doing something and the screen showing it. It is not one delay but a chain of them, and understanding which link dominates is the difference between spending money usefully and spending it on the wrong component.
The full chain, and what we can see of it
| Stage | Typical cost | Visible here |
|---|---|---|
| Switch contact and firmware debounce | 1–8 ms | no |
| USB polling interval | 0.125–8 ms | no |
| OS input stack | 1–4 ms | no |
| Browser dispatch and render | 1–10 ms | yes |
| Wait for next display frame | 3–17 ms | yes |
| Monitor scan-out and processing | 2–20 ms | no |
Add those up and true end-to-end latency on a typical setup lands somewhere between 20 and 60 milliseconds. This test will report a number considerably lower, because it honestly measures only its own window rather than pretending to see the whole chain.
What this test measures, precisely
We record the timestamp your browser attached to the click event, then wait for the animation frame on which the visual response is actually painted, and report the difference. That window covers the browser's event dispatch, the work the page does in response, layout, paint, and the wait for the next display frame.
It does not cover the switch closing, your mouse firmware debouncing the contact, the USB polling interval, the operating system input stack, or the monitor's own scan-out delay. Those stages are invisible to JavaScript, and together they are a substantial fraction of what you actually feel.
Why your refresh rate dominates the result
Your display only accepts a new image at fixed intervals. At 60 Hz that is every 16.7 milliseconds. When your click arrives, on average you have already missed half of the current interval, so you wait roughly 8 ms for the next frame — before any other factor is considered.
At 144 Hz the interval is 6.9 ms and the average wait falls to about 3.5 ms. At 240 Hz it is closer to 2 ms. This is why refresh rate is the single most effective latency upgrade available, and why the display floor figure appears alongside your result — it tells you how much of your number is simply your monitor.
How to reduce input lag
In order of impact. The first item matters more than everything below it combined.
- A higher refresh rate display. Nothing else comes close. Moving from 60 to 144 Hz removes about 9 milliseconds of average wait; every other change on this list is worth one to three between them.
- Enable hardware acceleration. Check your browser settings. Software rendering adds several milliseconds to every frame and is sometimes switched off by troubleshooting advice that was never reverted.
- Close background applications. A busy CPU delays frame delivery, and this is the most common cause of inconsistent results rather than high ones.
- Disable browser extensions. Ad blockers and script injectors add work to every frame. Test in a private window to measure the difference.
- Use 2.4 GHz wireless or wired, not Bluetooth. Modern low-latency wireless is within a millisecond of wired. Bluetooth typically runs at 125 Hz with variable latency and is genuinely worse.
- Raise polling rate from 125 Hz. Worth a few milliseconds if your mouse is still at its default. Check with the polling rate test.
Why does my mouse feel laggy?
If your numbers here look fine but the mouse still feels wrong, look at consistency rather than the average. Erratic timing reads as lag even when the median is low, because your hand notices variance far more readily than absolute delay — a steady 20 ms feels better than something alternating between 8 and 30.
If your variance figure is high relative to the median, the cause is almost always background load or an extension rather than hardware. It is also worth running the polling rate test, because unstable reporting from a failing cable or wireless interference feels exactly like lag but is really jitter, and it will not show up here at all.
One more possibility worth ruling out: if clicks feel late rather than slow, and occasionally register twice, the switch itself may be failing. The double click test will show that in seconds.
Related tests
Latency is one part of how a setup feels. The polling rate test measures how often your mouse reports and how stable that reporting is, the CPS test measures your own speed, and the double click test checks whether the switch is registering cleanly.
Frequently asked questions
How do I test my input lag?
Click inside the test area above ten or more times at a relaxed pace. The panel flashes the instant the response is painted, and we report the time from the click event to that frame. Close other applications first, since background CPU and GPU load add milliseconds. Use the median rather than any single click, because one measurement is dominated by whichever frame happened to be next.
Does this measure my real mouse input lag?
No, and any site claiming otherwise is overstating what a browser can do. True end-to-end latency runs from the switch closing, through USB polling, the operating system input stack, the browser event loop, rendering, compositing, and finally your monitor drawing the pixels. JavaScript can only observe the last few stages. What we measure precisely is the time from the browser receiving the event to the frame that actually paints the response — a real, repeatable number, but only part of the chain.
What is input lag actually made of?
Six stages. Switch contact and firmware debounce takes 1 to 8 milliseconds, USB polling 0.125 to 8 depending on your report rate, the operating system input stack 1 to 4, browser dispatch and render 1 to 10, waiting for the next display frame 3 to 17, and monitor scan-out and processing 2 to 20. Total end-to-end latency on a typical setup lands somewhere between 20 and 60 milliseconds. This test sees only the middle two of those six stages.
How do I reduce input lag?
In order of impact: a higher refresh rate display, which is by far the biggest single factor and removes more latency than everything else combined; enabling hardware acceleration in your browser; closing background applications, since a busy CPU delays frame delivery; using a wired connection rather than Bluetooth, though modern 2.4 GHz wireless is within a millisecond of wired; and raising polling rate from 125 Hz if it is still at the default.
Why does my mouse feel laggy even with good numbers here?
Check consistency rather than the average. Erratic timing reads as lag even when the median is low, because your hand notices variance more than absolute delay. If your variance figure is high relative to the median, the cause is usually background load or a browser extension rather than hardware. It is also worth running the polling rate test, since unstable reporting feels like lag but is really jitter.
Why does my refresh rate appear in the result?
Because it sets the floor. A frame can only be drawn when the display is ready for one. At 60 Hz frames arrive every 16.7 milliseconds, so on average you wait about 8 milliseconds for the next one no matter how fast everything else is. At 144 Hz that average wait drops to roughly 3.5 milliseconds. A large share of the number you see is your monitor, not your mouse, which is why we show it alongside your result.
My results vary a lot between clicks. Is something wrong?
High variance almost always means background load rather than a hardware fault. Other browser tabs, extensions running scripts, a game or video encoder in the background, or an operating system update downloading will all delay the frame that paints your response. Close what you can and re-test. If variance stays high on a quiet machine, check that hardware acceleration is enabled in your browser settings.