How to Reduce Keyboard Input Lag

Most of the delay between pressing a key and seeing something happen is not created by the keyboard. On a typical desktop the switch, the firmware and the USB link together account for a few milliseconds; the display, the graphics pipeline and the application usually account for considerably more. Fix them in that order.

The list below is ordered by expected impact, not by how easy each item is to change. Change one thing at a time and re-measure in between, or you will never know which change did anything.

1. Raise your display refresh rate

Usually the biggest number in the chain, and the one people skip because it is not a keyboard setting. A display draws frames at a fixed cadence; your keystroke lands at an arbitrary point in it and waits half a frame on average before the frame that could show it even begins.

Going from 60 Hz to 144 Hz removes roughly 5 ms of average waiting, and removes it again at every buffered stage, so the felt difference is larger than the table suggests. Plenty of people own a high-refresh panel running at 60 Hz because a cable, a driver default or a dock set it there — check your display settings, and if the high rate is not offered, suspect the cable or the port before the monitor.

2. Stop frames from queueing in games

VSync makes an application wait for the display's next refresh before presenting a frame, costing up to a full frame. Drivers and engines may also prepare several frames ahead, adding one frame interval each. At 60 Hz that combination can reach 30–50 ms, dwarfing anything the keyboard does.

Cap your frame rate slightly below your refresh rate instead of running into the VSync wall, enable the driver's low-latency or anti-lag option to limit how many frames are queued ahead, and prefer variable refresh rate over plain VSync. A browser cannot see a game's render queue, so verify this one with the game's own latency readout or a driver overlay.

3. Choose the connection type deliberately

Wired is the most predictable rather than automatically the fastest. What matters is how often the device is allowed to report, and how much power saving it does between reports.

If your board has a wired mode, plugging it in is the cheapest experiment on this page. With Bluetooth, the variability is often what you feel — the occasional slow keystroke rather than a uniform delay.

4. Set polling rate once, then stop thinking about it

Polling rate is how often the host asks the keyboard for a report. The interval is 1000 / rate milliseconds, and a keystroke landing at a random point inside it waits half of it on average.

At 125 Hz the interval is 8 ms, so a keystroke waits 4 ms on average and 8 ms at worst. At 1000 Hz those figures become 1 ms, 0.5 ms and 1 ms; at 8000 Hz, 0.125 ms and about 0.06 ms.

So 125 Hz to 1000 Hz saves about 3.5 ms on average and is worth doing. 1000 Hz to 8000 Hz saves at most about 0.44 ms — roughly one twentieth of a 60 Hz frame — while measurably raising CPU interrupt load. The polling rate calculator works this out for any rate.

One caution: the event cadence test reports how often your browser receives keyboard events. That is not a USB polling rate and cannot confirm one — see polling rate vs browser event cadence.

5. Take hubs, KVMs and docks out of the path

A plain powered hub normally costs little. Be suspicious of anything that does not simply pass reports along: KVM switches, some laptop docks and monitors with built-in USB switching often emulate a keyboard on the host side and re-package the reports. That adds delay, and more importantly it adds delay that varies. Test by plugging the keyboard straight into the computer — a rear motherboard port on a desktop — and re-running your baseline.

6. Cut background CPU load and fix power profiles

This is what the tests here measure most directly: the flagship measurement is the gap between the browser creating a keyboard event and your page's JavaScript receiving it, and anything competing for the CPU stretches that gap.

• Pause antivirus scans, search indexing, sync clients and build jobs while you test, and look for a single runaway browser tab.
• On a laptop, check whether you are on battery. Power saving lowers clocks and raises scheduling latency, and USB selective suspend delays the first press after an idle period.
• Thermal throttling produces bursty lag rather than constant lag.

Verify: measure under load and again idle, watching the 95th percentile and jitter rather than the median. Contention shows in the tail long before it moves the middle.

7. Turn off Filter Keys, Sticky Keys and Slow Keys

These accessibility features deliberately change key timing, and they are easy to enable by accident — Windows offers Filter Keys after holding right Shift for several seconds, and Sticky Keys after five presses of Shift. Filter Keys ignores brief or rapidly repeated keystrokes and can require a key to be held before it is accepted; macOS Slow Keys does the same. If keys need a deliberate, firm press, check these first, and use the event tester to see whether a press produces an event at all.

8. Audit remapping, macro and vendor software

On Windows, low-level keyboard hooks are delivered synchronously: the system passes the keystroke to each installed hook and waits for it to return, up to a timeout. A hook that is slow to return delays that keystroke for everything downstream. Common occupants are remappers and AutoHotkey scripts, vendor and RGB suites, overlays, game launchers, screen recorders and some security software; on macOS, utilities granted Accessibility permissions. Close them one at a time, measure after each, and note which removal actually moved the number.

9. Browser extensions and page scripts

If typing feels slow only in a browser, extensions are the first suspects: grammar checkers, password managers, clippers, translators and heavily configured content blockers all attach handlers that run on your keystrokes. Open a private window with extensions disabled and re-run the latency test; if the median drops, re-enable them one at a time. A badly written script on the page you are typing into produces the same symptom — browser keyboard event timing explains why.

10. Remote desktop, virtual machines and cloud gaming

A different category of problem: your keystroke crosses a network, the remote machine renders, and the pixels come back encoded. You pay a full round trip plus encode and decode buffering, typically tens to hundreds of milliseconds. A wired network connection, a lower resolution and a closer server help. A faster keyboard does not.

11. Wireless interference and receiver placement

The 2.4 GHz band is shared with Wi-Fi, Bluetooth and wireless headsets, and USB 3 ports, cables and drive enclosures are well documented sources of broadband noise around 2.4 GHz — which is why a receiver plugged in beside one can behave badly.

Move the receiver to a front port, or onto a short extension cable that puts it on the desk with line of sight to the keyboard, and keep it away from USB 3 ports, external drives and the back of the monitor. The tell-tale symptom is lag that is intermittent and position-dependent: fine at one spot on the desk, poor at another.

12. Firmware and debounce, on boards that expose them

Mechanical contacts bounce briefly when they close, so firmware waits out a debounce window before declaring a press. That window is genuinely part of the keyboard's own delay, and boards running open firmware or a capable vendor tool let you shorten it — around 5 ms down to 2–3 ms is a small but real saving.

The trade-off is direct: set it too low and one press starts producing two events. After any debounce change, run the chatter test; if duplicate events appear, raise the value back. Hall-effect and optical boards instead expose actuation point and rapid trigger, which change how far your finger travels rather than the electronics.

Things that do not help

This is where most keyboard lag advice goes wrong. None of the following measurably reduces input lag on a working system.

Which of these changes can this site verify?

The tests here run in a browser and only see keyboard events after the operating system has delivered them. They measure the browser input pipeline, not keyboard hardware, so some fixes above are confirmable here and some are not.

If you still cannot tell what is wrong, work through why your keyboard feels slow or laggy, which is organised by symptom rather than by fix, or run the combined keyboard performance test.