What a browser reaction time test measures
A reaction time test measures the interval between a browser-observed start reference and your response arriving. In Testpartout, the start reference is the point immediately after the signal state is committed for the upcoming frame; the response is the moment an input event for your click, tap or key press is delivered to the page. The result is the distance between those two browser timestamps — not a direct reading of photon onset, nerve conduction or brain activity.
That distinction matters more than it sounds. The number you see is the total time taken by a chain: your eye and brain notice the change, your hand moves, the input device reports the action, the operating system and browser deliver it, and the page timestamps it. A browser test measures the whole chain end to end, because that is the only thing it can honestly see.
The stimulus and the response
On Testpartout the stimulus is visual: a waiting state changes into a clearly different “go” state. The response can be a pointer press or a key press, which makes the test usable on a desktop with a mouse, on a laptop trackpad, and on a touchscreen.
Why the wait is randomised
Before the stimulus appears there is a randomised delay — in the current implementation between roughly 1.5 and 4.5 seconds. A fixed delay would be easy to learn: after a few attempts you would stop reacting and start predicting, and the test would measure your sense of rhythm instead of your response. Randomising the wait keeps the stimulus genuinely unexpected across attempts.
Why a press, not a release
The response is recorded on the press event rather than on release, because pressing is the earliest unambiguous signal that you have reacted. How long you keep the button held down is irrelevant to the measurement and varies wildly between people and devices.
Why the test uses several attempts
A single attempt is only one sample. Human response times can move from trial to trial for reasons that have little to do with ability: a lapse in attention, an unusually short or long wait, or a fingertip starting from a slightly different position. Several attempts make the result less dependent on one unusually fast or slow response.
The Testpartout test therefore collects several valid attempts in a session and reports the average, so one unusually lucky or unusually distracted trial does not define the result. Seeing the individual attempts alongside the average is useful too: a tight cluster suggests you were concentrating consistently, while a wide spread suggests the session was not a clean measurement and is worth repeating.
False starts and why they are excluded
A false start is a response that arrives before the stimulus appears. It is not a fast reaction — there was nothing yet to react to. Counting it would produce an impossibly low number and quietly corrupt the average, so a false start is detected, excluded from the results, and the attempt is restarted rather than scored.
Anticipating is easy to do accidentally, particularly if you have already run several attempts and your hand starts moving on expectation. Excluding those attempts is what keeps the reported average a measurement rather than a guessing game.
Timing with performance.now()
Timing is anchored on performance.now(), the browser’s monotonic high-resolution clock. Two properties make it the right choice. It is monotonic, so it cannot jump backwards if the system clock is adjusted or a time server syncs mid-session, and it is expressed as a high-resolution offset rather than a calendar time, so elapsed intervals are measured directly instead of being subtracted from two wall-clock readings.
Modern browsers deliberately reduce the resolution of this clock and add small amounts of jitter as a defence against timing-based fingerprinting and side-channel attacks. That places a floor on precision that no web page can get under. It is small compared with human response times, but it is one reason a browser measurement should not be presented as laboratory-grade.
Frame-aligned stimulus presentation
A stimulus is not physically visible the instant code asks for it to change. The change has to be committed, painted by the browser and then scanned out to the display, which happens on the display’s refresh cycle. If the test used an earlier code timestamp, it could include an extra slice of waiting-to-be-painted time in the result.
The implementation therefore uses a browser-observed frame-aligned start reference rather than the earlier code path that requests the change. In practice, the signal state is committed synchronously during an animation-frame callback and performance.now()is read immediately after that commit. This reduces one avoidable source of timing error, but it does not equal physical photon onset and it cannot remove the display’s own pipeline: on a 60 Hz screen a new frame appears at most every ~16.7 ms, and panels may add their own processing delay on top.
Browser, display and input latency are part of the number
Between the stimulus being drawn and your press being timestamped, several components add delay that belongs to the equipment rather than to you:
- Display refresh and processing. Refresh rate sets how often a new image can appear; panel processing, overdrive and scaling add more.
- Input device polling. A mouse or keyboard reports at a fixed rate; a touchscreen samples touches at its own rate. Your press waits for the next report.
- Wireless links. Bluetooth and low-power wireless receivers typically add more latency than a wired connection.
- Operating system and browser scheduling. Event delivery competes with everything else the machine is doing, including other browser tabs.
None of this is a flaw in the test. It is what “reaction time in a browser” means, and it is why the platform-wide methodology states plainly that your environment affects every result.
Why this is not pure biological reaction time
Pure biological reaction time — the interval from a stimulus reaching your retina to a muscle beginning to contract — requires instruments a web page does not have: calibrated stimulus onset, direct measurement of muscle activation, and a controlled environment. A browser test measures a task performance that includes your biology plus the whole hardware and software path around it.
Treat the result as a repeatable performance score for the combination of you and this device, not a physiological constant. Testpartout publishes no “good” or “bad” bands, no percentiles and no population averages for it, because it holds no real aggregated data to derive them from, and inventing them would be worse than showing nothing.
Why same-device comparisons are the meaningful ones
Because some of the measured interval comes from the equipment, comparing your number with someone else’s from a different machine compares two different measurement chains. A noticeable gap between two people may come partly from the display, input device, browser, operating system or the person using them.
Comparisons where the equipment is held constant are more informative: the same device, the same browser, the same input method, and ideally similar conditions. Under those conditions a change in the result is more likely to reflect attention, fatigue, practice or other session factors than a different hardware path. That is why the test keeps a personal best locally on your device instead of placing you on a leaderboard.
Practical factors that move your result
- Input method. Mouse, trackpad, keyboard and touchscreen have genuinely different latencies. Keep one within a session.
- Hand position. A finger already resting on the button may respond sooner than one hovering above it.
- Attention and expectation. Actively waiting for the stimulus differs from glancing away between attempts.
- System load. Heavy background work, many open tabs, or a browser throttling an inactive tab all add delay. The test cancels a run if the page stops being visible, precisely because a backgrounded page is no longer being measured fairly.
- Fatigue, caffeine, time of day. These can influence performance; how much, and in which direction, may differ by person, and we make no claims about it.
- Practice. Early sessions may improve through familiarity with the interface, not necessarily through any change in your reflexes.
Reading your result sensibly
Run several sessions on the same device before drawing any conclusion, look at the spread of attempts rather than only the average, and treat your own previous runs as the baseline. Documented for exactly this test, including its attempt count and exclusion rules, is the Reaction Time Test page itself; the platform-wide rules that apply to it are on the methodology page.