Input Lag & Mouse Polling Rate Tester Reference

What Is Mouse Polling Rate?

A mouse reports movement in regular bursts, not a continuous stream. Polling rate is measured in Hz (reports per second), so higher rates deliver more position updates within the same span of time and reduce the maximum gap between physical movement and cursor response.¹

What is a polling rate?

Why polling rate matters for gaming

In competitive games, cursor position is read at the start of each frame render cycle. At 1000 Hz polling, the mouse sends up to one report per millisecond; the game gets the most recent position each time. At 8000 Hz, reports arrive every 0.125 ms, meaning the cursor position available at render time is at most 0.125 ms old rather than up to 1 ms old.¹ Consequently, fast aim movements involve less positional error between the physical mouse and the displayed cursor, particularly during high-speed flick shots.

Why polling rate changes cursor freshness

Because cursor position gets sampled by the game engine at the start of each frame, the polling interval and the frame interval interact in a way that matters most at high frame rates. At higher polling rates, more reports arrive between frames, and the cursor is fresher at sampling time. Games that run at lower frame rates benefit less from polling rate increases, because the frame interval dominates the total input latency rather than the polling interval.

Common polling rate values and their intervals

125 Hz (8 ms interval) is the USB legacy default, adequate only for non-gaming use. 500 Hz (2 ms) is common on older gaming mice and usable for casual play. 1000 Hz (1 ms) has long been the competitive baseline. 4000 Hz (0.25 ms) provides a measurable improvement for players who perform fast movements. 8000 Hz (0.125 ms) is the current high-frequency ceiling for consumer gaming mice.² Yet polling rate above 1000 Hz requires getCoalescedEvents() support in the application; older engines operating on standard PointerEvents effectively see at most 1000 Hz regardless of hardware setting.³

Why the getCoalescedEvents() API matters for high-frequency measurement

The getCoalescedEvents() API lets browsers expose intermediate mouse reports that would otherwise be combined into a single PointerEvent before the application sees them. Without this API, every browser collapses multiple reports into one event per dispatch cycle, capping visible polling rate near 1000 Hz regardless of hardware rate. Pointer Events Level 3 also defines pointerrawupdate for high-frequency pointer events, while warning that high-frequency listeners can affect performance.⁴ This is why a measurement page needs the right browser API support to show rates above the normal dispatched-event cadence.

How to check and change your polling rate

The polling rate is set in companion software (Razer Synapse, Logitech G HUB, Corsair iCUE, etc.) and stored in the mouse's onboard memory. After setting it, the rate persists without the software running. You can verify the active polling rate using this tool; move your mouse inside the tracking zone and read the Hz chart. This tool uses getCoalescedEvents() to accurately measure rates above 1000 Hz.³ A reading significantly below the configured rate typically indicates USB bandwidth contention or USB selective suspend coalescing OS-level reports; disabling selective suspend in Windows Device Manager resolves many cases.⁵

In companion software, the polling rate setting persists in onboard memory after the software is closed. Setting 8000 Hz in Razer Synapse, then closing Synapse, keeps the mouse at 8000 Hz without Synapse running during the test. Confirming the setting was applied by running this tool with Synapse closed gives a cleaner baseline than measuring with companion software active, since background software processes can introduce minor scheduling delays that inflate the measured latency by 0.5 to 1 ms.

When the configured rate is not the active rate

The configured polling rate matters only after it reaches the browser. If the chart reads far below the setting, treat the result as an active-path measurement and troubleshoot USB power management, port selection, and software state before changing other mouse settings. A mouse set to 8000 Hz in software but reading 1000 Hz in the browser is not broken; it is telling you that something in the delivery path between the mouse firmware and the browser event is coalescing or throttling the reports, and that diagnostic information is more useful than the advertised specification for understanding your actual input latency.

Repeating the verification after a Windows update is worth the minute it takes. Updates frequently reset USB power policy and reinstall controller drivers, which can quietly drop a stable 8000 Hz reading back toward 1000 Hz. Running this tool once after each major update confirms the delivery path still holds, and catches a regression before it shows up as aim drift in a match.

Try in the tool

What Is Click Latency?

In a mouse test, click latency tells you how long a button press takes to reach the operating system. It is the time from physical mouse button actuation to the corresponding mousedown or pointerdown event.¹ This latency determines how quickly in-game actions respond to your clicks. Lower is better, and consistency is as important as the average value.

What is click latency?

Components of click latency

Click latency accumulates across four stages. Switch actuation: optical switches detect actuation through a light beam rather than physical contact points, and Razer describes its optical mouse switches as having zero debounce delay.³ Firmware debounce: mechanical contacts can bounce before settling, so firmware debounce filters secondary transitions. The exact debounce window depends on the switch and firmware, so it can add visible latency. USB polling cycle: the delay until the next USB report slot is determined by endpoint polling interval, device speed, and host controller; at 1000 Hz, the scheduling window is up to 1 ms.⁴ OS input processing: driver and input stack overhead also affect when the event reaches the browser. All four sum to the value you see in a browser click latency test.

Which stage is slowing your click

Isolating each contributor requires changing one variable at a time. Moving from a hub to a direct rear motherboard port removes one USB contention point and can reduce scheduling delays. Disabling selective suspend can also help when a mouse becomes unstable while waking from a suspended state.⁵ Reducing debounce in companion software removes the firmware debounce component. Measuring before and after each change in the click latency log gives a concrete value for what each pipeline stage contributed, which tells you exactly which change produces the most improvement on your specific system.

Optical vs mechanical switch click latency

Optical switches can keep debounce delay near zero because they do not rely on physical contact closure for click detection.³ Mechanical switches require a debounce window to filter contact bounce, and that window adds directly to click latency. The larger the stable debounce setting, the later the browser can receive the pointerdown or mousedown event for the same physical press.

For players transitioning from a mechanical switch mouse to an optical model, the click latency log shows the difference most directly. A mechanical mouse with a long debounce window typically shows a higher baseline than an optical mouse with minimal debounce. Your individual values will differ based on the specific switch, firmware, USB path, and OS scheduling, but the pattern holds across brands and price points: optical mice can produce lower averages and tighter per-click variance when debounce is the limiting factor.

What click latency values are normal

In a browser-based test, click latency readings reflect the combined path from switch actuation, firmware debounce, USB reporting, OS scheduling, and browser event delivery. Optical-switch gaming mice with minimal debounce typically read lower and tighter than mechanical-switch mice with longer debounce windows. Mechanical mice, budget switches, USB contention, and background scheduling interference can all push readings higher or make consecutive clicks vary more widely. Values that vary widely between consecutive clicks indicate USB contention, OS scheduler interference, or a switch approaching contact bounce failure.⁵

Using individual log values rather than averages for diagnosis

Average click latency conceals the distribution shape that diagnoses specific problems. A mouse with a 4 ms average and all values between 3 and 5 ms is in good condition with consistent hardware behavior. A mouse with a 4 ms average but values ranging from 1 ms to 20 ms has a spike problem that the average obscures. The individual log in this tool shows every click value; reviewing the spread rather than just the average identifies intermittent scheduling interference, USB contention, or early-stage switch bounce that an average-only reading would never reveal.

Why consistency matters as much as the average

A low average can hide a few tall spikes that matter during rapid actions. If most clicks cluster tightly and only one session shows spikes, compare background apps and USB path before changing switch settings. If every session shows the same high average, debounce or firmware settings deserve closer attention. In competitive play, a single 15 ms spike during a crucial flick shot matters more than a 2 ms average across a hundred clicks; the individual log values surface those outliers so you can decide whether the inconsistency is an occasional scheduling hiccup you can ignore or a systematic USB contention problem that needs a hardware fix.

Logging the same 20 clicks across two or three sessions gives you a reliability picture that a single run cannot. If the spread stays tight every time, the mouse is stable and you can stop troubleshooting. If the spikes grow between sessions, the switch or USB path is degrading and deserves a fix before it spreads. Treat the repeated log as your maintenance check rather than a one-time curiosity.

Try in the tool

What Is Mouse Debounce?

A mechanical switch bounces before it settles. Mouse debounce is a firmware technique that filters out this physical bounce so a single press is not interpreted as multiple clicks.¹ Understanding debounce explains both click latency, because the debounce window delays the reported state change, and double-click failures, because aged mechanical switches can bounce outside a too-short window.

What is mouse debounce?

How mechanical debounce works

When a mechanical switch closes, the metal contacts physically bounce apart and reconnect multiple times before settling. This produces a series of on-off electrical transitions until the contact stabilizes. Without debouncing, each transition can register as a separate click event.¹ Firmware debounce applies a timer: after the first contact event, it ignores subsequent events for the debounce window duration. Consequently, the total click latency includes the debounce window; a mouse with a 5 ms debounce can add up to 5 ms before the firmware reports the settled state.² A shorter debounce reduces latency but accepts more risk of bounce events slipping through as the switch ages.³

How the debounce window affects your click speed ceiling

At a debounce window of 10 ms, the firmware ignores any event that arrives within 10 ms of the previous one. Clicking faster than 100 times per second would place some presses within the debounce window, causing them to be silently filtered. For most gaming scenarios, 100 CPS is well above sustained competitive rates, and a 10 ms window has no practical effect on gameplay. Competitive players who jitter-click or butterfly-click at 14 to 20 CPS, however, may notice that rapid press sequences do not register fully at long debounce settings, making minimum debounce a priority for fast-clicking play styles.

Optical switches and near-zero debounce

Optical switches eliminate the physical mechanism that requires debouncing. When your finger presses the button, a lever interrupts a light beam rather than closes metal contacts. A light beam either interrupts or does not; there is no physical bounce in the beam interruption event. Building on this, optical switch firmware can use zero debounce delay because there is no contact bounce to filter.⁴ This is why optical-switch mice can reduce measured click latency compared with mechanical mice that still include a debounce window.³

Why optical switches can skip the debounce window

Optical switch mice benefit from zero debounce delay because there is no physical bounce to filter. Setting the minimum debounce in companion software directly reduces measured click latency by the debounce window amount. For mechanical-switch mice, the same change requires more caution: reducing debounce below the switch's natural bounce duration will produce double events, making the minimum stable setting specific to each switch's condition.

Debounce, aging, and double-click failures

As mechanical switch contacts age, contact wear and surface condition can make the bounce pattern less predictable. A fixed debounce window that reliably filtered bounce on a new switch may no longer cover all bounce events on an aged one. When a bounce event falls outside the debounce window, the firmware registers it as a second click. Adjusting the debounce window longer in companion software filters the wider bounce pattern, suppressing double-clicking temporarily. Yet this workaround adds latency and only delays the need for switch replacement.

Tracking double events over time reveals how quickly a mechanical switch is wearing. After identifying that double events appear only occasionally, increase debounce one step and retest. If that single step eliminates the double events, the switch still has usable life at the adjusted window. Retesting monthly with the same 30-click protocol shows whether the adjusted window continues to suppress bounce or whether the minimum stable debounce keeps rising, which signals that physical replacement is approaching.

Why the lowest stable setting is not always permanent

A switch that is stable today can need more debounce after heavy use. If the minimum stable setting creeps upward over several months, the adjustment is buying time rather than restoring the switch to its original condition. Replace the switch when debounce becomes long enough to affect gameplay or when double events keep returning. Contact oxidation and mechanical wear are cumulative processes, so a debounce setting that works for six months may need another increase after a tournament season of heavy clicking; tracking the trend over time tells you whether the switch is in a slow decline or has reached a stable plateau.

Running the 30-click protocol after any debounce change keeps the comparison honest as the switch ages. If a setting that cleared doubles last month needs another step now, you have a dated record of the decline rather than a vague sense that the mouse feels worse. That record is what tells you when a replacement is cheaper than continuing to chase the bounce with firmware delays.

Try in the tool

Optical vs Mechanical Mouse Switches

Switch design determines debounce requirements, so optical and mechanical switches produce measurably different click latency profiles. Optical switches detect button presses by interrupting an infrared light beam; mechanical switches detect them when metal contacts close.¹ This single design difference explains why optical mice can register clicks with lower debounce-related latency and avoid the contact-bounce failure pattern that characterises aged mechanical switches.

What is optical vs mechanical mouse switches?

Click latency: the debounce difference

Mechanical contact closure produces physical bounce; the contacts can snap together and apart several times before settling. Firmware must wait for bounce to subside before confirming the actuation, so the debounce window becomes part of measured click latency.⁴ QMK's debounce model shows why this matters: the firmware can ignore changes until the configured debounce time has elapsed, which means a longer debounce window trades latency for stability.³ Optical beam interruption produces no physical contact bounce, so optical mouse switches can bypass debounce delay and reduce the debounce portion of click latency.¹

If you want to isolate how much of your click latency comes from debounce specifically, compare the same mouse before and after changing the debounce window setting. The gap between those two values equals the debounce contribution for your system at that setting, assuming the same USB scheduling and OS conditions.

How to compare switch types fairly

A fair comparison keeps the mouse, port, surface, polling rate, and press rhythm constant while you change only the debounce setting or switch type. That prevents the test from blaming a switch for a USB path, grip change, or background scheduler spike. When the same setup shows a repeatable gap between optical and mechanical readings, the difference is much more likely to be the debounce path than an unrelated system variable.

Longevity and failure modes

Mechanical switches age through contact wear and changing contact surfaces; Analog Devices notes that mechanical switches can become less bounce-free as they age.² When bounce grows beyond the firmware debounce window, the firmware can register a second click from one physical press. Optical mouse switches avoid that failure mode because light-based actuation does not rely on metal contacts, and Razer rates its optical mouse switches for a 100 million click lifecycle.⁵

What the click latency log shows differently for each switch type

The click latency log makes the difference between switch types visible at the individual-event level rather than through averages alone. Optical switches tend to show lower debounce-related latency because they can bypass contact bounce. Mechanical switches tend to show a debounce window in the log, and aged mechanical switches can add double entries from one physical press. Running both switch types through the same 20-click protocol on the same mouse, if the design supports hot-swapping, produces the most direct comparison because every other variable (grip, port, OS state, browser) stays constant while only the switch mechanism changes.

Feel and feedback differences

Mechanical switches provide tactile and audible feedback through the physical spring and contact mechanism. Optical switches actuate without metal contact closure, so manufacturers tune the lever, spring, and feedback curve to preserve a familiar click feel. Razer describes Gen-4 optical mouse switches as responsive and tactile⁵, while Logitech LIGHTFORCE combines optical speed with mechanical feel.⁶

Haptic switch designs like Logitech H.I.T.S. go further: electromagnetic sensors detect button movement and micro-motors create tactile feedback, with Logitech claiming 9 to 30 ms less click latency per click on the PRO X2 SUPERSTRIKE.⁷ For players who prefer mechanical click feel over the latency improvement of optical designs, hybrid switches like Logitech LIGHTFORCE offer a middle ground: optical actuation handles the registration event while the physical lever and feedback system preserve the click feel.

Choosing based on measured behavior and feel

Do not choose switch type from averages alone. Run the click latency test with your normal debounce setting, then note whether the log shows tight values, occasional bounce outliers, or repeated double events. A tight mechanical log may be preferable if feel matters, while an optical switch is usually the cleaner choice when bounce outliers or double events dominate your current setup.

Repeating the test after you swap a switch or change a debounce setting confirms whether the new behavior is real or just session noise. If the optical run shows tight values across three sessions and the mechanical run shows recurring doubles, the pattern is reliable enough to guide a purchase. A single session of either type is too small a sample to justify replacing hardware you already own.

Try in the tool

What Is Mouse Jitter?

A steady cursor should follow your hand in a predictable way. When it does not, the difference is called jitter. Mouse jitter refers to erratic or inconsistent cursor displacement: small deviations in the cursor path that do not correspond to intentional physical motion. It degrades fine-grained aiming, precision work, and general cursor feel.

What is mouse jitter?

Hardware causes of jitter

Several hardware sources contribute to mouse jitter. Optical sensor inconsistency: at very high DPI, small sensing error and scaling choices can become visible in the cursor path, and the surface texture affects how reliably the sensor translates movement into cursor movement.³ Surface interaction: inconsistent, patterned, or dirty surfaces can interfere with sensor performance, while a consistent texture gives sensors better imagery for translating mouse movement. Cable drag: a stiff or snagging cable can add mechanical resistance and inconsistent feel rather than pure sensor-position noise; managing the cable can reduce drag.⁴ Wireless mice avoid cable drag, but 2.4 GHz receivers can suffer erratic operation when USB 3.0 devices or poor receiver placement reduce operating distance.⁵

For most gaming mice, surface choice produces the most immediately testable jitter reduction. Switching from a glossy desk surface or reflective mousepad to a clean medium-texture cloth or hard mousepad changes the sensor tracking environment directly. Running the test on the current surface, then on a different surface, and comparing the Hz chart variance gives a concrete measurement of how much the surface contributes to jitter on your specific sensor. A chart that visibly stabilises on a new surface points to surface interaction as the primary source rather than USB or cable factors.

Testing surface interaction before changing settings

Before adjusting DPI, polling rate, or acceleration settings, test the mouse on a different surface to rule out sensor tracking as the jitter source. A clean, medium-texture cloth mousepad provides the most consistent tracking surface for the majority of optical sensors. If the Hz chart stabilizes on a new pad but the cursor still feels erratic, the issue is more likely USB timing or software scaling rather than the sensor itself. This simple swap test takes under a minute and prevents unnecessary configuration changes that mask the real problem.

USB and software causes of jitter

USB polling inconsistency creates temporal jitter; events that are correct in position arrive with irregular timing. The USB endpoint descriptor defines the interrupt endpoint polling interval through bInterval, and Windows says the actual polling frequency also depends on the device and host controller.⁶ Windows disables USB selective suspend for HID devices by default to avoid resume latency, but vendor or PC configured HID devices can support it and must wake from suspend without perceived delay.⁷ Software causes include mouse acceleration, which Windows exposes as Enhance Pointer Precision, and rapid DPI changes through assigned DPI Up, DPI Down, and DPI Cycle buttons.⁸

USB hub contention produces periodic rather than random jitter. When multiple interrupt devices share a host controller, endpoint timing depends on the controller schedule and each device can add timing variability to the measured Hz chart.⁹ Periodic drops usually point to USB scheduling or hub contention, while random slow-movement dropouts can point to configured power-management behavior, so retest after changing USB port or receiver placement before blaming the sensor.

Separating USB timing from cursor scaling

USB jitter changes when the report timing changes; cursor scaling changes when acceleration or DPI settings change. If moving the receiver or disabling selective suspend stabilises the Hz chart, the issue was timing. If the Hz chart stays stable but the cursor path still feels wrong, check Enhanced Pointer Precision and DPI configuration next. The two causes require completely different fixes: USB timing problems need a hardware or OS policy change, while cursor scaling problems need a software setting change, so correctly identifying which one is active prevents you from chasing the wrong solution.

Detecting jitter with a polling rate test

This tool surfaces jitter through the Hz chart. A stable mouse at 1000 Hz produces a flat line near 1000.¹ Wide variance, a jagged chart, or repeated dropouts indicate temporal jitter rather than a single clean polling rate. Persistent dropout markers (red vertical lines) during slow, steady movement indicate event coalescing from USB power management or hub contention rather than the normal coalescing during fast movement. Cursor path smoothness is harder to quantify in a polling test; if the Hz chart looks stable but aim feels inconsistent, sensor surface interaction or mouse acceleration is the more likely cause.

Identifying the jitter source from the dropout marker pattern

Reading the dropout marker pattern in the Hz chart helps distinguish environmental sources from hardware sources before making any changes. Markers that appear during fast directional changes but disappear during steady straight movement suggest cable drag; each brief tension peak as direction reverses interrupts the smooth polling cadence. Markers spread evenly across both fast and slow movement suggest hub contention, because the interrupt-slot competition happens regardless of movement speed. Markers that appear randomly without correlation to movement direction or speed can point to configured USB power-management behavior or another host-controller scheduling issue, so retest after changing USB port, receiver placement, or wireless interference conditions before blaming the sensor.

Taking the same 15-second sample on two different surfaces and two different ports creates a small comparison matrix you can trust. If the chart cleans up on both a new pad and a direct port, the sensor was never the cause and you can stop there. If only the port change helps, the issue is USB timing. Building the matrix once saves you from repeating the same failed fix the next time jitter returns.

Try in the tool