MOUSE LATENCY / METHOD GUIDE
Measure the delay you actually mean.
A browser can measure what happens after a mouse event reaches the page. It cannot see the physical switch close or confirm when pixels change on your display.
Choose the result you need first. Then use the matching endpoints, equipment and interpretation below.
CHOOSE BEFORE YOU MEASURE
Six similar-sounding tests answer different questions.
The endpoints decide what the number means. If either endpoint sits outside the browser, a webpage cannot measure the complete path.
BROWSER RESPONSE CHECK
Run ten clicks in one fixed target.
This check starts at the event timestamp supplied to the page. It does not start at the physical mouse switch.
Only trusted main-button mouse presses inside this target count. Touch, pen, keyboard activation, right/middle clicks and clicks outside the target are excluded.
NOT TESTED
Complete ten clicks to get a browser result.
The result will describe event delivery and the first animation-frame callback in this tab.
Next: Start a round, keep this tab active, and make ten deliberate clicks.
EXACT ROUND EVIDENCE
See the spread, not just one average.
Waiting for a complete round.
- No completed samples yet.
CONTROLLED A / B
Keep two completed rounds in this page.
Change one condition at a time. Saved rounds stay only in this open page unless you copy or download the report.
Complete a round before saving it.
No saved rounds yet.
ONE CLICK, SEVERAL SEGMENTS
The browser check observes only the middle of the path.
Observed here: the teal segment. A requestAnimationFrame callback runs before a paint opportunity; it is not proof that a completed frame reached your eyes.
MOUSE-ONLY CLICK LATENCY
Compare press → USB report.
Use this when the decision is about the mouse, connection mode or firmware—not the game and display.
- Trigger repeatably. Use a controlled actuator or electrical contact so the start point is consistent. Finger movement and switch pre-travel must not silently become part of one mouse’s result and not another’s.
- Capture the report. Record the first matching USB input report with a protocol analyzer or a validated rig that exposes the same endpoint.
- Fix the conditions. Record firmware, debounce/performance mode, wired/receiver/Bluetooth connection and report-rate setting.
- Repeat and show the distribution. One click is not a comparison. Report sample count, median, tail value and exclusions.
RTINGS’ current method is one documented example: a solenoid, contact trigger and USB analyzer across repeated clicks. Its exact rig and scoring bands belong to that method; they are not universal thresholds for this page.
CLICK-TO-DISPLAY LATENCY
Compare trigger → changed light.
Use this when the felt problem is “I click, then the game changes late.” It captures the combined mouse, PC, game, rendering and display path.
- Choose one visible response. Keep the same game scene, response region, frame-rate cap and display mode.
- Capture both endpoints. Use a synchronized input trigger and luminance sensor, a compatible integrated analyzer, or high-speed video that clearly shows both events.
- Repeat under one condition. Do not compare wired and wireless while also changing display mode, scene or frame rate.
- Interpret the whole path. A slower result says the combined path changed; it does not identify the mouse as the cause without a mouse-only measurement.
NVIDIA Reflex Analyzer and LDAT show two concrete click-to-display setups and their hardware boundaries.
HIGH-SPEED VIDEO LIMIT
Frame rate sets your timing resolution.
Count frames from the chosen input marker to the first clearly changed display frame, then multiply by the time per frame. Report the uncertainty instead of adding false decimal precision.
WHEN ONE WEBPAGE FEELS SLOW
Inspect the page, not the mouse.
Reproduce the actual interaction. Use the button, menu or control that feels slow. This page’s 10-click check cannot stand in for another site’s work.
Break down the delay. Event Timing and browser developer tools can distinguish delay before the handler, handler work and time until the next presented frame.
Use INP for page responsiveness. INP summarizes interaction responsiveness across a page visit. It is not a mouse specification and it is not this lab’s ten-click median.
A COMMON MIX-UP
1,000 Hz means a nominal 1 ms report interval—not 1 ms total click latency.
That interval is only one scheduling opportunity in a longer path. Switch handling, transport, operating-system work, the application, rendering and the display remain outside it.
USE THE RESULT
What to do next.
Repeat with one changed condition.
Keep the device and target fixed. Compare a quiet tab with the same tab under load, or browser A with browser B. Ten clicks describe only that round.
Run another browser round ↑Use a hardware endpoint.
A lower browser event age does not prove one mouse is faster. Compare controlled press-to-USB data under matching settings.
Open mouse-only method ↑Measure click to visible response.
Capture the same trigger and response region repeatedly. Then isolate components only if the full path changes.
Open full-system method ↑Test the signal before timing it.
First confirm that the expected button events arrive. Timing cannot explain a press that never reaches the page.
Open mouse input test →METHOD, DATA AND LIMITS
The online result is browser evidence, not a mouse health grade.
The lab accepts ten trusted main-button mouse Pointer Events inside the fixed target. It calculates event age at the page handler and time to the first requestAnimationFrame callback using the browser’s performance clock. P95 uses the nearest-rank value. Negative or incompatible event timestamps fall back to the handler clock and are labelled.
Current samples, condition notes and up to two saved summaries stay in this open page’s memory. Reset or reload clears them. Copy and download happen only when you press those controls. This page does not upload the round.
Method sources: W3C Event Timing · MDN interactionId · web.dev INP · web.dev INP diagnostics · RTINGS latency method.