Methodology · open by default
How we measure reaction time
Almost every reaction-time site online shows you a single number and hides how much it could be wrong. We do the opposite. Here is exactly how WiredReflex measures — and the limits we're honest about.
01The two timestamps that matter
A reaction time is just response time − stimulus onset. The accuracy of that number depends entirely on how precisely we can timestamp those two events.
Read from the input event's own event.timeStamp — the moment the browser created the event, not the moment our code happened to run. That shaves off handler and dispatch jitter.
The hard part — and it differs between visual and audio. The next two sections are exactly that story.
02Visual: we timestamp the painted frame
When the field flips from red to green, we paint the change inside a requestAnimationFrame callback and record that callback's timestamp — the frame we actually painted, not the frame we requested. Getting this wrong adds a silent ~16.7 ms bias on a 60 Hz display, which is exactly the bug we avoid.
The unavoidable limit: your monitor only refreshes every 16.7 ms at 60 Hz, 6.9 ms at 144 Hz, 4.2 ms at 240 Hz, and 1.7 ms at 600 Hz. There are also a few more milliseconds of GPU, compositor and panel delay the browser cannot directly measure. The visual result uses a heuristic of about ± half a refresh plus timer granularity. This is not a statistical confidence interval or a bound on physical display and input delay.
03Audio: faster for you, harder for us
We schedule each cue on the audio clock and estimate its onset in the clock used by your input event. A usable Web Audio timestamp pair or a qualified fallback supplies that estimate; neither measures when sound reaches your ears. Browser implementations and privacy protections can change clock granularity or standardize latency readings. Bluetooth can add hidden output delay, but wired output is not automatically calibrated either.
Audio results remain relative. Keep the browser, output device, cue and input method unchanged when repeating. A lower result or output-delay reading in another browser is not evidence of faster reactions or better measurement. Coarse or unresolved clocks, estimated onset mapping, and interruptions must remain visible limitations.
04Resolution is not accuracy
Response SD describes variation across trials. Observed clock steps describe the readings exposed by the browser. Physical display, audio and input delays are a separate, uncalibrated quantity. These are not interchangeable. The visual ± remains a heuristic, not a confidence interval. For audio we report timing context rather than turning half a reported output latency into a misleading ± error bar. A clock probe that observes no tick has unresolved precision; cross-origin isolation alone does not prove high-resolution audio timing.
05Our scoring core is auditable
The median, percentiles and plausibility checks run in a small Rust core compiled to WebAssembly (~128 KB) — the same logic on your device and re-run on our server. The trial schedule is generated deterministically from a seed, so the server can reproduce exactly what you saw and re-score your raw trials instead of trusting any number your browser sends.
06Anti-cheat
Leaderboard runs are re-scored server-side from raw per-trial data and screened behaviorally, not by a speed prior. We deliberately don't discard results at the textbook ~100 ms “anticipation” line — genuinely fast people exist, and this test was built to measure them. Instead: responses below the ~50 ms physical limit (stimulus-to-muscle transit) are excluded as non-reactions; results in the 50–100 ms band count and rank, flagged “exceptional” and verified by the run's own evidence — the false-start rate against 1.5–4.5 s randomized waits, and variance. A fast median combined with a high early-click rate is guessing and doesn't rank; a fast median with a clean false-start record does. There are no catch trials: they inject a go/no-go decision into a pure speed measure and make honest users hesitate. Runs with near-zero variance or excessive false starts don't rank at any speed. It's not unbeatable — no web leaderboard is — but it stops casual fakes cheaply without punishing genuine speed.
07Measuring the Arena games
The Arena is a set of short training games — aim, tracking, choice speed, impulse control, focus — that log every action and score it with the same honesty as the reaction test. It is built for training and same-setup competition, not as a lab-grade replacement for the reaction-time test. There is more hardware in the loop — mouse, sensitivity, OS pointer settings — so Arena results are even more same-setup relative, and the engine adds about one extra frame of render-and-present time versus the precision test's bare timing path.
Fitts's law scores a flick by how much aiming information you push per second, using the spread of your clicks as the real target size — speed and accuracy count together. Movement time is browser-observed; the value is same-setup relative. Read more →
Signal-detection theory separates how cleanly you tell go from no-go from how trigger-happy you are. It needs enough of both trial types to settle, and it describes discrimination on this task — not a general attention score. Read more →
The EZ-diffusion model estimates how fast you gather evidence, separated from how cautious you are. It is a coarse estimate — read it as a direction, not a lab value. Read more →
Your aim-lock uptime: the share of the round your reticle sat on the target. Resolution is capped by your pointer sample rate; screen-space and same-setup relative; scoring still in calibration. Read more →
Flick time, overshoot, corrective sub-movements and path efficiency come from the pointer position the browser reports — the pointer, not your hand. We record the achieved sample rate and widen the band when it's sparse.
Arena metrics do not come with a calibrated timing-error band. Submitted runs are re-scored server-side from raw per-action telemetry — with extra cursor-path checks, so a flick with no approach movement, or a pointer that jumps faster than a hand can move, does not rank. Ranks stay provisional (beta) until the scoring is tuned against real pilot data.
08Your data
There are no accounts, no cookies, and no third-party trackers here (page counts are cookieless). What leaves your machine is decided by what you do:
Nothing leaves your browser. Scoring runs locally (the wasm core), and your run history is saved in your browser's storage only.
Submitting sends the raw per-trial timestamps and seed (so the server can re-score the run instead of trusting a claimed number), your chosen display name, and the timing context (including refresh rate and legacy timing estimates). Two operational fields ride along and decay: a salted IP hash (rate limiting and one-entry-per-player stats) and a coarse device class like “Chrome 126 · Windows” — both are deleted after 30 days. The raw trials stay, unlinkable, so any score on the board remains auditable forever.
Prefer not to be on a board but happy to help the science? On any result you can donate the run anonymously: the raw trials go in with no name, no IP hash, and no device string — nothing to link it to you, ever — flagged donated so it never ranks. It exists for one purpose: building the population distribution that will let everyone see where a score sits (“faster than X%”) on honest, real data instead of guessed anchors.
Pick any display name — it's the only identity the board ever shows, so don't put anything in it you wouldn't publish.
A precise-looking number is not proof of accurate physical timing. Browser results depend on the browser, device and input path; there is no universal offset to subtract. Keep your setup fixed, read the timing warnings and compare repeated runs without treating a lower number as proof of a faster nervous system.