What Is a Mouse Latency Test?
Mouse latency is the delay between physical activity and a resulting response, but that phrase can describe several different boundaries. A hardware mouse latency test may measure sensor movement or switch activation against an electrical report. An end-to-end test may measure from physical input to a changed display pixel. This browser mouse latency test has a narrower boundary: it inspects timestamps on pointer events delivered to JavaScript and the time at which the handler processes them.
That makes the page a browser event timing analyzer, also called a mouse event latency or browser input delay test. It can reveal delivery intervals, scheduling variation, and timestamp behavior in the current browser. It cannot see the instant a sensor first detected motion, observe the USB packet directly, read game-engine processing, or know when the display emitted the resulting pixel. The labels keep those layers separate.
What This Browser Test Measures
For every pointer movement, the tool stores the event timestamp, current performance.now() value, and time origin. Where getCoalescedEvents() is supported, it includes the browser-exposed sub-events rather than discarding them. The page reports median and average browser event delay, P95 delay, population standard deviation as timing jitter, average interval between event timestamps, sample count, and session duration.
A bounded 5,000-sample history prevents continuous motion from growing memory indefinitely. Interface updates are throttled while raw accepted samples remain available to the calculation. Median describes the typical validated processing delay, P95 describes the slower tail, and standard deviation describes spread. Average event interval remains useful even when the browser’s delay timestamp origin cannot be reconciled reliably.
Mouse Hardware Latency vs Browser Event Delay
Hardware sensor latency begins before the operating system or browser receives anything. Switch debounce, firmware scheduling, USB report opportunities, host processing, and driver behavior can all occur upstream. Browser event delay begins much later and is based on an exposed event timestamp. Downstream, application logic, frame scheduling, GPU work, display scanout, and pixel response still remain. Therefore browser delay must never be renamed hardware mouse latency.
Click-to-photon latency spans the complete path and normally requires external instrumentation such as a controlled actuator, photodiode, high-speed camera, or purpose-built latency device. A normal page cannot independently establish the physical start or emitted-light finish. Use this mouse response test to compare browser delivery conditions, not to publish an end-to-end hardware specification.
How to Get Started
Connect a physical mouse, select Start Test, focus the patterned movement area, and move continuously in broad circles or side-to-side passes. Avoid repeatedly striking the edge of the area, since stopping and repositioning changes event intervals. Collect several hundred samples over at least five seconds, then select Stop. Touch motion is ignored, and a touch-only device shows a clear mouse-required state.
Run at least three sessions under the same browser, display, USB path, power mode, and movement style. Close unusually heavy tabs if you want a quiet baseline. To compare one setting, reset between runs and change only that setting. Small differences can be ordinary scheduling noise, so use median, P95, jitter, intervals, and sample count together instead of treating the smallest observed delay as the answer.
How Event Timing Is Calculated
Browsers have historically exposed event timestamps relative to different origins. The production calculation first rejects non-finite and negative inputs. An epoch-sized timestamp is converted by subtracting performance.timeOrigin; a relative timestamp is used directly. The normalized value must be plausible relative to current high-resolution time. Negative delays, origin mismatches, and delays above the safety ceiling are excluded from delay statistics.
When enough timestamps validate, delay equals handler time minus normalized event time. Median, arithmetic mean, linearly interpolated P95, and population standard deviation are computed from those delays. Positive event-time differences below one second form the interval series. If delay timestamps are unreliable, the interface explicitly says so and falls back to interval and sample statistics instead of displaying an absurd or fabricated processing delay.
Polling Rate vs Latency
Polling or report rate is a frequency, commonly expressed in hertz. Latency is a duration. A theoretical 1000 Hz report opportunity occurs every 1 ms, while 125 Hz occurs every 8 ms, but that interval is only one component of a complete response. A higher configured rate can reduce waiting for the next report without guaranteeing lower sensor delay, browser processing delay, or click-to-photon latency.
The mouse polling rate test emphasizes delivered-event frequency and reciprocal intervals. This latency page emphasizes timestamp-validated browser delivery characteristics and jitter. Event coalescing can cause JavaScript dispatch frequency to differ from exposed sub-event timing. Use both pages when you need both perspectives, and use suitable lower-level instrumentation when the hardware layer is the actual question.
What Affects Mouse Timing?
Mouse firmware, configured report rate, USB topology, hubs, wireless interference, battery state, operating-system input policy, browser implementation, timer precision, event coalescing, main-thread load, power saving, and hand motion can all affect the observed series. Screen refresh does not directly define every pointer timestamp, but some browsers may align dispatch or page work with rendering. Recording software and developer tools can add load.
Movement speed matters because a stationary sensor produces no useful sequence. Extremely small or irregular movement can create sparse events. High-rate devices may deliver more updates than a busy page can process individually, leading to coalescing. A browser difference is therefore evidence about browser delivery, not proof that the physical mouse changed. Repeat on the same path before comparing configurations.
Who Should Use the Test?
Web developers can inspect pointer-delivery behavior during performance work, users can compare browsers or power modes, and gamers can learn how event interval differs from end-to-end latency. The tool can expose severe scheduling interruptions or confirm that a page receives a dense event stream. It is not a competitive ranking and does not label a universal good or bad delay.
For troubleshooting, save the browser version, operating system, mouse connection, configured rate, sample count, median, P95, jitter, and interval. A repeatable change across controlled sessions is more meaningful than one unusually low sample. Native games use different input APIs and scheduling paths, so a browser result should not be presented as the latency inside a named game.
Why Browser Results Cannot Replace Hardware Measurement
The web security and input model intentionally abstracts devices. JavaScript does not receive a trusted physical-motion timestamp, raw USB transaction log, sensor scan signal, switch contact state, display scan position, or emitted-light measurement. Even getCoalescedEvents() only reveals events the browser chooses to expose. High-resolution clocks measure the page’s part of the path accurately, but accuracy within a narrow boundary does not expand that boundary.
Use professional or purpose-built hardware measurement when comparing mouse sensor onset, click latency, or click-to-photon response. This page remains useful because browser event delivery is itself a real layer for web games and applications. Its limitations are a reason to label the output precisely, not a reason to invent a more impressive metric.
Related Gaming Input Tools
Open the mouse polling rate test to focus on estimated event frequency, or the mouse DPI analyzer to estimate movement density over a measured physical distance. The reaction time test measures a complete visual screen-to-input task that includes a person and device chain. Those three intents are distinct from browser event processing delay, even though all involve pointer input.
The methodology documents event types, timestamp normalization, negative and absurd delay rejection, percentile and jitter calculations, coalesced-event handling, sample bounds, and interval fallback. The disclaimer explains why browser-level timing does not establish hardware, sensor, or click-to-photon latency. Use those definitions whenever you record or share a result.