How This Click Speed Test Works (and Why We Built It)

A click speed test looks like the simplest possible web page: a button, a timer, a number. Under the hood there are a surprising number of decisions that affect whether the number you see is honest — how clicks are counted, how time is measured, and what happens at the messy edges where browsers, mice, and touchscreens disagree with each other. This page explains how our test handles those decisions, and why we built it the way we did.

The core formula

CPS is total clicks divided by elapsed seconds. That's the whole formula, and both halves need to be measured correctly for the result to mean anything.

In the timed modes (5, 10, 30, or 60 seconds), the denominator is fixed: click as much as you can and we divide by the duration you chose. In the 100-click race mode it's inverted — the click count is fixed at 100 and the clock is what varies, so finishing faster yields a higher CPS. The race mode exists because it changes the psychology: instead of pacing yourself against a countdown, you're sprinting toward a finish line, and many people find they click measurably faster that way.

Counting clicks: why we listen for pointerdown

The obvious way to count clicks in a browser is the click event, and it's the wrong one. A click only fires after a full press-and-release cycle completes on the same element, which adds latency and can swallow presses during very rapid clicking, when a release might land slightly off-target. Instead, this test counts pointerdown events — the earliest moment the browser knows your button or finger went down. Nothing about your release timing affects the count.

Using the Pointer Events API also solves the classic double-counting bug that plagued older click testers on phones. Touch input historically fired both a touch event and a synthesized mouse event for compatibility, so a naive tester that listened for both would count every tap twice. Pointer events unify mouse, touch, and stylus into a single stream, so one physical press is one pointerdown, whatever device produced it. That's how the same test works on desktop and mobile without inflating either.

One thing we deliberately do not do is filter “implausibly fast” clicks. If your mouse registers a burst — say, from drag clicking, or from a worn switch that double-fires — we count what the operating system reports. A browser page has no reliable way to distinguish a hardware double-click from a genuinely fast human, and guessing would make results less trustworthy, not more.

Measuring time: performance.now() and honest endpoints

For the clock, the test uses performance.now(), the browser's high-resolution monotonic timer, rather than the wall-clock Date.now(). The distinction matters: the wall clock can jump around (NTP sync, timezone changes, the OS adjusting itself), while the monotonic clock only ever moves forward at a steady rate. For a measurement where a 2% timing error means a 2% CPS error, that's the correct tool.

The on-screen countdown and live CPS readout update on a requestAnimationFrame loop — once per display frame — but that's purely cosmetic. Your clicks are timestamped and counted by their own events, independently of how often the display repaints, so a janky frame rate can't eat your clicks. When a timed mode ends, the elapsed time is clamped to exactly the mode's duration, so a frame arriving a few milliseconds late can't quietly stretch your denominator and shave your score.

There's also a short countdown before the timer starts, and the timer begins at the start signal rather than on your first click. Starting the clock on the first click sounds generous but subtly inflates scores (your first click is “free”), and different sites choosing differently is one reason the same person gets different numbers on different testers.

Why your results vary between devices

Take the same test on two computers and you may score differently. Some of that is you — chair height, mouse familiarity, warm-up — but some is genuinely the hardware:

Switch debounce. Mouse firmware waits a few milliseconds after each click to filter electrical noise before it will register another. A mouse with 20ms of debounce physically cannot report more than ~50 clicks per second, and aggressive debounce can clip legitimate fast clicking. Gaming mice often let you tune this.
Polling rate. A mouse reporting at 125Hz batches its news in 8ms intervals; at 1000Hz, 1ms. This mostly affects latency rather than count, but at extreme click rates coarser polling adds jitter to when clicks land.
Touchscreens. Taps involve firmware-level gesture processing, so mobile scores usually run a little lower than mouse scores for the same person. Comparing phone scores to desktop scores is comparing different sports.
Background load. A heavily loaded machine can delay event delivery. The count survives, but if you're benchmarking yourself seriously, close the forty other tabs first.

The practical upshot: CPS scores are most meaningful as comparisons against yourself, on the same device, in the same mode. That's why the site frames your result against your own personal best and recent attempts rather than a global leaderboard full of unverifiable numbers.

Why we built it this way

We wanted a click test with three properties. Honest measurement — the technical choices above, made deliberately rather than inherited from a tutorial. Instant and free — no sign-up, no app, nothing between you and the button. And private by default: everything runs locally in your browser. Your clicks and scores are never uploaded to any server; your personal best lives in your browser's localStorage on your own device, which is also why clearing your browser data resets it. There's no account system because the test doesn't need to know who you are.

The rest — the ranks, achievements, streaks, and score sharing — exists because a measurement tool is more fun when it's a little bit of a game. None of it changes the math.