Hit a sequence of randomly repositioned targets and review average target time, best time, and targets per second.
Compare repeated runs only under similar conditions. Browser scheduling, display refresh, pointer/keyboard hardware, operating-system settings and touch input can change measured timing.
Average target time and targets per second are meaningful only with the target count and size beside them.
Save up to five recent runs in this browser, repeat the same setup, clear the history at any time, and avoid treating browser timing as hardware-latency or medical measurement.
Use the tool first, then apply these checks to verify the inputs, interpret the result, and hand it off without displacing the primary workflow.
Target count, target size, pointer device, display refresh rate, browser zoom, and input method all affect the measured run. A faster result after changing the target size is not evidence of the same performance improving. Save comparable runs with the same settings before interpreting a trend.
A single unusually fast run can reflect anticipation, a lucky target sequence, or a warm-up effect. Compare a small series and look at typical performance as well as the best time. The local history is useful for self-comparison, but it should not be treated as a standardized clinical or hardware benchmark.
The drill combines seeing the target, moving the pointer, and clicking accurately. It is not a pure reaction-time measurement and it does not isolate mouse sensor latency. If you need a different construct, use a reaction-time or input-latency tool designed for that measurement instead of relabeling this score.
Touch input, trackpads, mice, styluses, motor accessibility settings, and display size can make the same target geometry feel very different. Compare only within a setup that makes sense for the user, and prioritize comfortable, safe interaction over chasing a score that encourages strain or repetitive overuse.
WebToolArc