Methodology

ReactionMetric is designed to be transparent about what a browser can and cannot measure.

Protocol

Each session requires five valid trials. After you start, the test waits for a randomized delay. The ready state is committed on an animation frame, then ReactionMetric timestamps the visual-ready event and your response using the same high-resolution monotonic browser clock.

False starts and valid-trial window

If you respond before the signal appears, that round is marked as a false start and excluded. After the signal appears, ReactionMetric accepts browser-observed responses from 100 to 3000 ms. Responses under 100 ms are treated as anticipatory and responses over 3000 ms as lapses; neither counts toward the five valid trials. The 100 ms lower bound follows a common data-cleaning convention in reaction-time research rather than claiming that human physiology has one universal hard cutoff. Examples include a browser-based simple reaction-time study and a visual reaction-time study that excluded responses below 100 ms.

Background tabs

If the page becomes hidden during a waiting or ready phase, the round is invalidated. Browsers throttle background work, so keeping that round would reduce comparability.

What the score means

The displayed milliseconds are browser-observed visual response time. They are not a pure measure of nervous-system latency. Display refresh, input hardware, operating-system scheduling, browser scheduling and system load can all contribute.

No fake calibration

ReactionMetric does not apply a fixed subtraction for “browser latency” or claim to know your monitor and mouse hardware delay. Instead, it records coarse environment context and can compare similar setups when enough first-party data exists.

Environment quality

The browser estimates display refresh rate from animation-frame intervals and labels the sampled frame stream as stable or unstable. Where supported, the Long Tasks API is used only as a coarse busy/clear signal for main-thread jank. These are measurement-quality hints, not hardware calibration, and benchmark storage keeps only coarse quality labels rather than detailed device fingerprints.

Benchmark protocol versions

The current public benchmark is task version 2. Version 2 applies the 100–3000 ms valid-trial window and is kept separate from earlier benchmark rows so a protocol change does not silently mix incompatible populations.

Summary statistics

We report mean, median, best, worst and standard deviation. Median is resistant to a single unusually slow trial, while standard deviation helps describe session consistency.