Two gaming keyboard latency figures are worth comparing only when they measure the same interval, report the same kind of metric, and use similar stated test conditions. A number in milliseconds tells you how long something took. It does not tell you where the clock started or where it stopped.
If a method leaves out its start event, its stop event, or a key setting, the comparison is unclear. In that case the numbers cannot support a ranking, no matter how far apart they look.
Compare the Measured Interval, Not the Headline Number
Your job is not to find the fastest keyboard on a spec sheet, but to decide whether two claims answer the same question. A shared unit does not settle that. Two results can both read in milliseconds while one covers only part of the input path and the other covers a longer chain ending at a later event.
To compare gaming keyboard latency claims fairly, work in a fixed order. First, record each method's stated start and stop events. Next, check which metric each figure reports and how it was summarized. Then note the test conditions the method discloses, such as connection mode or settings. Only after those checks should you decide how the two numbers relate.
Treat every missing detail as unknown. An unstated stop event does not mean a test matches another one. It means you cannot tell. Matching methods won't make two results identical, but they do give you a fair basis for comparison.
Trace Each Test's Start and End Events
Every latency figure is a stopwatch reading between two events, and the method should name both. Keep the start event, the stop event, and the included stages as separate notes so a gap in one can't hide behind the others.
Record the Starting Event
Write down the start event exactly as the test describes it. Use words like "switch activation" or "beginning of the keypress" only when the method itself names that event. Different starting points measure different intervals, even on the same keyboard.
One camera-based test shows why this matters. It starts timing at the beginning of the keypress rather than at switch activation, and its author notes that another measurement he found online started at switch activation instead. The same author reports using a 240-fps camera, so frames are 4 ms apart. That frame spacing is part of the result, because the camera can only place each event within one of those 4 ms frames.
Find the Stopping Event and Included Stages
Next, record where the clock stops and which stages the method says it covers or leaves out. Possible stages include key detection, keyboard processing and reporting, the host or game response, and the change on screen. Not every test includes all of them, so check each one against the method text.
The LagBox method for USB-connected devices is a clear example of a named stop event. Its timer starts when the button makes an electrical connection. It stops when the resulting input event is read through the Linux kernel's device interface. That endpoint is an operating-system input event, not a game frame or a screen change. The method also does not read USB traffic directly, and the described setup required physically modifying the device.
Keep a short note for each claim:
- Start event: the event the method names
- Stop event: the event the method names, or "unknown"
- Included or excluded stages: only what the method states
- Unknowns: anything you would otherwise have to guess
If the stop event is missing, mark it unknown and treat the interval as incomplete. Don't assume a test ends at the game or the screen just because it starts at the key.
Check the Metric, Conditions, and Polling-Rate Claim
A polling rate and a latency result are different kinds of information, so one can't stand in for the other. Run these checks after you have traced the endpoints.
- Name the metric. Record what each figure reports and how the method summarizes it, such as one run or a summary across many presses. A shared unit does not mean a shared metric. If you can't tell how a number was summarized, mark it unknown.
- Compare like with like. Put two gaming keyboard latency figures side by side only when they describe the same kind of metric. A single best-case run and a summary of many presses answer different questions.
- Record the stated conditions. Note connection mode, settings, and firmware only when the source names them. Connection type is one condition worth matching, and our guide to wired versus wireless latency explains those tradeoffs. On boards with adjustable actuation distance, the setting used during the test is another condition to write down when the method states it.
- Separate polling rate from latency. The USB HID specification describes input reports sent at the polling rate through the Interrupt In pipe. That describes how often a USB HID device sends reports. It does not state the time from a physical key press to a later host, game, or screen response, so a polling-rate figure is not a measured latency interval.
- Note debounce only when the method names the firmware. Debounce is how firmware filters the electrical bounce of a switch. QMK's documented debounce options include "eager," which reports a key change immediately, and "defer," which waits for no changes during the configured debounce interval before reporting. This applies to QMK only, so record it when a test identifies QMK and which option it used. For more on how this setting differs from actuation, see our guide to keyboard debounce behavior.
Classify the Comparison and Choose Your Next Step
Once your notes are complete, give each pair of claims one of three labels. Base the label on what the methods actually document, never on a stage you guessed.
| Label | What the stated methods show | Your next step |
|---|---|---|
| Comparable | Same start and stop events, same metric, similar stated conditions | Compare the figures and note any minor condition differences |
| Not directly comparable | A known difference in endpoints, metric, or conditions | Skip the ranking; look for both keyboards in one test |
| Unclear | A decisive method detail is missing | Find the full methodology or use same-test results |
A "not directly comparable" label is not a verdict on either keyboard. It only means the two numbers answer different questions. Results from the same test, run the same way, give you the strongest basis for a side-by-side view.
The same labels work when you scan spec sheets across magnetic switch keyboards or any other category. Latency is also just one line in a broader gaming keyboard features checklist, alongside layout, comfort, and software.
FAQs
Why does a camera's frame rate matter in a latency test?
A camera can only show what happened in each frame. At 240 fps, frames are 4 ms apart, so any two events that fall within the same frame look like they happened at once. When a camera-based result is close to another figure, check the frame rate before reading much into the gap.
Is a manufacturer's latency number less useful than a reviewer's?
The source alone doesn't decide that. What matters is whether the claim names its start event, stop event, metric, and conditions. A manufacturer figure with a full method can be easier to compare than a review figure with none, and the reverse is also true.
Does a longer debounce setting always add the same delay?
No single rule covers every keyboard. In QMK, the eager option reports a change right away and then ignores further changes for the debounce period, while the defer option waits out that period before reporting. The same debounce number can affect reporting differently depending on which option the firmware uses, so check the algorithm as well as the value.
