DeviceBenchFree online input lag test
Input lag test from the press to the painted frame
The stopwatch here starts on the timestamp your browser wrote onto the press and stops on the first task that runs after the frame answering it has been painted, which is the entire span a web page is able to observe. Every press is reported twice over: the part spent waiting for the browser to reach the handler, which is your machine being busy elsewhere, and the part spent waiting for the display’s next chance to show anything, which is the panel. Your reflexes sit outside both figures, since nothing on this page waits for a cue — and so do the mouse’s own report delay before the timestamp and the compositor, cable and panel after it, none of which any browser exposes.
- 100% free
- No signup
- 40 presses
- Queue vs paint split
- Reaction time excluded
Press the pad below. Speed does not matter and there is nothing to wait for — the clock starts on your press, not before it.
Where the milliseconds went
Two numbers appear here after the first press: the wait before the browser ran the handler, and the wait after it for the frame to reach the screen.
Every press in this run
Each press adds a bar here, newest on the right.
Read this as the browser’s share and nothing more. Before the clock starts, the mouse has already spent time deciding to report the press and the operating system has spent time routing it; after the clock stops, the frame still has to go through the compositor, down the cable and into a panel that lights its pixels at its own pace. None of that is visible to JavaScript, so the true delay between your finger and the photons is always larger than the figure above. Treat it as a floor under the real thing, and as something to re-run after changing one setting.
How to measure input lag in the browser
Twenty presses, then read the split — the two halves have different cures.
Press the pad about twenty times, at any pace you like
There is nothing to react to and no advantage in being quick — every press is timed from its own timestamp, so a press you took your time over measures exactly the same as a snap one. Twenty is roughly where the median stops moving; the run keeps the last forty and the oldest fall off the front as you continue.
Read the two halves separately
The bar under the results divides the median into the time before the browser reached the handler and the time after it. The first half is contention — other tabs, a background process, a busy machine — and it shrinks when you close things. The second half is the wait for the display's next opportunity to show anything, and closing tabs will not touch it.
Change exactly one thing and press again
This figure earns its keep as a before-and-after instrument: switch the monitor out of a picture mode, turn off a browser extension, unplug the second screen, move the window between displays, then clear the run and take another twenty presses. An absolute number from one machine means little on its own, but a shift of eight milliseconds after one change is a real result.
Technical specifications
| Clock | performance.now() throughout — monotonic, sub-millisecond, and immune to a clock correction mid-run in the way Date.now() is not |
|---|---|
| Start of the interval | event.timeStamp on the pointerdown event, written by the browser when the operating system delivered the press |
| End of the interval | The first task after that frame's rendering steps, reached with a frame callback followed by a MessageChannel message — a frame callback alone lands before the paint and undercounts by a full frame |
| Reported split | Queue (event timestamp to handler entry) and paint (handler entry to committed frame), given separately as well as summed |
| Run length | Up to 40 presses, oldest discarded first; median, best, slowest and p95 |
| Rejected samples | Anything over 500 ms is counted as discarded rather than averaged in — that is a tab switch or a stall, not the input path |
| Outside the measurement | The mouse's report interval and the OS input thread before the timestamp; the compositor, the cable and the panel's own scan-out and pixel response after the commit |
| Data kept | 40 sets of three durations, held in the tab and cleared by the button or a reload; no pointer coordinate is read or stored |
Frequently asked questions
Does my reaction time end up in the number?
No, and that is the main design decision on this page. Nothing here waits for a cue and nothing asks you to respond to anything — the stopwatch starts on the timestamp attached to your own press, so however long you hovered beforehand costs nothing. Most pages that call themselves input lag tests do the opposite: they flash something, wait for you to click and report the gap, which measures a human nervous system with a computer somewhere inside it. If that is what you were after, the reaction time test does it properly, with false starts caught.
Why does the figure never drop below one frame?
Because a screen can only show something at the moment it is ready to draw, and nothing you do makes that moment come sooner. A press landing just before a frame is prepared gets on that frame almost immediately; a press landing just after it has to wait for the next one. On a 60 Hz display that wait can be anything up to 16.7 ms and on a 144 Hz display up to 6.9 ms, so the median of a long run tends to settle near half a frame plus whatever the machine spent on top.
My monitor is advertised at 1 ms. Why does this read twenty-something?
Those are two unrelated quantities that share a unit. The 1 ms on the box is pixel response — how long a pixel takes to change color once it has been told to — while this figure is signal latency, the queue from your press to a finished frame. A monitor with instant pixels can still add ten milliseconds of its own processing before it draws anything, and no panel can shorten the frame boundary the whole system is waiting on. Response time has its own page here, and it is deliberately visual rather than numeric.
How is this different from the keyboard latency test?
That page times a keypress and this one times a pointer press, and the two travel different routes into the browser. A key goes through the keyboard's own scan matrix and debounce firmware before anything leaves the device, which is the part that page is built to expose; a mouse click goes through a switch and the mouse's report interval instead. Use that one when you are judging a keyboard and this one when you are judging what the display path does with a click.
Does a wireless mouse add to this?
It does, and none of it appears in the figure. Everything before the browser stamped the event — the switch closing, the mouse's own firmware debouncing it, the wireless link waiting for its next slot, the USB stack delivering it — has already happened by the time this measurement starts, so a 125 Hz Bluetooth mouse and an 8,000 Hz wired one produce identical readings here. The report interval that governs that hidden portion can be measured separately on the mouse rate checker.
Why is the first press of a run always the slowest?
The first press pays for work the rest do not. The browser compiles the handler on first use, the styles for the flipped state have never been computed, and the graphics layer may have to allocate before it can paint — after which all three are cached. This is why the run keeps every sample visible as a bar rather than only reporting an average, and why the median is the headline: one expensive first press moves a mean and leaves the middle value alone.
Should I close my other tabs before running it?
Only if you want the best case rather than the honest one. Other tabs, extensions and background downloads all compete for the same main thread, and their cost lands almost entirely in the first half of the split — so leaving them open tells you what your machine actually feels like, and closing them tells you what it is capable of. Running both and comparing is more informative than either on its own.
About the input chain and the part of it a page can time
Between a finger and a photon there are at least nine stages: a switch closes, the device’s firmware debounces it, the report waits for its slot on the USB or wireless link, the operating system’s input thread picks it up, the browser queues it, JavaScript runs, styles and layout are recomputed, the compositor assembles a frame, and finally the monitor receives it, processes it and scans it onto the panel while each pixel takes its own time to change color. Reviewers who publish a monitor input-lag figure are measuring a specific slice of that with external hardware — typically a photodiode taped to the screen and a signal generator standing in for the input — and they can do it because they are outside the computer. A web page is inside it, and can only see the stages the browser itself timestamps.
Those boundaries are what make this measurement honest rather than impressive. The starting mark is event.timeStamp, which the browser writes when the operating system hands over the press, so everything the mouse and the kernel did beforehand is already spent. The finishing mark is the task that runs immediately after that frame’s rendering steps, obtained by waiting for a frame callback and then for a message posted through a MessageChannel — a distinction worth insisting on, because a frame callback by itself fires before the paint, and a page that stops its clock there reports a whole frame less than the truth. What is left after the commit — compositing, transport and the panel’s own scan-out — is invisible to JavaScript, which is why the real delay between your hand and the picture is always larger than what you see here.
The reason to take many presses rather than one is that a large part of this quantity is a coin toss. Frames leave on a fixed schedule, so a press arriving just before one is assembled catches it, and a press arriving just after it waits nearly a whole frame period — spread over enough presses that wait averages to about half a frame, and the frame period comes from your display: the refresh rate test measures it, and the Hz to ms converter turns it into the milliseconds this page is quantized by. The other neighbors are worth keeping straight. How often the mouse reports its position, upstream of everything timed here, is on the polling rate test. How fast you are, which this page removes on purpose, is on the reaction time test. The same timing done on a keypress instead of a pointer press — a different route through a scan matrix and debounce firmware — is on the keyboard latency test. And when the picture arrives on time but looks smeared or uneven rather than late, the ghosting test and the FPS test cover those two failures respectively.
What a press leaves behind
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
A press contributes three durations to an array that never grows past forty entries, and nothing else about it is looked at — not where on the pad you pressed, not which button, not what kind of pointing device it was. Clearing the run or reloading empties the array, and there is no stored best score to compare you against next time.