Scroll Latency Test

For each trusted `wheel` event received inside the active surface, the scroll latency test records a high-resolution browser timestamp and requests the next animation frame. When that callback runs, it subtracts the event receipt time from the callback timestamp. The resulting event-to-next-frame delay is retained in a bounded local sample and summarized without uploading raw timing data.

This measurement begins late in the full input pipeline and ends before a pixel is guaranteed to appear. It does not include an independently measured physical wheel movement, firmware processing, complete USB transport, display scanout, or pixel response. It is therefore a browser/render-loop timing approximation, not total click latency, mouse latency, or a laboratory input-lag number.

Latest delay is the newest completed event-to-frame measurement. Median is the middle of the sample and is less dominated by one long interruption. P95 is a tail indicator: about ninety-five percent of recorded values are at or below the reported nearest-rank value. Minimum and maximum show the observed range, while sample count indicates how much data supports the summary.

No single value is universally good. At a steady refresh cadence, an event arriving just before a frame callback can have a small delay, while one arriving just after a callback may wait closer to a full frame interval. Background load, timer scheduling, power management, and browser work add variation. Compare distributions collected under matched conditions instead of ranking devices from one minimum.

The page separately samples animation-frame callback intervals and displays their median as milliseconds and an approximate hertz value. A 60 Hz context is roughly 16.7 milliseconds per frame, while a higher-refresh display can offer shorter opportunities. Browser throttling or a background tab can dramatically reduce callback frequency even though the mouse itself has not changed.

Observed render cadence is not hardware mouse polling rate. Polling describes how often a device or USB path reports input; `requestAnimationFrame` follows the browser’s rendering schedule. The mouse polling rate test estimates browser-received movement event delivery through a different protocol. Mixing those values would collapse two independent parts of the pipeline.

Operating-system scheduling, browser event dispatch, main-thread work, compositor decisions, display refresh, variable-refresh behavior, power-saving modes, background applications, extensions, and developer tools can all influence the wheel input latency test. Smooth-scrolling code may introduce additional animation after the measured callback. A page with no visual scroll can still produce an event-to-frame timing value.

The input source also affects event timing. A notched wheel, free-spin wheel, touchpad with momentum, remote session, or accessibility controller can send different event patterns. Multiple wheel events may schedule callbacks for the same upcoming frame. Each receives its own delay, but that does not imply that each physical movement created a separate presented frame.

Begin with the same browser window, zoom, display, power mode, and background load. Capture twenty to fifty normal wheel events, finish the run, and note the median, P95, frame context, and any focus interruption. Reset and repeat before changing one variable. Large differences that survive repeats are more useful than a single low or high reading.

When comparing browsers, restart the same simple page and avoid carrying open developer tools in only one run. When comparing system settings, write down the original value so it can be restored. When comparing devices, remember that the page still begins timing only after input reaches the browser; a similar result cannot prove identical end-to-end hardware latency.

If scrolling feels delayed but event-to-frame values are stable, inspect application smooth-scrolling duration, extensions, animation, overflow handlers, and compositor behavior. If the frame context becomes slow or irregular, close heavy work, check power and display modes, and repeat. If wheel events themselves arrive in bursts, compare the scroll speed and wheel event tester pages.

Try another browser and a native application before changing drivers. Use official operating-system or manufacturer sources for updates. Wireless charge, receiver placement, remote-desktop latency, and system load can matter, but this timing metric cannot identify which one is responsible. A controlled before-and-after test is more credible than attributing a long P95 to one component.

Browser timestamps and animation callbacks are designed for web scheduling, not calibrated instrumentation. Security precision limits, callback batching, variable refresh, and background throttling affect them. The tool discards synthetic events from the official sample, stops when focus is interrupted, bounds stored values, and performs calculations in the browser.

A scroll latency test result should be described as event-receipt-to-next-frame delay for this browser session. It is not end-to-end physical mouse latency, click latency, USB polling rate, display response time, or proof of a hardware problem. Repeat the measurement in another application or use dedicated measurement equipment when a high-stakes latency conclusion is required.