Why Anticipation Is the Only Cheat That Matters

A reaction time test is only worth running if guessing cannot beat reacting.Everything about a trustworthy version of this measurement comes down to preventing a correct answer by predicting the question.

There are other ways to flatter a score — an unusually fast machine, a favourable moment — but anticipation is the one that destroys the meaning of the number entirely. Here is how this site handles it, and the one case it cannot fully close.

The delay is redrawn every attempt

Before each stimulus, the test waits a uniformly distributed integer between 1000 and 3000 ms inclusive. It is not a fixed period with a little jitter; it is a fresh draw across the whole range, every single attempt.

That matters more than it might sound. With a fixed or narrow delay, a practised tester learns the interval within a few attempts — and then the measurement silently becomes a test of anticipation timing. Across a two-second uniform range there is no rhythm to find. Counting, tapping along, or guessing a pattern produces results scattered across the whole range, most of which are too early.

There is also a deliberate implementation detail: the draw takes no calibration input at all. So enabling latency compensation or screen-scale correction provably cannot distort the delay distribution. The guarantee does not depend on a configuration being right.

Pressing early is caught

Any input while the test is still in its waiting state is handled as too early and isnever written to your history. It is not averaged in, not recorded as a zero, not quietly discarded — it is surfaced to you as a failed attempt so you know it happened.

This closes the obvious exploit. Someone trying to beat the test by tapping on a rhythm cannot build a history of lucky taps, because those taps are not successes. In the five-trial mode the trial simply repeats rather than ending the run.

The corner case, stated honestly

There is one gap, and pretending otherwise would undermine the rest of this page. The detector catches presses that arrive before stimulus onset. It does not catch a press that wasintended as a pre-press but landed a few milliseconds after the signal.

A sufficiently practised person can learn to pre-press so precisely that the press coincides with the onset, and it registers as a legitimate very fast result. This is not a bug to be fixed inside the page — the information needed to distinguish it does not exist there. The signal is a colour change; the code knows when it committed that change, not when the pixels changed.

So the honest guidance is behavioural rather than technical: treat a suspiciously fast result as a signal to re-test, not a result to celebrate. A consistent sub-150 ms visual average on a browser test is more likely anticipation than physiology. Our FAQ used to describe very fast results as exceptional; it now says to verify them.

The ready gate closes it properly

Rather than trying to detect anticipation after the fact, the ready gate removes the opportunity. With it enabled, the stimulus does not fire on a timer at all — it waits for you to press a ready button. You therefore cannot be early, because nothing has started yet.

The cost is that the measurement now includes a deliberate decision, which slightly changes what is being tested and adds an extra press to the sequence. For occasional use it is the most rigorous option available in a browser. For comparing your own scores across sessions it is unnecessary, because a consistent anticipatory strategy produces a consistently wrong number, which still tracks.

What the response window adds

After the stimulus, the test waits 2000 ms for a response before recording the attempt as missed. Two things follow:

• 1.There is a minimum honest response time. Nothing faster than the window opening is possible without pre-pressing.
• 2.Missing is recorded rather than silently dropped, so an incomplete run is visible instead of quietly improving your average.

A separate 250 ms guard prevents a single attempt from being scored twice by a lingering double-event.

Why the ruler cannot be reverse-engineered

On a real ruler-drop test you catch a falling stick and the catch distance is converted into a time. That gives an attacker a second route to a fabricated result: measure the ruler against a screen ruler and derive the time from the geometry.

Here the arrow points the other way. The on-screen fall is animated by the same high-resolution clock that records you, with a deliberately quadratic ease rather than real gravity. Your score is the elapsed time between onset and your input; the centimetre figure displayed beside it isthen computed from that time using d = ½gt². Pixel position carries no independent information, so there is nothing in the geometry to solve backwards from.

All constants quoted are this site’s own, fromsrc/engine/types.ts(1000–3000 ms delay, 2000 ms response window, 250 ms re-arm guard) and implemented insrc/engine/lifecycle.tsand src/engine/modes/ruler.ts. See the methodology page.