Why Browser Tests Can't Measure Hardware Latency

Published 15 August 2026 · Last updated 15 August 2026

No web page can measure how long your keyboard takes to respond. A browser's first knowledge of a keystroke arrives after the switch has closed, after the firmware has scanned and debounced it, after the report has crossed USB or radio, and after the operating system has processed and routed it. By then the interesting part is over, and nothing that survives that journey carries a record of how long it took.

Any site claiming to have measured your keyboard's hardware response in a browser tab is either using the words loosely or is wrong. This page sets out exactly where the blind spot begins, what would be required to see into it, and what the browser measurement genuinely tells you — because it does tell you something worth knowing.

The chain, stage by stage

The dividing line is sharp. Everything above the browser row happens in other processes, other chips and other machines' worth of code. JavaScript is handed a finished object and no provenance.

There is no hardware timestamp on the event

This is the crux, and it is worth stating on its own. A KeyboardEvent exposes which key it was, where it sits on the board, which modifiers were held, whether it was an auto-repeat, and when the browser created it. There is no field describing when the switch closed, when the firmware built the report, or when the operating system received it.

Without an origin time, no arithmetic can recover the elapsed time. You cannot subtract a number you do not have. A browser measurement necessarily starts its stopwatch at the browser, which means the entire hardware contribution is a constant offset the page cannot see and cannot estimate.

Even the browser's own clock is deliberately blunted

High-resolution timers in a browser are a side channel, and after the Spectre class of attacks every engine reduced their precision. The exact treatment varies: some engines clamp to the order of a tenth of a millisecond, others to a full millisecond unless the page is cross-origin isolated, and some add jitter on top. The details change between versions.

The consequence is fixed, though. If your browser can only express time in 1 ms steps, then any difference smaller than a millisecond is invisible to it — and most of the hardware stages people care about live in exactly that range. Every measurement page here probes the clock empirically and prints what it found, so you can see whether the numbers on screen have the resolution to mean anything. The methodology page explains the probe.

Queueing, scheduling and coalescing blur the rest

Browsers do not hand input to a page the instant it arrives. Events become tasks on the page's main thread and wait their turn behind whatever is already running. Continuous input such as pointer movement is additionally merged and aligned to the rendering cycle, so multiple raw reports can arrive as one event.

Key presses are discrete and are not merged the way pointer moves are, but they share the same queue and the same scheduler. If the machine is busy, or the tab is throttled, or the compositor is behind, the browser's own timing shifts. That noise sits on top of a hardware contribution you already could not see.

What about WebHID or WebUSB?

A reasonable question, since those APIs can talk to devices directly. They do not solve this. Browsers block access to devices that present standard keyboard usage — precisely so that a web page cannot turn itself into a keylogger — so an ordinary keyboard is not available to a page through them at all.

And even if it were, it would not help much. You would see the report arrive at the host, which is already downstream of actuation, scanning, debounce and transport. The interesting latency is upstream of any timestamp software can take.

What a real measurement rig looks like

Measuring hardware latency properly means putting an instrument on both ends of the chain and timing between them, with no software in the loop on the reference side. The common approaches:

• Instrumented switch. A wire is tapped onto the switch contact and fed to a microcontroller or logic analyser, which timestamps the exact moment of closure. The same instrument watches the USB line or the host, giving keyboard-only latency.
• Mechanical actuator plus USB capture. A solenoid or servo presses the key while a protocol analyser records when the corresponding report appears on the bus. This isolates the keyboard and its transport without touching the host software.
• High-speed camera. A camera recording at a thousand frames per second or more captures both the key moving and the screen changing. Frame counting gives an end-to-end figure, and the frame rate sets the resolution: 1000 fps means 1 ms per frame, so a single frame of ambiguity is a millisecond of error.
• Photodiode on the display. A light sensor taped to the monitor detects the pixel change and is timed against the switch trigger, which measures the whole click-to-photon path including the display.

Each of these needs physical access to the keyboard, hardware that costs real money, and a controlled setup. None of them can run in a browser tab, and any of them can be undermined by sloppy method — which is why serious rigs report their instrument's resolution alongside their results, the same way this site reports the browser clock's resolution alongside yours.

So what is the browser measurement good for?

Quite a lot, as long as you read it as what it is: a measurement of the software path between event creation and your JavaScript, on this machine, in this browser, right now.

Comparing sessions on the same machine

Holding the browser, the machine and the conditions constant makes the number a fair relative measure. Run a session, change one thing — close a heavy tab, disable an extension, switch power plan, unplug the dock — and run again. The session comparison tool puts two runs side by side so you compare medians and spread rather than remembering a single number.

Spotting inconsistency

Spread is often more informative than the average. A tight distribution means the input path is being serviced promptly and predictably. A long tail — a 95th percentile several times the median — points at contention: background work, thermal throttling, a virtual machine, or a remote desktop session batching input.

Detecting chatter and duplicate events

Chatter is a switch producing more than one registered press from one physical press, and it shows up as duplicate key events separated by an implausibly short interval. That pattern is fully visible from JavaScript, because it is a pattern in the events themselves rather than a duration inside the hardware. The chatter test flags it as a possible pattern, with the timings, and leaves the diagnosis to you.

Checking rollover and simultaneous key handling

How many keys register at once, and which combinations get lost, is again a question about which events arrive. The rollover test and the ghosting test report what your browser registered, which is influenced by the keyboard, the transport mode and the OS — a browser-observed result, not a hardware specification.

Diagnosing software-side input problems

If typing feels laggy, the cause is far more often software than switches. Remapping utilities, security software hooking input, an overloaded main thread, a virtual machine, a remote session, or a browser extension running on every keystroke will all show up in browser-observed timing. A keyboard that measures the same in a clean browser profile as it did in your normal one has just ruled out an entire class of suspects.

How to read your result honestly

Treat the number as a floor and a fingerprint, not a specification. It tells you the browser input path on this system was at least this slow, and it gives you a repeatable value to compare against. It does not tell you which keyboard to buy, and it cannot be compared against someone else's browser on someone else's machine — see why results vary between systems for the list of reasons.

If you want the mechanics of what is being timed, read browser keyboard event timing explained. When you are ready to collect samples, the keyboard latency test reports the median, percentiles, jitter and consistency with every excluded sample accounted for.