Scroll Acceleration Test

A scroll acceleration test asks whether the browser-visible response pattern changes when the user changes the pace of the same basic action. This page records two runs instead of assigning a universal score. For each run it keeps event count, elapsed duration, events per second, median and p95 event intervals, raw absolute delta summaries, cumulative delta, peak delta, direction consistency, and action groups separated by short pauses.

That definition makes the scroll wheel acceleration test repeatable without overstating what a webpage can know. A browser receives processed input after the device, firmware, driver, operating system, and browser have already played a role. A difference between Slow and Fast is an observed response change in this environment. It is not proof that a particular hardware or software acceleration feature is enabled.

Scroll speed describes one run: how many browser wheel events arrived, how closely they were spaced, and how large their exposed deltas were. Scrolling acceleration on this page describes the change between two intentionally different input paces. The Fast run may have more events per second, shorter intervals, larger deltas, or some combination. None of those patterns alone establishes a physical acceleration curve.

For a single fixed-time rate measurement, the scroll speed test is the more direct tool. Use this mouse wheel acceleration page when the question is comparative: does a faster action produce a different browser event pattern than a slower action under matched conditions? Slow vs fast scrolling is most informative when the direction, device, browser, and settings stay constant across both stages.

The Slow run is a controlled baseline. Separated wheel actions make it easier to see typical interval spacing and the number of browser events produced per action group. The Fast run uses a noticeably quicker rhythm while preserving the same direction. The wheel response test then calculates event density, median timing, p95 timing, median absolute delta, p75 and p95 absolute delta, cumulative absolute delta, the observed peak, and possible opposite-direction candidates.

Duration begins when you start each stage and ends when you finish it. Events outside the capture card are not counted. If focus or page visibility changes, the run is paused and a quality flag is retained. Twelve events is a minimum rather than a benchmark; more representative input generally produces a more stable summary, but a long run is not automatically more accurate if the movement pattern changes halfway through.

Event rate change reports the percentage difference from Slow to Fast. Median interval change usually moves in the opposite direction because more densely arriving events leave less time between them. Median absolute delta change is shown only when raw units are compatible. Direction consistency is expressed as a percentage-point change so a small number is not mistaken for a multiplier or a quality grade.

The event density timeline divides each run into equal portions of its own duration. It shows event concentration over normalized time, using separate labels and patterns for Slow and Fast. A taller cluster means more events landed in that portion of the run. It does not claim those events correspond one-to-one with physical notches, degrees of rotation, distance on the page, or a device polling frequency.

WheelEvent exposes delta values in pixels, lines, or pages, identified by deltaMode. A value of 100 pixels and a value of three lines do not share a common physical scale. If one acceleration run is Pixel mode and the other is Line mode, the tool disables the raw magnitude percentage instead of inventing a conversion. Event count, event rate, run duration, and timing remain available because they do not require delta-unit conversion.

Even matching deltaMode values do not make raw deltas universal hardware measurements. Browser behavior, line-height assumptions, smooth scrolling, device profiles, and application-level processing can still influence them. Treat a compatible median |delta| change as evidence about these two runs in this browser. Repeat the scroll acceleration test under the same setup before interpreting a change as persistent.

A notched mouse wheel, free-spin wheel, trackpad, trackball, accessibility controller, or remapped input can produce distinct WheelEvent sequences. Vendor utilities may change line counts or add smoothing. Operating-system preferences can alter direction and scroll distance. Browsers may coalesce activity, express different units, reserve modifier combinations, or schedule events differently when the page loses focus. User grip and stroke length add another source of variation.

For a useful slow vs fast scrolling comparison, keep the same device and connection, leave browser zoom unchanged, keep the tab visible, and avoid changing system or driver options between stages. Do not compare a touch gesture with a mouse-wheel run. Touch scrolling is not silently converted into wheel input, and a device that produces no WheelEvent will leave the capture count unchanged.

The wheel response test can document a before-and-after setting change, compare a controlled notched-wheel pattern with a faster pattern, or help explain why rapid document navigation feels different from careful scrolling. Developers can inspect whether an interface receives denser events during faster input. Support teams can ask for two repeatable runs before suggesting a driver, operating-system, browser, or application setting to inspect.

The test is also useful to people evaluating their own comfortable scrolling rhythm. It does not rank users, declare a mouse good or bad, or provide a 0–100 score. If the goal is to inspect individual WheelEvent fields, open the raw wheel event tester. If the goal is a general A/B protocol across devices or settings, use the scroll wheel comparison test instead.

This scroll wheel acceleration test cannot identify a mouse firmware algorithm, read a driver coefficient, confirm a hidden operating-system feature, measure physical angular acceleration, or diagnose an encoder. A higher Fast-run median delta may reflect response scaling, a more forceful user action, event aggregation, a mode change, or several layers acting together. The page reports the pattern and leaves the cause open.

No result should be treated as a hardware specification or warranty decision. A surprising value deserves a repeated controlled run, followed by comparison in another browser or application if needed. The site performs the calculations locally and offers an optional versioned summary for the local Test Results center; it does not upload raw event samples or create a public benchmark.

This test compares browser-observed wheel input between controlled runs. It does not directly measure a hardware or operating-system acceleration coefficient. Results can change with the input source, remapping, driver, system configuration, browser, page focus, deltaMode, and the way the user performs each run.