📊Input lag chart

By the Devicedial test desk

Refresh rate and polling rate are argued about as if they compete. They do not: they are two queues in a row, and the delay you feel is one of each. The table below is generated at build time from that arithmetic, for the nine refresh rates people actually own and the three polling rates mice actually ship with.

What does the worst case actually mean?

It means both queues went against you at once. A press that lands one microsecond after the mouse has sent its report waits a full polling interval — 8 ms on a 125 Hz mouse, 1 ms on a 1000 Hz one. The frame built from that report can then be finished one microsecond after the display has started drawing, so it waits a full frame as well.

Neither wait happens every time. On average you lose half of each, so a typical press at 60 Hz with a 125 Hz mouse costs about 12 ms rather than 24.7. The worst case is the number worth quoting because it is the one that produces the shot you swear you took. Measure your own two halves with the polling rate test and the refresh rate test before assuming which of them is the problem.

Which upgrade is worth the money?

The display, almost always, and the table says so in one line: going from 60 Hz to 144 Hz with the same 1000 Hz mouse takes the worst case from 17.7 ms to 7.9 ms, a saving of 9.7 ms. The largest saving any mouse upgrade can offer on the same screen is 7.0 ms, and that is only if you are starting from a 125 Hz office mouse. From 500 Hz to 1000 Hz the whole prize is 1.0 ms.

There is a second reason to fix the mouse first if it is genuinely a 125 Hz one. From 144 Hz upward the frame is shorter than the 8 ms between its reports, so the screen has frames to draw for which no new position exists. That is not lag any more, it is missing information, and no amount of refresh rate fixes it. The mouse tester confirms which buttons and wheel are reporting at all; the polling rate test puts a number on how often.

Why does the browser report a refresh rate the control panel does not?

Because a browser can only count frames it is given. A page measures the gaps between requestAnimationFrame callbacks, which is the rate at which the compositor delivered pictures to that tab — throttled if the tab was in the background, capped if hardware acceleration is off, and reduced on a laptop that has decided to save power. The control panel reports the mode the panel is set to, which is a different thing entirely.

Both numbers can be right at once. When they disagree, the guide on a monitor stuck at 60 Hz walks through the four causes in the order worth checking.

Does any of this matter for reaction time?

Less than the chart implies. A human reaction to a visual cue is a couple of hundred milliseconds, and the entire worst case here is under 25 ms even in the slowest row. What input lag changes is consistency: a variable delay is far harder to aim through than a constant one, which is why the same setup can feel fine one evening and wrong the next.

Measure the human half separately with the reaction time test, and the aiming half with the aim trainer. If the number that bothers you is clicks rather than milliseconds, the CPS test and the double click test cover that side — and the guide to a mouse that clicks twice explains the 50 ms threshold the latter uses.