ScrollTest measurement methodology

While a capture is armed or recording, ScrollTest captures wheel input anywhere on the page so keyboard users do not have to position the pointer over the workbench. For each delivered event, the measurement core records the values needed to describe that browser sample: horizontal delta, vertical delta, delta mode, a monotonic timestamp, an unambiguous up/down/horizontal/zero classification, and the interval since the previous event. A horizontal-only event has zero vertical delta and a nonzero horizontal delta; a true-zero event has neither. Neither is collapsed into a generic neutral bucket or forced into up or down.

The WheelEvent standard provides three delta modes. Mode 0 means pixels, mode 1 means lines, and mode 2 means pages. ScrollTest labels totals with the unit actually reported for the event. It does not label line or page values as pixels, and it does not invent a universal conversion between them.

A reported pixel is a browser/CSS movement unit, not a measured distance travelled by a wheel or finger. Line and page deltas depend on application and system settings. If a run contains more than one delta mode, the units remain separated so unlike quantities are not silently added together.

Read mouse versus touchpad scroll events for the practical reasons two devices can report very different event and delta patterns for actions that feel similar.

Intervals come from each event's own WheelEvent.timeStamp: the moment the browser created the event, reported on the monotonic performance.now() timeline. Reading that clock inside the listener instead would add however long the main thread took to reach the event, and that delay varies from event to event, so it does not cancel out of an interval — it can push a normal interval under the burst threshold or over the gap threshold. Timed runs offer 5, 10, and 30 seconds. The selected duration is the protocol target; the result also shows the measured protocol duration and any observed stop-delivery delay separately so scheduling delay is not silently treated as extra input time.

An event that carries no usable timestamp is timed from the listener instead. That is a fallback, not the method, so each run reports which clock produced its timestamps and how many events used each, and a run that fell back says so in its result and in its export.

The material callback-delay threshold is 250 ms. A deadline completion delayed by exactly 250 ms remains valid; a delay greater than 250 ms invalidates the sample and excludes it from saved history and comparisons. A valid result, including a valid one-event result, persists and displays its measured callback delay so the scheduling context is not lost.

A timed run starts under the test's stated start condition and has one terminal state. Completion, manual cancellation, and interruption are mutually exclusive outcomes. If the document becomes hidden during a run, ScrollTest flags or invalidates the sample because browsers can throttle work in background tabs. Returning to the tab does not retroactively make that interval comparable.

The controlled direction diagnostic asks for a declared down phase and a declared up phase. Within each phase, an event whose vertical direction opposes the declared direction is a reversal observation. Horizontal-only events, true-zero events, long gaps, and tightly delivered event groups are counted and reported separately as browser-observed patterns. Horizontal and zero events do not satisfy the expected vertical-direction sample. A phase with too few expected vertical events is inconclusive, never classified as clean merely because it contains no counted reversal.

A reversal can come from hardware, momentum, software, an accidental finger movement, or browser delivery. A gap cannot reveal a physical detent that produced no browser event. A burst may represent fast input, coalescing, an input driver, or main-thread scheduling, so a burst count is descriptive context and does not by itself trigger a retest outcome. The conclusion is therefore limited to “no suspicious pattern observed” or “pattern worth retesting.” It is never a definitive hardware-failure verdict.

Follow the full troubleshooting protocol before changing hardware or settings.

Event rate is the number of browser events received divided by measured seconds. The challenge uses browser events per second. It is not notches per second. Delta movement is reported independently in pixels, lines, or pages because a high event rate and a high delta rate are different observations.

Average event rate divides received events by the measured run duration. Peak event rate is the largest count observed in a trailing one-second window. Neither number reveals how many physical wheel steps occurred.

ScrollTest does not publish universal “good,” gamer, quality, percentile, or accuracy bands. Those claims would require a disclosed dataset, fixed device categories, browser and OS controls, inclusion rules, sample dates, and a stable metric version. Until such a dataset exists, the useful comparison is your own repeated run on the same setup.

Repeatability and diagnostic-protocol history are scoped by metric version, test intent or mode, selected duration, declared input category and setup. Diagnostic protocols also keep the declared input-device connection and coarse browser/OS context in scope. The input categories are detented mouse, free-spin mouse, touchpad, or unknown. ScrollTest retains at least three completed same-scope diagnostic protocols so their outcomes can be compared. Results outside the same scope are context, not a like-for-like benchmark, and are never folded into the three-run comparison. Incompatible records from an older schema are migrated only when their meaning is preserved; otherwise they are safely ignored or discarded.

History and raw traces remain in the browser unless you explicitly export them. A normal share URL contains a small summary, not the raw event trace. Query values can be edited by anyone, so a loaded shared result is labelled self-reported and unverified. Validation rejects malformed or out-of-range values but does not prove that a test occurred.

See the privacy policy for storage, sharing, export, analytics, retention, and deletion details.

A normal diagnostic report includes the locally generated report ID and date, declared setup, protocol, input category, input-device connection type (or explicitly unknown), browser and operating-system context, metric version, duration, validity and callback-delay context, the diagnostic outcome, and a link to https://www.scrolltest.io/methodology. Declared context is labelled as such; ScrollTest does not infer a device model or other physical hardware.

The normal report contains summary counts—including up, down, horizontal-only and true-zero events—but not the raw wheel-event trace. The raw trace is added only when the user explicitly chooses the separate raw-export action.

1. Select the input category and keep the same device, browser, OS settings, and wheel mode.
2. Choose the same diagnostic, repeatability, or challenge intent and the same duration.
3. Keep the test visible and avoid switching tabs, zooming, or changing scroll settings.
4. Use a deliberate protocol: steady down, pause, steady up; repeat at normal and faster paces.
5. Complete at least three valid same-scope protocols before interpreting repeatability.
6. Export a report only when you want to retain or send the observation outside this browser.