DevicedialWhere do the milliseconds between your click and the pixel go?
No single test can see the whole chain. Added one link at a time, it stops being a feeling.
One gear check a month
MonthlyOne thing a month worth measuring before it fails properly — a mic that reset itself, a stick that drifts, a switch sending two clicks. Two sentences and the test.
Free to use — Pro is for keeping it
This tool, like every other one here, is free and needs no account. A free account keeps three setups and three email alerts. Pro takes the ads off every site we run and lifts that to 200 setups and 50 alerts, adds a public page for any result and lets you embed the tool without our badge.
Try also
How do I work out where my input lag comes from?
The Devicedial input lag budget adds up every wait between your hand and the screen, one row at a time, and reports the worst case in milliseconds. A row is either a rate or a fixed figure. A device reporting 1000 times a second can cost a full 1 ms interval, a 144 Hz screen can hold a finished frame for 6.9 ms, and a panel’s pixel response comes off its datasheet because no browser can measure it. The four rows it starts with come to 8.9 ms.
Worst case means every wait went against you at once, which is not what a normal press feels like, so the sheet halves the total as well: 4.5 ms, or half a frame at 60 Hz. Two of the four links have their own tests here and can be measured in seconds. The other two are yours to fill in, and a budget that says so is more use than one that quietly invents them.
What each link costs at the settings people actually own
Anything that reports at a fixed rate can cost you one whole interval: the press lands just after the last report and waits for the next.
| Link in the chain | What it means | Worst case it adds |
|---|---|---|
| Anything reporting at 125 Hz | 8 ms between reports | 8.0 ms |
| Anything reporting at 500 Hz | 2 ms between reports | 2.0 ms |
| Anything reporting at 1000 Hz | 1 ms between reports | 1.0 ms |
| Screen at 60 Hz | 16.7 ms a frame | 16.7 ms |
| Screen at 120 Hz | 8.3 ms a frame | 8.3 ms |
| Screen at 144 Hz | 6.9 ms a frame | 6.9 ms |
| Screen at 240 Hz | 4.2 ms a frame | 4.2 ms |
| Panel pixel response | A datasheet figure, invisible to a browser | Enter it as a fixed delay |
| Game or app render queue | Invisible to any web page | Enter it as a fixed delay |
The top two groups are the only links a browser can measure, and each has its own test on this site. Everything below them is a figure you bring, which is why the sheet asks for it instead of assuming one.
Which two rows can you measure right now?
The two rates, and both take seconds. The polling rate test reports the median gap between the movement reports your browser receives, so a 1 ms median is 1000 Hz and an 8 ms median is 125 Hz. The refresh rate test counts the frames the browser is actually given and prints the frame time in milliseconds beside the rate — which is the figure this sheet wants, and not always the one on the box.
Put those two in and the sheet already reproduces the worst case in the input lag chart, because it is the same arithmetic. What the chart cannot do is carry your panel’s response time or the render queue of the game you actually play, and those are the rows that make the total yours.
Where the budget stops being a number and starts being a decision
The order of the rows is the order worth spending money in. Going from 60 Hz to 144 Hz with the same mouse takes 16.7 ms down to 6.9 ms; the largest saving any mouse upgrade offers on the same screen is 7.0 ms, and only from a 125 Hz office mouse. If your own budget disagrees with that, it is usually because a fixed delay you entered is doing the work — which is exactly what it was for.
The human half is measured separately by the reaction time test, and it is an order of magnitude larger than everything here. Consistency is what these milliseconds change: a variable delay is far harder to aim through than a constant one.
Frequently asked questions
Do polling rate and refresh rate add up, or does one hide inside the other?
They add. The two are queues in a row, not alternatives: your movement waits for the mouse to report it, and the frame built from that report waits for the screen to draw. That is why the sheet has a row for each rather than asking you to pick one. At 60 Hz with a 125 Hz mouse the two together are 24.7 ms in the worst case, and at 144 Hz with a 1000 Hz mouse they are 7.9 ms.
My monitor says 1 ms. Why is that not the number in this sheet?
Because the 1 ms on the box is pixel response — how long the liquid crystal takes to change shade once it has been told to — and it is the smallest of the delays on this page. It says nothing about how long the finished frame waited to be drawn, which at 60 Hz is up to 16.7 ms. Both belong in the budget, which is why pixel response has its own row rather than being confused with the frame.
A high-speed camera measures more lag than this total. What is missing?
Everything the browser is not allowed to see. A camera pointed at the screen catches the operating system’s scheduling, the engine’s own render queue, any frame buffering the driver adds, the panel’s internal processing including overdrive and scaling, and the display’s own pipeline. Those routinely add more than everything on this page. The budget deliberately gives you the floor: the delay that is there even when the software is perfect.
How the test works
Sources: