Building a Fair Reaction Time Test in the Browser

Waqar ashraf — Sun, 30 Aug 2026 07:26:45 +0000

A reaction time test is one of those projects that looks tiny until you try to make the result fair. The basic version needs only a coloured target, a random delay, and a timer. A useful version has to handle false starts, input differences, slow frames, touch screens, repeated attempts, and clear feedback.

I built a browser-based reaction test as part of HitTheButton.io. This post explains the engineering choices behind it and the testing method I used. It is not a medical or diagnostic tool. It is a small web game designed for repeatable practice and honest feedback.

Start with a simple state machine

The cleanest way to avoid confusing behaviour is to model the round as a few explicit states:

Idle — the player has not started.
Waiting — the timer is hidden and the game is waiting for a random delay.
Ready — the target has changed colour and input is now valid.
Result — the reaction time is displayed.
False start — the player acted before the signal.

This structure keeps the click handler small. It does not need to guess what the player intended. It checks the current state and performs the matching action.

A single boolean such as "started" is usually not enough. It cannot clearly distinguish waiting from ready, and that is where early clicks get counted by mistake.

Use a random waiting period

If the signal always appears after exactly two seconds, players learn the rhythm instead of reacting to the visual change. The game therefore chooses a random delay for each attempt.

The range should feel long enough to prevent prediction but short enough to avoid frustration. It is also useful to keep that range visible in the rules so players understand that the pause is intentional.

The pending timeout must be cancelled whenever the round resets. Otherwise, an old timeout may fire during a later round and turn the target green at the wrong moment. I keep the timeout identifier with the round state and clear it before starting every new attempt.

Measure elapsed time, not frames

For short intervals, the browser's high-resolution performance clock is a better fit than counting animation frames. Frames are for drawing; they are not a dependable clock. A busy device may skip frames, and background work can delay visual updates.

When the signal appears, the game stores a start timestamp. When the player responds, it subtracts that value from a fresh timestamp. The displayed number is rounded for readability, but the internal measurement stays precise until the final step.

This separation also makes the interface easier to change. The timer logic does not depend on how often the screen is redrawn.

Treat false starts as part of the test

An early press should not produce a fast score. It should stop the round and explain what happened. This protects the result and teaches the player to wait for the actual signal.

The message should be neutral. "Too soon — try again" is more useful than a dramatic penalty. The next attempt should be available immediately, especially on mobile where accidental taps are common.

A false start also needs to cancel the pending ready signal. Without that cleanup, the button may turn green after the failure message appears.

Keep input paths consistent

A browser game may receive input from a mouse, touchscreen, keyboard, or assistive technology. The scoring logic should live in one function, while different event handlers call that function.

That reduces the chance of one input method getting different rules. It also helps prevent double counting when a touch event is followed by a synthetic click.

For keyboard play, Space and Enter are sensible controls. During an active round, the game prevents Space from scrolling the page. Outside the game, normal browser behaviour remains available.

Pointer events are useful for mouse, pen, and touch support, but the main control should still be a real button. Native buttons provide focus behaviour and keyboard accessibility that a generic container does not.

Design for repeatable attempts

One score can be affected by distraction, device load, anticipation, or a slightly late visual frame. A useful game makes repeated attempts easy and shows the best score without implying that a single number defines the player.

I store a personal best in local storage. It stays on the current device and does not require an account. If storage is unavailable, the game still works; it simply skips persistence.

A short history can also help players notice consistency. I prefer a small list of recent attempts instead of a complicated dashboard. The game remains quick to understand.

Explain measurement limits

Browser reaction tests include more than human response time. The result can also be affected by:

display refresh and pixel response;
mouse, keyboard, or touchscreen latency;
browser scheduling;
background applications;
power-saving modes;
the way a person holds or presses the device.

For that reason, comparisons are more meaningful when the same person uses the same device and input method under similar conditions.

Age-based comparisons also need careful wording. They are descriptive references, not diagnoses or fixed targets. I wrote a separate, plain-language overview of average reaction time by age for kids that explains these limitations and encourages consistent test conditions.

Make mobile layout intentional

A target that works with a mouse may be awkward for a thumb. On narrow screens, the active area needs enough height and the button needs generous spacing from browser controls.

The score should not jump around when its value changes. Stable dimensions prevent layout shifts during the moment when the player is trying to react.

I also avoid heavy animation before the signal. Decorative motion can become an unintended cue or distraction. The ready state should have one strong visual change with sufficient contrast.

Test the failure cases

The happy path is easy. The useful tests are the awkward ones:

tap twice quickly;
press before the signal;
restart while waiting;
switch tabs during a round;
rotate a phone;
press Space while the page can scroll;
start a new round immediately after a result;
disable local storage;
use keyboard-only navigation.

I test those cases manually on desktop and mobile widths. I also inspect the state transitions during development. If the game ever reaches a state that the interface does not represent, the model needs simplifying.

Tab switching deserves special attention. A hidden tab can delay timers. When the player returns, the game should either calculate from timestamps honestly or reset the round with a clear message. Quietly continuing from an unreliable state creates confusing scores.

Keep the result honest

A fair reaction game does not need a complex framework. It needs a clear state machine, a monotonic clock, consistent input handling, careful reset logic, and honest explanations.

The most important design choice is restraint. Do not claim scientific precision that the browser cannot provide. Do not turn a false start into a score. Do not hide the role of device latency. Give players a responsive tool, explain what it measures, and make the next attempt easy.

That approach produces a small game that feels dependable, which matters far more than making the interface look technically impressive.

DEV Community: Waqar ashraf