How Much Click Latency Does a Wireless Link Actually Add

There are two ways to answer the wireless question. One is to repeat the number printed on the box, which usually claims a one millisecond connection and stops there. The other is to wire a photodiode to the switch, capture the USB traffic, film the screen at a high frame rate, and measure where the delay actually lands. The first answer takes five seconds and sounds reassuring. The second takes an afternoon and produces a number that rarely matches the box.

We took the second route on three wireless boards, because the interesting part is not the total but the breakdown. A wireless keypress travels through the switch, the matrix scan, the firmware debounce, the radio link, the dongle, and then the host stack, and each stage contributes its own slice. Knowing which slice is large tells you what to change and what to leave alone.

What exactly are we measuring when we say click latency?

Click latency is the gap between the moment the key physically actuates and the moment the host has the event. That is not the same as the moment the screen changes, which adds the render and the panel on top. Mixing the two is the most common reason two sites publish wildly different numbers for the same board, so we separate them and record each one.

Our rig triggers a light sensor at actuation, logs the USB report, and captures the display separately. That gives three timestamps per press, and repeating the press enough times gives a distribution rather than a single figure. A single number hides jitter, and jitter is what a player actually feels.

Where does the delay come from before the radio is involved?

Most of it, surprisingly. The matrix scan alone can cost a full polling interval, and the debounce that prevents double presses adds its own fixed window. On one board the switch and scan stages together took longer than everything downstream combined, which means the radio was never the bottleneck on that unit.

Debounce is the part worth understanding. Firmware waits a few milliseconds after a press to confirm the contact has settled, and that wait is pure added latency. Some boards let you shorten it, and on the units we measured, shortening it shaved more from the total than switching from wireless to wired would have.

How much does the 2.4 GHz link itself add?

Less than the marketing implies and more than zero. Across our samples the radio stage sat in a band that is easy to feel in a slow-motion capture and hard to feel in normal typing. The spread between the best and worst unit was wider than the difference between wireless and wired on the same board, which tells you the implementation matters more than the medium.

The dongle matters too. A receiver plugged into a hub behind a monitor adds its own delay and its own jitter, while the same receiver in a direct port behaves better. We logged both placements on every board, and the hub placement was consistently worse, sometimes by enough to erase the advantage of a good radio.

Does polling rate change the answer?

It changes the scan slice more than the radio slice. Raising the report rate shortens the average wait between a press and the next report, which pulls the whole distribution down and tightens it. The effect is real but it shrinks quickly; going from a slow rate to a moderate one helps, and going from moderate to the maximum helps much less.

The tightening is arguably more valuable than the average. A board that averages well but occasionally produces a long outlier feels inconsistent in a way that a slower but steadier board does not. When we ranked boards by worst-case rather than average, the order changed.

What happens when the air is busy?

Congestion shows up as outliers rather than a uniform shift. A crowded room with several radios, a busy access point nearby, and a phone on the desk all produced occasional long presses in our logs, even when the average stayed flat. That pattern is the signature of retransmission, and it is the reason wireless measurements need to be repeated rather than sampled once.

Distance does something similar but steadier. Moving the receiver further away raised the average and widened the spread at the same time. Keeping the dongle within a short line of sight of the board was the single most reliable improvement we found, and it costs nothing.

Is Bluetooth ever competitive here?

For typing, yes, and for anything timing sensitive, no. The Bluetooth units we logged sat clearly behind their 2.4 GHz siblings on every press, with a wider spread and more outliers. The gap was large enough that no amount of tuning on the host side closed it, because the delay is in the protocol stack rather than in the keyboard.

That said, the Bluetooth numbers were still perfectly usable for office work, and the convenience of not carrying a dongle is real. The honest framing is not that Bluetooth is bad, but that it answers a different question than the one a competitive player is asking.

How should you read a vendor latency claim?

Ask what interval the claim covers. A figure that starts after the debounce and ends at the dongle is a different measurement from one that starts at the switch and ends at the host, and both can be technically true while differing by several milliseconds. If the vendor does not say where the clock starts, the number cannot be compared with anything.

Ask also whether it is an average or a worst case. Averages sell boards; worst cases win rounds. Our logs for the same board supported both a flattering average and a less flattering tail, and the tail is what a player remembers.

What is worth changing and what is worth ignoring?

Change the things that move a large slice: shorten debounce where firmware allows, plug the receiver into a direct port, keep it close, and raise the polling rate from a low default to a moderate one. Ignore the things that move a small slice: chasing the last fraction of a millisecond on the radio stage will not show up in your hands.

How much of the total sits outside the keyboard?

Once the keypress reaches the host, the operating system queues it, the application reads it, the renderer draws a frame, and the panel displays it. In our logs that second half of the chain was often longer than the first half, which means a keyboard upgrade can only ever address part of what a player feels.

This is worth stating plainly because it sets expectations. If the display path contributes the largest slice, then the fastest available keyboard changes less than a modest change to refresh rate or frame pacing. Measuring the whole chain before buying is the only way to know where your own delay lives.

Does battery level change the radio behaviour?

It can. Several units reduced transmit power or changed reporting behaviour as the cell drained, and the effect appeared as a slightly wider spread rather than a slower average. We caught it by logging the same board at full charge and again near empty, which is a test almost nobody runs.

The practical advice is to treat a low battery as a measurement condition, not just a convenience issue. If a board feels inconsistent and the cell is nearly flat, charge it and re-test before concluding anything about the hardware.

What is the cheapest improvement available?

Moving the receiver. A dongle in a front port with clear line of sight beat a dongle behind a monitor in every case we measured, and the improvement cost nothing. The second cheapest improvement was shortening debounce, where firmware allowed it, and that also cost nothing.

The expensive improvements ranked last. Replacing a perfectly good wireless board with a wired one produced a smaller change than either of the free fixes on most of our samples, which is a useful thing to know before spending money.

Does weather or interference move the radio stage?

It can, though the effect is smaller than most people assume. A busy room adds occasional retransmissions, which appear as outliers rather than as a slower average. Logging the same board in a quiet space and again in a crowded one showed the tail widening while the centre stayed where it was.

Physical obstructions matter slightly more. A metal desk surface between the board and the dongle reduced the margin enough to produce a few long presses, and lifting the dongle cleared them. That is the same placement lesson that applies to every wireless device on a desk.

What is the simplest way to repeat this at home?

A light sensor taped next to a switch, a recording of the screen, and a lot of presses. Comparing frames between the flash and the pixel change gives a usable figure, and repeating it enough times gives a distribution. The absolute number will not match a laboratory, and the comparison between two boards will be sound.

Keep the conditions identical between boards: same port, same day, same host, same number of presses. Those controls matter more than the precision of the capture, because the differences between boards are smaller than the variation introduced by changing anything else.

The remainder of the delay lives outside the keyboard entirely, in the host and the display. Once the wireless stage is under control, the next large number in the chain is the monitor, and that is where the following measurement should go.