CPS Is Not Mouse Latency: Pick the Measurement That Answers Your Question

Published by the CPS Test site operator team. This is an explanation of measurement limits, not an independent review or a hardware endorsement. The numerical examples below are hypothetical.

A click-speed result is a rate. Mouse latency is a delay. Both involve time, which makes them easy to confuse, but they answer different questions. Keeping them separate helps you decide whether a browser exercise, an application check, or a hardware measurement is appropriate.

Start with the question, not the biggest number

Suppose you want to know whether you can maintain a steady clicking rhythm for ten seconds. Counting registered clicks within a fixed window is a reasonable observation. If your question is why a menu opens noticeably after you press a mouse button, a total click count does not measure that delay. If your question is whether you noticed a visual signal quickly, you need a task with a defined stimulus and response, rather than a self-started clicking burst.

These distinctions are useful even when a tool displays several decimal places. Extra digits do not change the quantity being measured. A precise-looking rate is still a rate.

Why the reciprocal of CPS is not input lag

In a simplified count-over-time example, 40 registered clicks in five seconds gives 8 clicks per second. Dividing one second by eight gives 125 milliseconds per click as an average time allocation. That is not evidence that the mouse takes 125 milliseconds to report each press.

Imagine two five-second sequences with the same total. One is fairly even; the other contains a fast burst followed by a pause. Their average rates match, although their timing patterns differ. Neither total tells you when the finger first began moving or when the display changed after a particular physical switch activation. Those missing observations cannot be recovered by taking a reciprocal.

A useful score note is therefore “40 registered clicks in a five-second window,” not “125 ms mouse latency.” State how the window starts and ends if you are comparing implementations; a fixed countdown and a timer that starts on the first accepted activation need not count boundaries identically.

What browser timestamps do and do not establish

For developers, MDN describes the browser's Event.timeStamp property as a time associated with event creation, relative to a time origin. Its precision can be reduced by the browser. This is browser event data, not an independent observation of the physical switch closing.

You may use successive event timestamps to study the events a page receives. You should not label that interval “hardware latency” without a method that independently establishes the physical start and the relevant endpoint. An event log, a USB report, a rendered frame, and a visible pixel change are different observation points. A measurement claim should name the points it actually observes.

This article does not claim that a particular timestamp technique is used by our site. The distinction applies generally when interpreting browser-based tests.

A practical three-question worksheet

  1. Am I comparing sustained clicking rate? Use a fixed-duration counter, consistent input method and comparable conditions. Record the count, duration and visible result. For this kind of exercise, our CPS Test browser counter is one available starting point. Do not treat the score as a device certification.
  2. Am I investigating an unexpected extra or missing action? Describe the exact application action first. Slowly perform a small, predetermined number of individual presses, compare intended presses with what the page or application registers, and retain the observations. Agreement on a counter does not prove every other application path is working; a mismatch does not by itself identify a switch, driver or browser as the cause.
  3. Am I investigating response delay? Write down the proposed start and endpoint. “Physical press to visible screen response” needs observations of both. An ordinary CPS total supplies neither a physical start timestamp nor a screen-response timestamp, so use an appropriately documented latency method rather than renaming the total.

Changing several settings at once weakens all three comparisons. Keep a record of what changed, and avoid treating an isolated good result as proof that a change fixed the problem.

Keep conclusions smaller than the evidence

A brief session record can be simple: question; input device and method; browser or application; observed count and duration where relevant; changed condition; and the conclusion the observation actually supports. Add a separate line for what remains unknown.

For example: “The counter registered the planned slow presses in this session; the occasional duplicate action in another application was not reproduced here.” That statement is more informative than “the mouse passed,” because it preserves the scope of the observation.

Rate exercises can be enjoyable and useful without becoming measurements of everything in the input pipeline. Choose the task that matches the question, describe its boundaries, and resist converting a convenient score into a claim the experiment never tested.