How Our CPS Tests Work

How the Click Timer Works

The moment you click inside the test area for the first time, the timer starts. We record the start timestamp using performance.now(), part of the W3C High Resolution Time API. This API provides sub-millisecond precision relative to the page load epoch and is not affected by operating system clock adjustments or network time synchronisation. It is universally supported in all modern browsers.

The timer counts down for your chosen interval (1, 2, 5, 10, 30, or 60 seconds). When the elapsed time reaches the target, the test area locks, no further clicks are counted, and the end timestamp is captured using a second performance.now() call. The elapsed duration used in the final CPS calculation is the difference between those two timestamps, converted to seconds — not the nominal interval length. This corrects for the small but real latency introduced by JavaScript's event loop and setTimeout drift.

Using the measured duration rather than the target duration means that if a 5-second timer actually ran for 5.012 seconds (a common scenario on busy browser tabs), your CPS is divided by 5.012, not 5.000 — giving you a result that accurately reflects how many clicks you landed in real elapsed time.

What Counts as a Click

FastCPSTest listens for mousedown events, not click events. This is a deliberate and important distinction. The browser's click event fires after both mousedown and mouseup have completed, meaning each registered click requires the full physical press-and-release cycle. For most users clicking at 5–8 CPS, this makes no practical difference. But at high CPS (12+), extremely fast clickers — particularly butterfly clickers — can lift their finger so quickly that the mouseup event is delayed by the browser's gesture recognition, causing some clicks to be missed or merged.

By capturing mousedown, we register the click the instant the physical switch actuates, regardless of how quickly you release. Each mousedown from the primary mouse button (button index 0) increments the counter by exactly one. Right-click and middle-click are ignored. Scroll wheel clicks are also ignored.

On touch devices, touchstart events are mapped to the same counter. Each distinct finger touch counts as one click, so multi-finger tapping can inflate your CPS significantly compared to mouse clicking. Touch results are labeled accordingly in your score history so you can keep desktop and mobile results conceptually separate.

How CPS Is Calculated

The formula is straightforward:

CPS = totalClicks ÷ elapsedSeconds

totalClicks is the raw count of mousedown events recorded between the first click and the timer expiry. elapsedSeconds is the measured duration in seconds from that first performance.now() timestamp to the final one.

The result is displayed rounded to two decimal places. Internally we preserve the full floating-point value for rank calculation and history storage so that small differences between very close scores are not lost to rounding. For example, a score of 9.994 CPS ranks differently from 10.001 CPS, and we preserve that distinction even though both display as approximately 10.00.

How the Rank System Works

Every CPS score maps to one of ten rank tiers — Iron, Bronze, Silver, Gold, Platinum, Diamond, Master, Grandmaster, Legendary, and Apex — based on thresholds derived from aggregated community click data. The thresholds are set so that the percentile boundaries reflect real-world clicking distributions: the majority of casual users fall in Silver and Gold, while Diamond and above represent genuinely fast clicking that requires either technique (jitter or butterfly clicking) or elite-level natural speed.

Below the Apex tier, each rank is divided into three divisions: III (the lower third of the CPS range), II (the middle third), and I (the upper third). The progress bar shown after each test tells you your position within the current division and how far you are from the next division boundary. This gives you a concrete, incremental target rather than a single large CPS gap to close.

To see the exact thresholds, percentiles, and descriptions for every tier, visit the Ranks page.

Accuracy and Limitations

While performance.now() provides sub-millisecond resolution, several layers of the browser stack introduce real variability:

• Event loop latency. JavaScript is single-threaded. If other scripts, layout passes, or rendering work is queued when you click, the event handler may fire up to a frame late (approximately 16 ms at 60 Hz). This is why we use the actual elapsed time rather than a fixed interval.
• Timer resolution clamping. For privacy and security reasons, browsers clamp performance.now() to 1 ms resolution in cross-origin contexts and 100 µs in same-origin contexts. FastCPSTest runs same-origin, so you get 100 µs resolution — more than sufficient.
• Touch vs. mouse. Touch input is processed through a separate pipeline from mouse input. On most mobile browsers, touch events are subject to a 300 ms delay for tap recognition unless touch-action: none is applied. Our test area disables this delay, but touch still adds roughly 20–50 ms of latency compared to a direct mouse connection, slightly compressing high-end CPS scores on touchscreens.
• Background tabs. Browsers throttle timers in background tabs to conserve battery. Always keep the FastCPSTest tab in the foreground while testing.

These factors mean that two identical tests run seconds apart can produce CPS scores that differ by 0.1–0.5. This is normal variability, not a measurement error — it reflects the genuine randomness in human motor performance and browser scheduling.

How Scores Are Stored

All test results are stored exclusively in your browser's localStorage. Nothing is sent to our servers. No account is required. No cookies track your test history. When you complete a test, the score, timestamp, test duration, and computed rank are serialised to a JSON array in localStorage under a single key. We retain the last 20 attempts and your all-time best score.

Because storage is local, your history is specific to the browser and device you used. Clearing your browser storage or using a different browser will reset your history. This is a trade-off we make intentionally: local storage is faster, requires no authentication infrastructure, and gives you complete control over your own data.

If you want to transfer your history to another device, you can inspect localStorage via your browser's developer tools and copy the JSON string manually. Future versions of FastCPSTest may add optional cloud sync behind an account login, but local-first storage will always remain the default.

Why Tests Vary Between Sessions

It is completely normal to see your CPS fluctuate by 0.5–2 CPS between sessions, even when you feel like you are clicking identically. Several factors drive this variability:

• Physical fatigue and warm-up state. Your finger muscles perform differently cold versus warmed up. The first test of the day is almost always slower than the third or fourth.
• Browser load. A tab-heavy browser session with background scripts, video players, or extensions running may introduce more event loop latency than a clean session.
• Motor variability. Human click cadence is not perfectly regular. Your rhythm naturally speeds up and slows down in micro-bursts, and the final score depends on which phase of that rhythm the timer catches.
• Shorter intervals are more volatile. On a 1-second test, a single missed click changes your CPS by 1.0. On a 10-second test, one missed click changes it by 0.1. Use longer intervals for a more stable measure of sustained clicking speed, and shorter intervals to measure peak burst speed.

The history feature exists precisely for this reason: averaging your last 10–20 results gives a much more reliable picture of your true CPS than any single attempt. Learn more about what your score means on the main CPS test page.

Equipment Recommendations for Most Accurate Results

The equipment you use significantly affects both your score and result consistency. Here is what we recommend:

• Wired mouse over wireless. A wired USB mouse eliminates the 1–8 ms of added latency introduced by wireless polling and Bluetooth protocol overhead. At high CPS, that latency can cause clicks to be dropped or registered out of order.
• High polling rate mouse (500 Hz or higher). A 125 Hz mouse (standard for budget mice) reports position every 8 ms. At 500 Hz, that drops to 2 ms; at 1000 Hz, to 1 ms. For CPS measurement specifically, polling rate primarily affects whether a very fast click lands in the window between polls. 500 Hz is the minimum we recommend for meaningful high-CPS tests.
• Desktop or laptop over mobile. As noted above, touch events carry additional latency and can be inflated by multi-finger techniques. For a fair comparison with other users' scores, test on a mouse.
• Updated browser. Older browser versions may have less efficient JavaScript engines or missing APIs. Chrome, Firefox, Edge, and Safari at their current release all perform well. We do not officially support browsers older than two major versions.
• Stable surface. This sounds trivial, but a mouse pad significantly reduces friction variability compared to a bare desk. Consistent surface friction means your hand position stays stable, reducing the movement that causes inconsistent finger angles — one of the most common sources of click-to-click variability.
• No other heavy processes running. Close unnecessary browser tabs, video streams, and CPU-intensive applications during your test window. The more CPU bandwidth available to the browser, the lower and more consistent the event loop latency.

You do not need a premium setup to get useful results — any modern laptop and a standard mouse will measure your click speed accurately enough to track improvement over time. These recommendations matter most when you are trying to push absolute peak CPS or compare scores precisely with other users. For a deeper look at how reaction time interacts with click speed, see our Reaction Time Test.

Summary

FastCPSTest uses performance.now() for high-resolution timing, mousedown events for accurate click capture, measured elapsed time rather than nominal interval length for CPS calculation, community-calibrated rank thresholds, and local localStorage for private, server-free score persistence. Small session-to-session variability is normal and expected. Use longer test intervals and multiple attempts to characterise your true clicking speed.