Methodology

This page documents exactly how each test is timed and scored, where the measurement loses precision, and what the anonymous statistics we publish do and do not contain. It exists because a test that oversells its own accuracy is not much use to anyone — if you are going to compare your score against something, you should know what the score is made of.

How timing is taken

All timing uses the browser's high-resolution clock, performance.now(). Two properties matter here. It is monotonic, so it cannot jump backwards if the system clock is adjusted mid-test. And it is measured from page load rather than wall-clock time, which removes a class of error that Date.now() would introduce.

Browsers deliberately reduce the resolution of this clock as a defence against timing-based attacks, so the practical granularity is not the microsecond figure the API suggests. We report whole milliseconds because that is the honest level of precision, and any digit beyond it would be decoration.

Every measurement happens in your browser. There is no server round-trip in any timing path — network latency cannot affect your score.

Reaction time test

Procedure. Five rounds, averaged.

  1. You click to arm the pad. The round begins.
  2. The pad waits a random interval before turning lime. The interval is drawn uniformly between 1.5 and 4.0 seconds.
  3. The moment the pad changes, a timestamp is taken. Your click takes a second timestamp. The difference, rounded to the nearest millisecond, is that round's result.
  4. After a 700 ms pause the next round arms automatically.

Why the delay is random. A fixed delay is learnable within two rounds. You would end up timing an internal count rather than reacting to a signal, and the test would measure rhythm rather than reaction.

False starts. If you click before the pad turns, the round is discarded and retried. It is not recorded as a very fast score, and it does not add a penalty. Both alternatives corrupt the measurement: counting early clicks rewards guessing, and penalising them measures your lapse rather than your reaction. Discarding is the only option that leaves the remaining data clean.

Scoring. Your reported result is the arithmetic mean of the five rounds, rounded to the nearest millisecond. Your best round is the minimum. The mean is the figure worth tracking; the minimum is largely luck.

CPS test

Procedure. A fixed window of 5, 10, or 30 seconds.

  1. The timer starts on your first click, not when the page loads. Tests that start counting when ready silently charge you for your own reaction time.
  2. Every click on the pad is counted, including the first one that started the clock.
  3. When the window expires the pad stops accepting input immediately, so a late click cannot inflate the total.

Scoring. Total clicks divided by the mode duration, rounded to two decimal places. No smoothing, no peak detection, no discarding of slow stretches.

Aim test

Procedure. A fixed 30-second window.

  1. The timer starts on your first click.
  2. A target appears at a uniformly random position within the field. Hitting it spawns the next one elsewhere.
  3. A click that lands on the field but not on the target is recorded as a miss.

Scoring. Accuracy is hits divided by total attempts (hits plus misses), expressed as a whole-number percentage. Average time per target is the mean interval from a target appearing to it being hit, rounded to the nearest millisecond. Misses do not contribute to the timing average — only successful acquisitions do.

Random spawn positions are deliberate: a predictable pattern would let you pre-aim, which turns an aim test into a rhythm test.

The grading scale is ours, not a standard

The arcade ranks — Sleepy Sloth through Arcade Legend — are thresholds we chose. They are informed by commonly reported ranges, but they are not derived from a published scale and no external body endorses them. A different site with different thresholds is not wrong; it is using different thresholds.

Treat the rank as flavour and the underlying number as the measurement.

Error we cannot remove

Your score includes your equipment. None of the following is separable from the result, and no browser test can subtract it:

SourceTypical contribution
Display refresh wait~8 ms average at 60 Hz; ~3.5 ms at 144 Hz
Display processingVaries; can be substantial on televisions
Mouse polling~4 ms at 125 Hz; ~0.5 ms at 1000 Hz
Switch debounceMainly affects rapid repeated clicking
Browser event handlingEvents may be coalesced or dropped under heavy input rates
System loadVariable; widens your spread rather than shifting your average

Stacked together, the difference between a poorly configured setup and a tuned one is comfortably in the tens of milliseconds — which is why the same person can score 30–50 ms apart on two machines in the same room, and why cross-site comparison does not work. There is more detail in refresh rate, input lag, and your test score.

What we do not claim

The anonymous statistics

When you complete a test, one anonymous record is sent to us so we can publish aggregate distributions. This is the only thing we store on our servers.

Each record contains at most seven values: which test, the test mode, the score, a device category (desktop, mobile, tablet, or unknown), a two-letter country code supplied by our network provider, the time the record was created, and — only if you chose one — an optional age range (one of seven broad bands, e.g. 20–29). The age range is what will let us publish reaction time by age from measured runs rather than quoted tables; until a band has at least ten runs we will not report it.

It does not contain your IP address, your browser's user-agent string, cookies, account identifiers, or any value that could identify you or link two of your visits together. The device category is derived from the user-agent and then the user-agent is discarded; it is never stored. Records carry no identifier, so they cannot be traced back to an individual — which also means we cannot locate or delete an individual record on request. Full detail is in our privacy policy.

Quality controls. Submissions outside plausible ranges are rejected before storage — for example, a CPS value above 30 or a reaction time under 80 ms. The submission endpoint is rate limited. At aggregation time we additionally remove outliers, and we will document the specific rule used on the statistics pages themselves rather than applying it silently.

Figures we cite but cannot source. Several pages here quote ranges that circulate widely — that simple visual reaction time centres around 250 ms, that ordinary clicking runs 4–6 per second, and so on. We cannot tell you how many people are behind any of those numbers, what equipment they used, or how outliers were handled, because that information is almost never published alongside them. We repeat them because the shape is consistent across sources, not because we can vouch for a specific figure, and we mark them as cited rather than measured wherever they appear. Where our own dataset says something different, we show both and say which is which.

Our own runs are excluded. Scores generated by us while building and testing the site are not visitor data, so they do not belong in a visitor distribution. We now avoid submitting scores from production at all — widget behaviour is checked against a local build instead. Where we cannot be certain whether a run was ours, we exclude it: understating the sample is the safer error.

Every published figure will state its sample size and collection period. Collection began on 29 July 2026, so early figures will be drawn from small samples and labelled as such. We would rather publish a small honest number than a large vague one. The actual distributions are published on our data pages — currently CPS and reaction time — recomputed from the live dataset at most a minute apart, not baked in at a past build.

Corrections

22 August 2026 — statistics restated after removing our own test runs

Until this date the published distributions included scores we had generated ourselves while testing the site in production. They were a large share of the total: of the 23 CPS submissions shown at one point, 16 were ours. We had been deleting such runs as we went, but a batch from 29 July was missed, and figures including it were quoted publicly before the mistake was caught.

All 30 identified operator runs have been removed. The sample dropped from 71 submissions to 41, and every figure on the data pages moved accordingly. The removed rows are listed in the project repository so the change can be audited rather than taken on trust, and the rule that produced the removal is stated above.

10 September 2026 — 53 submissions from a single source excluded

In a ten-minute window on this date, 53 scores arrived from what was clearly one source: every run the same device class and country, one 5-second CPS run every twelve seconds, and none of them accompanied by the page events a browser session produces. Fifty-three people did not show up at once; one script or one person on repeat did. Under the rule above — when in doubt, shrink the sample — those rows were removed and are listed in the project repository. At the time they were 57% of the 5-second CPS sample, which is why we did not wait. A per-minute submission limit was added the same day.

If we find an error in a test's timing or scoring, we will fix it and note the change here rather than quietly adjusting numbers. If a change makes historical statistics incomparable with new ones, we will say so on the affected page.

Found something wrong? Tell us via the contact page. Corrections to this page are welcome and will be credited in substance if not by name.