Input lag test
Input lag is a chain, and a web page can see two links of it: how long your click takes to reach the page, and how long from there to the frame that answers it. It cannot see your monitor. This measures the part it can measure, states the part it cannot, and tells you what each one means.
- Click to frame—
- Verdict—
- Reaching the page—
- Waiting for the frame—
- Worst of the run—
- Refresh interval—
What did click-to-frame come out at?
Where the measurement stops
This is the part worth being clear about, because most pages offering an input lag test are not.
The full chain, from your finger to the light reaching your eye, is roughly this:
- The mouse decides it has something to report, and waits for its next reporting slot.
- The event crosses USB or a radio link and enters the operating system.
- The operating system timestamps it and passes it on.
- The browser receives it and runs this script. The measurement starts here, at step 3, and this is “reaching the page”.
- The page changes something and the browser begins the frame that shows it. This is “waiting for the frame”, and the measurement ends here.
- The frame is composited, handed to the graphics driver, and sent down the cable.
- The display receives it, does its own processing, and drives the panel.
- The liquid crystal or the OLED actually changes.
Steps 3 to 5 are measured. Steps 6 to 8 are not, and cannot be from inside a page. Together they are typically another 5 to 20 milliseconds on a monitor, more on a television, and a great deal more on a television in a picture mode that is not called Game.
That is why the result is labelled click to frame rather than input lag. The figure below it adds one refresh interval, which is the earliest those pixels could possibly be lit, and even that is a floor rather than an answer — the panel’s own delay comes after it.
Reading the two halves
They fail for different reasons, so read them apart rather than together.
Reaching the page should be a few milliseconds. A 125 Hz mouse spends up to 8 ms of that waiting for its own next report, which is worth knowing before you blame anything else — the polling rate test measures that directly. Above roughly 15 ms with a decent mouse, something is holding the input path up: a busy machine, a power profile throttling it, an extension running work on every event, or a Bluetooth link.
Waiting for the frame cannot be smaller than zero and cannot usefully be larger than one refresh interval. If it is consistently larger, the browser is missing frames — the page is competing with something for the processor or the graphics card.
The worst reading is the one that describes how it feels. Input lag is noticed at its peaks, not its average.
Windows 11
- Power mode. Settings → System → Power → Power mode. On Balanced or Power saver, Windows parks processor cores, and waking one up to handle an input event costs milliseconds. Best performance removes that, at the cost of battery.
- Bluetooth mice are the single most common cause of a poor first figure on a laptop. A dongle or a cable is a different order of result, not a small improvement.
- Hardware-accelerated GPU scheduling (Settings → System → Display → Graphics → Advanced) changes how frames are queued. It is worth testing both ways rather than trusting either, because which one wins depends on the machine.
- Game Mode does nothing for a browser, and browser hardware acceleration does. If click-to-frame is high, check that acceleration is on in the browser’s own settings before changing anything in Windows.
macOS
- Low Power Mode throttles both halves of this measurement. Turn it off before drawing conclusions from a laptop on battery.
- ProMotion displays vary their refresh rate down to 24 Hz when the content is static, and a page that is not animating is static. This test runs a continuous animation loop for exactly that reason — without it the refresh interval it measured would be the idle rate rather than the one you get while playing.
- macOS exposes no equivalent of the Windows scheduling controls. If the figures are high on a Mac, the cause is load or power state rather than a setting.
What this is good for
Deciding where to look next, which is most of the value in any diagnostic.
A high first figure is yours to fix, and the fixes above are real. A low click-to-frame with a system that still feels sluggish moves the search to the monitor or to the application, and rules out an entire category of advice you would otherwise have worked through. That is a smaller claim than “measure your input lag”, and it is one this page can actually keep.
Common questions
Does this measure my monitor input lag?
No, and nothing running in a browser does. What a monitor review calls input lag is the gap between the display receiving a signal and the pixels changing, and measuring it requires a camera or a hardware lag tester pointed at the panel — an instrument outside the computer. A web page finds out what happened inside the computer and then hands a frame to the graphics stack, and that is where its knowledge stops. Any page that gives you a single millisecond figure and calls it your monitor input lag has estimated it.
So what is actually in the number?
Two things, and the test shows them separately. "Reaching the page" is from the timestamp your operating system put on the click to the moment this script was allowed to run — that contains the mouse reporting interval, the USB stack, the operating system input path, and any work the browser was busy with. "Waiting for the frame" is from there to the start of the frame that carries the response, which is mostly waiting for the next refresh. Added together they are click-to-frame, which is real and yours.
Why can I not get below about 10 ms at 60 Hz?
Because of the second half. Your click lands at a random moment inside a refresh interval, and the response cannot appear before the next one begins. At 60 Hz that interval is 16.7 ms, so on average you wait about 8 ms for it and sometimes the whole 16.7. At 144 Hz the interval is 6.9 ms and the same waiting costs a fifth as much. This is the single largest reason a high refresh rate feels more responsive even outside games.
My worst reading is much higher than the median. Does that matter?
It matters more than the median does. A path that is steady at 15 ms feels better than one that averages 10 ms and spikes to 60, because the spikes are what you notice — the pointer keeps up and then briefly does not. A worst reading several times the median points at something intermittent: background work, a browser extension doing something on every event, thermal or battery throttling, or a wireless mouse with a poor link.
Is a wired mouse faster than a wireless one?
By less than people assume, and this test will show you. A modern wireless gaming mouse with its own receiver adds around a millisecond, which is inside the noise here. Bluetooth is different — it is a shared, power-saving radio and can add well over ten, sometimes much more when the link idles. If your mouse is on Bluetooth and the first figure looks high, connecting it with a cable or its own dongle is the test worth running.
Does the browser make this worse than a game would be?
A little, and the honest amount is a few milliseconds. A browser goes through more layers than a game engine talking to the graphics driver directly. What the browser does not change is the shape of the answer: if reaching the page takes 40 ms here, it is taking too long everywhere, and the cause is outside the browser.
Why does clicking count but a synthetic click not?
Because the whole measurement is the distance between an operating system timestamp and this script running, and an event made by script has no operating system behind it. Its timestamp would be the moment the script created it, which is the moment the script ran, which is zero. The test only accepts real input for that reason.