Device diagnostics research

The Measurement Floor in Browser Input Lag Testing

Input lag measurement in a browser is bounded twice over. The device delivers input events at a protocol rate, and the page observes them at a scheduling rate. Whichever is slower sets the floor below which the measurement cannot distinguish a real value from zero. Our evidence file records both sides so a test can state its resolution honestly.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

A page reports an input lag figure. Below what value can that figure not be trusted?

This research explains the sampling floor that bounds browser input-lag measurement, using derived protocol and scheduling constants. It does not report a measured lag value for any device and does not benchmark any product.

Try it on the anchor product: BeanNest Tools /device/.

The reporting side: display refresh

A measurement that samples with animation callbacks can only observe states at the display refresh rate. At 60 Hz that is one observation every 16.67 milliseconds, and at 144 Hz it is one every 6.94 milliseconds. A reported lag smaller than one observation period is not separable from zero by this method.

The delivery side: device polling

Devices report at protocol intervals that vary enormously. Our evidence file records USB low-speed at 10 milliseconds, full-speed and typical gaming mice at 1 millisecond, Bluetooth Classic at roughly 11.25 milliseconds, and Bluetooth low energy at a 7.5 millisecond floor. A device that reports every 10 milliseconds cannot be observed faster than that.

Why the slower side wins

The observable resolution is the coarser of the two rates. Comparing a 1000 Hz mouse against a 60 Hz display sampling path measures the display path, not the mouse. This is why so many published browser lag numbers cluster around the refresh period: the measurement is revealing its own floor.

Timer precision adds a smaller bound

Modern browsers clamp high-resolution timestamps, and event timestamps may use a different epoch than the performance clock. That adds a small uncertainty on top of the sampling floor. Our evidence file records both limits so a reported figure can account for them.

Coalesced events hide physical reports

Pointer input can be coalesced, meaning several hardware reports are merged into one delivered event. A page can request the coalesced events to recover the individual reports, but that capability is not universal. A measurement that ignores coalescing can undercount input events.

Stating a lag claim responsibly

A supportable claim names the display rate, the sampling method, and the device transport, then reports the measured figure with its resolution. The evidence file in this repository supports exactly that structure, and it supports no claim about a device this repository has not measured.

Two clocks, one answer

An input measurement involves a device clock that decides when a report is sent and a browser clock that decides when the page observes it. The observable resolution is the coarser of the two. A thousand-hertz mouse sampled by a sixty-hertz rendering loop is measured at sixty hertz, so the mouse's advantage is invisible to that method. Reporting the floor alongside the result is what prevents a reader from attributing the whole figure to the device.

How the floor sets a detection limit

At sixty hertz the sampling period is 16.67 milliseconds. Two devices whose true latencies differ by less than that period cannot be distinguished by this method, because their events can land in the same frame. A difference of one millisecond between two gaming mice is therefore not measurable in a page that renders at sixty hertz, no matter how many samples are collected.

Why high refresh displays help and by how much

At one hundred and forty-four hertz the sampling period falls to 6.94 milliseconds, roughly two and a half times finer. That is a real improvement and it still cannot resolve sub-millisecond differences. The relationship is linear in refresh rate, so the floor halves when the refresh rate doubles, and the guides state the arithmetic rather than presenting a high refresh rate as a complete solution.

What a genuinely useful browser measurement looks like

A useful measurement states the display refresh rate, the sampling method, the device transport, and the number of samples, then reports the observed figure with its resolution. That structure lets a reader judge whether the reported difference exceeds the noise floor. Our evidence file records each of those inputs, which is what makes the structural claim supportable even though no device has been measured here.

Why the floor is arithmetically unavoidable

A measurement that samples on a rendering callback can only observe state at rendering boundaries. If a device reports between two boundaries, its report is seen at the later one. The interval between boundaries is therefore the smallest difference the method can express, and no number of samples changes that, because it is a property of when observation happens rather than of how many observations are made.

How the device side adds its own floor

A device that reports every ten milliseconds cannot be observed more finely than ten milliseconds regardless of how fast the page samples. Bluetooth low energy reports at a seven and a half millisecond floor, and Bluetooth Classic at roughly eleven and a quarter milliseconds. Those intervals are protocol properties, so a wireless device carries a coarser delivery floor than a wired one even before the display floor is considered.

Why the slower side determines the answer

The observable resolution is the coarser of the reporting and sampling intervals. Comparing a high-rate device against a low-rate sampling path measures the sampling path, which is why many published browser figures cluster near the display period. Recognising that the figure is revealing the method rather than the device is the main insight the guide offers.

What coalesced events change

Pointer input can be delivered as a single event that stands for several hardware reports, with the individual reports available through a separate interface. A measurement that ignores coalescing can undercount input events and misjudge timing, while one that uses it recovers finer detail when the capability is available. The guide records coalescing as a factor rather than a flaw, because the capability exists and is not universally supported.

How to report a lag figure responsibly

State the display refresh rate, the sampling method, the device transport, and the sample count, then give the observed figure with its resolution. That structure lets a reader judge whether a reported difference exceeds the noise floor. Our evidence file records each of those inputs, which is what makes the structural claim supportable even though no specific device has been measured in this repository.

Why the floor makes some comparisons impossible

Two devices whose true latencies differ by less than one sampling period can produce identical measurements because their events land in the same frame. No increase in sample count fixes this, since the limit is when observation occurs rather than how often. Recognising an impossible comparison is as useful as making a possible one, and the guide states the arithmetic so a reader can determine which case they are in.

How refresh rate scales the floor

The sampling period is the reciprocal of the refresh rate, so sixty hertz gives sixteen point six seven milliseconds, one hundred and twenty hertz gives eight point three three, and one hundred and forty-four hertz gives six point nine four. The relationship is linear and the guide publishes the values so a reader can see immediately whether their hardware can resolve the difference they are trying to measure.

Why wireless transports carry a larger delivery floor

Bluetooth low energy reports at a seven and a half millisecond floor and Bluetooth Classic at roughly eleven and a quarter milliseconds, both coarser than a wired full-speed device at one millisecond. A wireless device therefore cannot be observed more finely than its transport allows, and the difference between two wireless devices may be smaller than either one's floor. Naming the transport alongside the result is what makes the figure interpretable.

What a reader should do with a published figure

Compare it against the floor for the stated method. A figure close to the floor is likely measuring the method rather than the device. A figure well above the floor is more informative but still carries the floor as an uncertainty. Our evidence file lists each input so the comparison can be made without guessing at the method behind a number.

First-party evidence and provenance

How we checked this

We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script in this repository. The definitions file is regenerated by running that script. For this guide we compared the display sampling period against each device polling interval to establish which side sets the observable resolution, and recorded the resulting floor.

Method: We derived the mechanism set from documented protocol limits, Web platform scheduling behaviour, and the electrical model of a keyboard matrix, then encoded each constant with its reason in a generator script in this repository. The definitions file is regenerated by running that script.
Environment: Node.js on a desktop workstation. The evidence is a definition set with recorded reasons, not a hardware measurement on a specific device.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

tools/research-evidence/device/definitions-2026-09-20.json
tools/research-evidence/device/README.md