Device diagnostics research
The Measurement Floor in Browser Input Lag Testing
A page reports an input lag figure. Below what value can that figure not be trusted?
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.
Reviewed 2026-09-20 by BeanNest Studio
The display-side sampling period
A test that samples through requestAnimationFrame can observe state only at rendering callbacks. The definition set records 60 Hz as a 16.67 millisecond period and 144 Hz as a 6.94 millisecond period. For that sampling method, a value smaller than one callback period is not distinguishable from zero by the callback observations alone.
The device-side delivery interval
The same definition set records 10 milliseconds for USB low-speed HID, 1 millisecond for USB full-speed HID and the 1000 Hz gaming-device entry, roughly 11.25 milliseconds for Bluetooth Classic HID, and a 7.5 millisecond floor for Bluetooth LE HID. These are delivery-side bounds, not measured end-to-end latency for a named device.
Use the coarser bound for this method
When the page samples more slowly than the device reports, the page-side sampling period is the limiting resolution. A 1000 Hz device observed only on a 60 Hz rendering callback is therefore bounded by the 16.67 millisecond callback period for this measurement method. Faster device reporting does not make that callback path resolve finer intervals.
Timestamps add a separate precision question
The definition set records timer coarsening for performance.now() and notes that Event.timeStamp can use a different origin. Those timestamp properties are separate from the display and transport intervals, so a useful report should name which clock supplied each time value instead of treating every timestamp as interchangeable.
Coalesced pointer events can hide reports
Pointermove delivery can coalesce several hardware reports into one dispatched event. The browser may expose the coalesced reports separately, but the definition set does not treat that as a universal delivery path. A test that counts only dispatched pointer events can therefore count fewer events than the device produced.
Sampling periods for common refresh rates
The period is 1000 divided by the refresh rate: 16.67 ms at 60 Hz and 6.94 ms at 144 Hz, which are the two values the definition set records, and by the same arithmetic 8.33 ms at 120 Hz and 4.17 ms at 240 Hz. A faster display lowers the floor for a callback-based test, but it does not remove it, and a device that reports faster than the display cannot raise the resolution above the display's period.
A worked reading
Suppose a page samples through requestAnimationFrame on a 60 Hz display and reports 12 ms. The period is 16.67 ms, so a value of 12 ms is below the resolution of the method and cannot be separated from zero by those callback observations alone. The same page reporting 40 ms is above the floor, but it still describes the whole chain of device, system, browser and display, not any single part.
What BeanNest's input pages report
Keyboard Test lists the events the browser received, including the physical key code, modifiers and repeat state. Mouse Test reports button, wheel and movement events and says it is not hardware latency. Refresh Rate Test estimates the foreground repaint cadence from requestAnimationFrame timing and makes no hardware claim. None of them is an input-lag meter, and this guide explains why a number from that kind of page needs its method attached.
What this evidence can and cannot support
BeanNest has not measured end-to-end lag for a specific mouse, keyboard, display, operating system, or browser build. The supportable output is a method description: display rate, sampling path, transport interval, clock source, and the observed value stated together with the method's resolution.
Scope of this guide
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.
Method and evidence
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 kept with the evidence files. 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.
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: 2026-09-20. Re-review trigger: Re-review when the polling constants or the browser scheduling limits are revised.
Evidence files: kept in BeanNest's source repository, not published on this site.
docs/research-evidence/device/definitions-2026-09-20.jsondocs/research-evidence/device/README.md
What this guide does not claim
- measured lag values for any device
- product comparisons or recommendations
- claims that one transport is always better
- statements about operating-system input stacks