Input lag is the delay between your hand moving and the screen reacting — the gap between a click and the muzzle flash. It's invisible until you feel it, and then it's the difference between winning a duel and swearing at your monitor. The frustrating part is that it isn't one number you can turn down; it's a chain of small delays, each adding a few milliseconds, stacked from the moment you move the mouse to the instant a photon hits your eye. Fix the wrong link and you get nothing. This guide walks the whole chain in milliseconds, shows you where the real time is hiding, and lists the changes that actually move the needle — then hands you a calculator to budget your own latency.
Here's the journey of a single mouse movement, stage by stage, with rough time contributions on a decent gaming setup:
| Stage | What happens | Typical ms |
|---|---|---|
| Peripheral polling | Mouse reports its position; you wait up to one polling interval | 1–8 ms |
| USB & OS | Signal travels the bus and through the input stack | ~1 ms |
| Game engine | Input is sampled, game state simulated | 1–8 ms |
| Render queue | Frames buffered ahead of the GPU (the big hidden one) | 0–40 ms |
| GPU render | The frame is actually drawn | 3–16 ms |
| Display scanout | Frame is sent to the panel; ~half a frame on average | 2–8 ms |
| Pixel response | The liquid crystal physically changes color | 1–10 ms |
Notice which stage has the widest range: the render queue. It's where a badly configured system hemorrhages latency, and it's the one most people have never heard of.
To keep the GPU fed and the frame rate smooth, the CPU can queue up several frames' worth of work in advance. That buffering is great for average FPS but terrible for latency: an input you make now might not be reflected until the GPU chews through the frames already waiting in line. If three frames are queued at 60 FPS, that's ~50 ms of pure delay before your action even reaches the screen.
The fix is to shorten or bypass that queue. Low-latency modes do exactly this — they cap the number of pre-rendered frames and dynamically pace the CPU so it submits work "just in time" instead of racing ahead.
The single biggest win: when your GPU is at 100% usage, the render queue fills and latency balloons. Cap your FPS a few frames below your max (or below your refresh rate) with a frame limiter so the GPU never fully saturates — this alone can strip 20–40 ms off your total.
People conflate these. Refresh rate (Hz) is how often the panel draws a new image — it sets the scanout portion of your budget and the freshness of what you see. Response time (ms) is how fast an individual pixel physically changes shade — it causes smearing and ghosting, and adds its own tail of delay. You want both good: high refresh for fresh frames, low response for clean transitions. A deeper walk-through lives in our refresh rate guide.
The calculator below sums the main stages of your chain into an estimated total, with a per-stage breakdown so you can see where your milliseconds are going. Pick your refresh rate, panel response, and mouse polling, and toggle whether you run a frame limiter. Numbers are reasonable approximations, not lab measurements.
The bottom line: input lag is a stack of small delays, and the largest, most controllable one is the render queue. Cap your FPS below your max, turn on a low-latency/Reflex mode, drop plain VSync in favor of VRR, and run a high-refresh panel with fast pixel response and a 1000 Hz wired mouse. Do those five things and you've cut the fat from every link in the chain — the rest is single-digit milliseconds that only the very top of the ladder will ever feel.