1. Layer 1: Switch Actuation & Contact Debounce
The keyboard's firmware scans its key matrix typically every 1ms. After detecting a state change, it applies a debounce filter (5–20ms) before sending a USB HID report. A switch with worn contacts may require multiple scan cycles before producing a stable signal, adding 5–15ms of latency before the host even knows you pressed a key.
2. Layer 2: USB Connection Type & Polling Rate
Standard USB keyboards report key events to the host at 125Hz (every 8ms). This means your OS can only learn about a keypress at the next polling interval — introducing up to 8ms of inherent latency even on a perfect switch. Gaming keyboards at 1000Hz poll every 1ms, and newer 8000Hz keyboards poll every 0.125ms.
| Connection Type | Poll Interval | Max Added Latency | Typical Total Latency |
|---|---|---|---|
| USB 2.0 Full-Speed (125Hz) | 8ms | 8ms | 10–18ms |
| USB 2.0 Gaming (1000Hz) | 1ms | 1ms | 2–5ms |
| Bluetooth (BT Classic) | 7.5–45ms | 45ms | 15–80ms |
| 2.4GHz RF Dongle (typical) | 1–8ms | 8ms | 2–10ms |
3. Layer 3: USB Power Saving (Windows USB Selective Suspend)
Windows automatically suspends USB devices when they appear idle to save power. When you resume typing after a brief pause, the OS must wake the USB device, adding a 20–200ms spike on the first keypress. This is often misidentified as intermittent "lag" or "delay when starting to type."
4. Layer 4: Windows Filter Keys / Slow Keys (Accessibility Features)
Windows Filter Keys is an accessibility feature that tells the OS to ignore brief keypresses or slow down repeat rates. If accidentally enabled, it will add a deliberate delay (default 500ms) before registering any keypress. Many users mistake this for hardware lag.
5. Layer 5: 2.4GHz Wireless Interference
Wi-Fi routers, nearby Bluetooth devices, microwave ovens, and baby monitors all compete in the 2.4GHz band. For wireless keyboards, interference causes the RF receiver to request retransmission of missed packets, adding variable latency spikes of 10–60ms per retry.
6. Layer 6: GPU Render Queue & Display Latency
Even after the OS receives the keypress event, visual feedback (the character appearing on screen) depends on the GPU render pipeline. With GPU pre-render queues (flip queues) set to 3 frames and a 60Hz monitor, you can add up to 50ms of display latency on top of the input latency. You type, the OS responds instantly, but the character doesn't appear for another 50ms.
7. Layer 7: Browser-Specific Event Queue
Our keyboard latency test measures the time between your physical keypress and the browser's keydown event. Browsers process keyboard events in the main JavaScript thread. If the tab is under heavy CPU load (complex animations, heavy scripts), keydown events can be delayed by 10–30ms relative to the actual keypress.
What This Test Result Does Not Prove
Understanding the limits of browser-based latency measurement:
- JavaScript timer resolution:
performance.now()has 1ms resolution on most browsers (reduced from microseconds for security). Sub-millisecond differences between keyboards cannot be reliably measured. - System jitter: OS scheduler interrupts, antivirus scans, and background services cause random latency spikes of 1–5ms that are unrelated to keyboard hardware.
- Display latency not measured: This tool measures the time to the browser event, not the time until a character appears on screen. GPU and display latency require specialized hardware (FPGA or high-speed camera) to measure.
Conclusion
Most keyboard lag is not caused by the keyboard itself — it's caused by USB selective suspend, wireless interference, Windows accessibility features, or GPU render queues. Run through this checklist layer by layer, re-testing with our keyboard latency test after each change, and you will identify the bottleneck within 15 minutes. For related hardware diagnostics, see our guide on detecting switch chattering and keyboard ghosting and NKRO.