Browser Keyboard Event Latency Test

Focus the test zone and press keys repeatedly to compare browser event timing under the same device/browser conditions. Use the result as a relative diagnostic, not a hardware polling-rate certification.

Press keys repeatedly

Measures browser event scheduling/timing—not physical switch-to-USB latency.

—Latest scheduling delay ms

—Average delay ms

—Interval jitter ms

0Samples

A web page does not know when a physical switch closed. It receives an event later from the OS/browser. Use this page for relative browser-visible timing comparisons under the same conditions, not as a certified keyboard polling-rate or hardware input-lag measurement.

Median, p95 & consistency audit

Summarize the browser-visible event-delay session with robust percentiles and timing consistency.

Benchmark evidence

Metric	Value	Use

How to use the Browser Keyboard Event Latency Test

Focus the timing zone and press keys repeatedly under the same browser/device conditions. Review browser scheduling-delay samples and timing consistency, then repeat after changing only one condition if you want a relative comparison.

Why use it

Measurement and privacy limits

A browser does not know the instant a physical switch closes, so this tool does not claim true end-to-end hardware latency, USB polling rate, or scan rate. It measures browser-visible event timing only.

Practical guide and verification

Use the product workflow above first. These notes add interpretation, verification and limits below the interactive result area.

This measures browser-visible event delay, not the whole keyboard pipeline

The reported delay is based on browser event timing. USB polling, keyboard firmware, operating-system scheduling, browser workload and display refresh all contribute to what you experience, so the result should not be presented as a laboratory measurement of switch-to-photon latency.

Use the median for a typical run and p95 for bad tails

One unusually slow event can distort an arithmetic mean. Compare the median for the center of the session, p95 for the slow tail, and jitter or spread for consistency. A device that is usually fast but occasionally stalls can feel worse than its average suggests.

Change one condition at a time

For useful A/B testing, keep the same browser, tab load, keyboard connection and power mode, then change only the variable you want to compare. Run enough presses to build a distribution instead of judging hardware from one or two events.

Background activity can dominate a browser benchmark

Heavy tabs, extensions, power-saving modes and system load can delay JavaScript event handling without any change to the keyboard itself. Repeat a suspicious result after closing background work and record the environment with the session export.

Compare distributions, not tiny decimal differences

A difference of a fraction of a millisecond in two short browser runs is rarely strong evidence. Look for repeatable changes in median, tail latency and consistency across multiple sessions before concluding that one setup is materially faster.