Input Lag Explained: Where the Milliseconds Go Between Your Press and the Screen

Between your press and a visible result, the signal passes through your input device, the computer or phone, the browser or game, and the display. Each step takes a little time, the delays add up, and they differ between setups. This guide goes through each step with the arithmetic, then explains what it means for online reaction and timing tests.

The chain from press to pixel

"Input lag" usually means the end-to-end delay from your physical action to a visible result. It is easiest to think of as a chain:

1. Input device. The switch or touch sensor detects the press, and the device reports it to the computer at its next polling or sampling opportunity.
2. System and application. The operating system delivers the event, and the game or web page processes it and prepares a new frame.
3. Display. The new frame waits for the next screen refresh, is scanned out to the panel, possibly processed by the monitor or TV, and finally the pixels change colour.

In a reaction test there is also a chain before you move: the stimulus has to be drawn and displayed before you can see it. Both count toward "your" result.

Display refresh: the frame you are waiting for

A display shows a new image at a fixed rate. The time between refreshes is simply 1,000 ms divided by the refresh rate:

Why half a frame on average? An event can happen at any moment between two refreshes. Sometimes it lands just before a refresh and waits almost nothing; sometimes it lands just after one and waits almost a full frame. Averaged over many events, the wait is about half the frame time.

So going from 60 Hz to 240 Hz cuts the worst-case refresh wait by about 12.5 ms (16.7 minus 4.2), but the average saving from this step is closer to 6 ms. Higher refresh rates help in other ways too, since games rendering at higher frame rates usually have less delay in the rendering pipeline, but claims of a full frame's advantage on every event overstate it.

Two more display factors matter. The panel is updated from top to bottom over most of a frame, so something in the middle of the screen appears roughly half a frame after the top. And many TVs apply picture processing that can add tens of milliseconds unless "game mode" is on; monitors usually add much less. Pixel response time adds a few more milliseconds on many panels.

Input polling: how often your device reports

USB mice and keyboards do not push events at the instant you press. The computer collects reports at a fixed polling rate, so the same half-interval logic applies:

• 125 Hz (a common default for basic mice and keyboards): a report every 8 ms, about 4 ms of added delay on average.
• 500 Hz: every 2 ms, about 1 ms on average.
• 1,000 Hz (common on gaming mice): every 1 ms, about 0.5 ms on average.
• 4,000–8,000 Hz: a tiny further gain, at the cost of more CPU work.

Polling is only part of the device's delay. The switch has to be debounced (filtered so one press does not register as several) and the firmware adds processing. These vary by model and are rarely published, so the polling rate tells you the minimum, not the total.

Wireless is no longer automatically worse: gaming mice with a dedicated 2.4 GHz receiver are generally measured close to wired ones. Bluetooth usually has longer, less predictable connection intervals, so Bluetooth devices can add more and more variable delay. For timing-sensitive play, use a cable or a dedicated receiver.

Touchscreens: sampling and gestures

A touchscreen is scanned by a touch controller at its own sampling rate, often 60–240 Hz depending on the model, and the touch passes through the operating system's gesture handling before an app sees it. Total touch-to-screen latency on phones is usually in the tens of milliseconds, varies widely between models, and is typically larger than on a desktop with a wired mouse and a fast monitor.

Two details matter for web-based tests on phones:

• Which event is measured. A click fires when your finger lifts, not when it lands. A test that listens for clicks therefore adds the duration of your tap to every result. Tests that react to the moment of contact (pointerdown or touchstart) avoid that.
• Power-saving modes. Low-power or battery-saver modes can cap the refresh rate (for example, iPhones with 120 Hz displays drop to 60 Hz in Low Power Mode) and slow the processor, which adds delay and makes it less consistent.

Browser frame timing

A web page does not draw directly to the screen. The browser runs JavaScript, calculates layout, paints, and hands the result to a compositor that is synchronised with the display's refresh. A change made by a page usually appears on the next frame or the one after, depending on the browser, the operating system and how busy the page is. On a 60 Hz screen, each extra frame in that pipeline is another 16.7 ms.

Well-built web tests reduce the browser's share: they update the screen with requestAnimationFrame, which runs once per frame right before drawing, keep the page light, and read times with performance.now() or the event's timestamp. Browsers round these timers slightly for security, but the rounding is small compared with the delays above. What a page cannot control is your environment (other tabs, background apps, battery saving), which mostly adds variability.

Adding it up

Here is a worked example using only the parts that can be calculated from the specifications. It assumes the browser shows a change one to two frames after it is requested.

Debounce, display processing and pixel response come on top, so treat these totals as lower bounds, not measurements. The point is the gap: two ordinary setups can differ by 20–30 ms before the person does anything differently.

What this means for online reaction tests

In a reaction test, every delay adds directly to your score. A result of 250 ms on a 60 Hz laptop with a basic mouse and 225 ms on a fast desktop can come from exactly the same person.

So results are only comparable on the same setup, and a sudden "improvement" after buying a new monitor is not faster reflexes. Our article What Is a Good Reaction Time? explains how to test properly, and you can try it on the reaction time test.

What this means for timing tests

In a timing game such as TimerBattle, you try to stop a running clock at an exact target, so device delay affects you differently. The clock you see is already slightly behind, and your press arrives slightly late, so a constant delay mostly shifts all your results in the late direction. Because you are anticipating rather than reacting, practice partly corrects for that shift without you noticing.

The part you cannot learn away is the variation. On a 60 Hz screen, the refresh wait alone varies between 0 and 16.7 ms from one press to the next. TimerBattle's Perfect grade requires landing within 20 ms either side of the target, so on slow hardware that random variation is a noticeable share of the window.

Still, for most players the device is not the main source of error: across 25,300 rounds the median miss was 114 ms, several times the variation hardware adds. Our numbers include device delay, since players use their own devices, and we cannot separate it from human error; the Limitations section of What 25,300 Rounds Taught Us About Timing says so explicitly. In online modes, TimerBattle also checks results on the server so a modified client cannot simply report a better time. That protects fairness between players; it does not remove the latency of anyone's own device.

A practical checklist

• Check the refresh rate your system is actually using. A high-refresh monitor can run at 60 Hz if it is set that way in the operating system, or if the cable or port does not support the higher rate.
• Use game mode on TVs and turn off motion smoothing.
• Set your mouse to 1,000 Hz in its software if it supports it. Going higher brings little.
• Prefer wired or a dedicated 2.4 GHz receiver over Bluetooth for timing-sensitive play.
• In games, review sync settings. Traditional V-Sync can add latency when frames queue up; a frame-rate cap, variable refresh rate or a game's low-latency option are common alternatives.
• On phones, turn off low-power mode, close background apps and keep using the same browser.
• Test on one setup so your results stay comparable over time.

FAQ

Does a 144 Hz or 240 Hz monitor improve my reaction time?

It does not change your biology, but it reduces system delay: compared with 60 Hz, the average wait for the next refresh drops by roughly 5–6 ms. Your measured reaction time may improve slightly for that reason.

Is a wireless mouse slower than a wired one?

Gaming mice with a dedicated 2.4 GHz receiver are generally close to wired ones. Bluetooth connections tend to add more and less predictable delay.

How much does input lag affect a timing game like TimerBattle?

A constant delay mostly shifts you slightly late and is partly corrected by practice. The varying part, such as the refresh wait, adds some random error. For most players this is small compared with the typical miss of about 114 ms, but it matters more when you are chasing 20 ms Perfects.

Can a website measure my input lag?

Not completely. A page knows when it received your input and when it asked for a frame, but not when your finger moved or when the pixels actually changed. Measuring full end-to-end latency requires external tools such as a high-speed camera or a light sensor.