Keyboard Latency vs Response Time

Latency has one meaning: the elapsed time between a cause and its effect, with both ends named. Response time has at least three, depending on who is speaking. Switch makers use it for how a key behaves mechanically. Reviewers use it for the whole path from keypress to lit pixel. Monitor makers use it for how fast a pixel changes shade.

Those three numbers describe different segments of the chain, are produced by different instruments, and cannot be compared, added, or substituted for one another.

Sense 1: switch response time

On a keyboard or switch specification, "response time" usually refers to how quickly a key press becomes an accepted state change inside the keyboard itself. Two things drive it: actuation and debounce.

Actuation is the point in the key's travel at which the switch registers, commonly quoted somewhere in the region of one to two millimetres of a total travel of around three to four millimetres, and adjustable on some analogue and magnetic switches. Note what this is: a distance, not a time. How long it takes you to push the key that far depends on how hard and how fast you press, so a shallower actuation point shortens a delay that belongs partly to your finger.

Debounce is a time. Metal contacts chatter for a short interval as they close, so firmware applies a settling window before accepting the change. Typical windows are in the low single-digit milliseconds. The implementation matters more than the number: firmware that reports on the first edge and then ignores further changes for the window costs almost nothing, while firmware that waits for a stable signal across the whole window costs the full window on every press.

This is also the sense behind marketing claims for optical and Hall-effect switches, which sense position without a bouncing metal contact and so can shorten or restructure the debounce stage. Those claims are about this one stage — they say nothing about the polling, operating system, application or display stages that follow.

Sense 2: system response time (input-to-photon)

When a reviewer measures "response time" with a high-speed camera pointed at a screen and a keyboard rigged to trigger, they mean the whole chain: switch contact → matrix scan → firmware → USB or Bluetooth transport → operating system input stack → application → GPU → display. This is the number that corresponds to what you actually feel, and it is the sense that deserves the word "latency".

It is also the largest number by far, because it includes terms that dwarf the keyboard's own. A frame on a 60 Hz display is 16.7 ms; at 144 Hz it is 6.9 ms and at 240 Hz it is 4.2 ms. A single frame of application or compositor buffering therefore costs more than the entire polling stage, which at 1000 Hz averages about 0.5 ms. If you are comparing a 3 ms keyboard difference on a 60 Hz display, one frame of buffering can hide it completely.

Measuring this properly needs hardware: a light sensor on the display, a switch closure you can timestamp, and a way to correlate the two outside the computer under test. That is why it is a reviewer's measurement, not a website's. The reasons a browser cannot substitute for that rig are worth reading if you are tempted to trust an online number that claims otherwise.

Sense 3: display response time

On a monitor box, "1 ms response time" describes how long a pixel takes to change from one shade to another, usually quoted grey-to-grey (GtG) and sometimes as MPRT, which is a motion-blur figure rather than a transition figure. Vendor numbers tend to be best-case transitions at aggressive overdrive settings; independent measurement commonly finds higher averages across the full range of shade transitions.

The critical point for this guide: pixel transition time is not display input lag. Input lag is the separate delay between a frame arriving at the display and the panel beginning to act on it, caused by scaling, image processing and buffering. A display can transition pixels very quickly and still add a substantial processing delay before it starts. Both belong in the end-to-end sum; they are different rows.

Which one this site measures

A slice of sense 2, and only a slice. This site runs in a web browser, so it can see keyboard events only after the operating system has delivered them. What it measures is the browser-side segment:

• Browser input event latency — the time between the browser creating the keyboard event and our JavaScript handler running. This captures event queuing and main-thread scheduling delay.
• Input-to-frame time (browser-side) — the same start point, measured instead to the next animation frame, which adds the browser's own rendering step.

Both are real, reproducible and honestly bounded. Neither is the switch sense, neither is the display sense, and neither is the full end-to-end sense. You can run them on the browser input latency test on the homepage, and the exact formulas, sample validation rules and timer-resolution limits are written out on the methodology page.

How to tell which sense someone is using

You rarely get a definition, but you can almost always infer one from context.

The single most useful question is: from what event, to what event? Any response time that cannot answer that in one sentence is marketing, not measurement. A figure with named endpoints can be checked, added to other stages, and argued with. A figure without them cannot.

Putting the senses back together

Because each sense covers a different segment, they combine rather than compete. A rough end-to-end estimate is the sum of a switch and firmware term, a transport term, an operating system term, an application term and a display term — and the last two are usually the largest.

The latency calculator lets you enter your own figure for each stage and see the total, with every input clearly labelled as your estimate rather than a measurement. If you want to see how small the transport term really is once you are at 1000 Hz, the companion guide on latency versus polling rate works through that arithmetic, and what counts as a good latency covers what the totals actually mean in use.