The Input Lag Chain — from Finger to Pixel
Every hop between pressing a mouse button and seeing the result: switch, debounce, USB poll, OS, compositor, GPU, display — with typical ms.
Why “my mouse feels slow” is almost never the mouse
Input lag is a chain, not a number — and the mouse is a short link in it. Here’s every hop between your finger and a changed pixel, with honest typical values.
The chain, hop by hop
1. Switch actuation (~1–2ms). Mechanical travel from resting to contact. Optical switches skip contact physics but still have actuation travel.
2. Firmware debounce (~2–16ms). Metal contacts bounce — for a few milliseconds the signal flickers open/closed. Firmware deliberately waits for it to settle; that wait is configurable on some mice and is the quiet trade behind “zero debounce” marketing. Too low and you get the double-click fault later anyway as the switch ages.
3. USB polling (0–8ms, half on average). The host asks the mouse for data on a fixed schedule — 125Hz means a report can wait up to 8ms, 1000Hz up to 1ms, 8000Hz up to 0.125ms. Average cost is half the interval. This is the hop polling rate controls, and it’s one of the smallest.
4. OS + HID stack (~0.5–2ms). Interrupt handling, driver processing, delivery into the OS input queue — plus compositor batching on the cursor path.
5. Application input sampling (0–1 frame). A game or page reads input once per loop iteration. At 60fps logic that’s up to ~16.7ms of added wait; browsers deliver to pointermove/pointerdown handlers on the frame loop too — the delivery-delay number in our click test measures exactly this hop’s tail.
6. Render + present (1 frame, often queued). The engine draws the response; with V-Sync or a frame queue this is typically 1–3 frames — 16–50ms at 60Hz, 4–12ms at 240Hz. This is usually the largest single contributor.
7. Display processing + pixel response (~1–10ms). The monitor’s scaler, overdrive, and the physical pixel transition time. Game mode bypasses most of the processing hop.
Rough totals
A casual 60Hz setup lands around 30–80ms end to end; a tuned competitive setup (240Hz+, no V-Sync, game-mode monitor, sensible debounce) lands around 10–20ms. Inside both numbers, the entire mouse-side share — hops 1–3 — is roughly 3–10ms, and the polling-rate share of that is under 1ms once you’re at 1000Hz.
The practical takeaway
If clicks feel late, the fix order that matches the physics is: display pipeline first (refresh rate, V-Sync off, game mode), engine/frame-queue second (FPS cap just under refresh, low-latency modes), mouse last (1000Hz polling, sane debounce, wired or 2.4GHz — see wireless vs wired). And if you want to see what one of these hops looks like in isolation, the tester reports the in-browser delivery delay honestly — the one slice of the chain a page can actually touch.
Frequently asked questions
How much input lag does a mouse add?
The mouse itself contributes roughly 2–10ms before the signal even reaches the OS: switch actuation ~1–2ms, firmware debounce ~2–16ms depending on settings, then up to one polling interval (~0.5–8ms depending on rate). The rest of the felt lag — often 20–60ms total — is mostly downstream: engine sampling, frame rendering, and the display.
What is the biggest source of input lag?
Almost always the display pipeline, not the mouse: frame render time, the compositor queue, and the monitor's own processing together dwarf the few milliseconds in the click path. That's why 'low input lag' setups are built around refresh rate, V-Sync off, and game-mode displays — not exotic mice.
Does debounce time add input lag?
Yes, by design — debounce is deliberate delay: the firmware waits a few milliseconds for switch contacts to stop bouncing so one press doesn't register as several. Typical firmware debounce runs ~4–16ms; some mice let you set it to 0 at the risk of double-clicks. The trade-off and the fault it guards against are in the debounce guide.
Can a browser measure my input lag?
Only the last hop of it — how long an event takes to reach the page's handler, which is what our tester reports as 'delivery delay'. Everything upstream (switch, debounce, USB, OS, compositor) is invisible to JavaScript. Measuring the full chain needs a hardware rig or a high-speed camera.