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 PulsarMS 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 square 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 literally cannot see. So we report a confidence of about ± half a refresh, and we record your refresh rate with every result.
03Audio: faster for you, harder for us
Your brain reacts to sound faster than to light, but browsers measure audio worse. We schedule the click sample-accurately and convert it into the same clock as your keypress using the Web Audio output timestamp. The catch: the true delay from “audio leaves the app” to “sound leaves the speaker” is an estimate browsers report unreliably — and Bluetooth can add hidden output delay, sometimes large enough to distort the reaction itself.
So we treat audio results as a relative measure (great for tracking your own progress and same-machine competition), warn you to use wired output, and never pretend an absolute audio number is exact.
04Why there's a ± on every result
Because there should be. The ± confidence band is computed per session from your display refresh rate (visual) or audio path (audio) plus the measured resolution of your browser's clock. It describes uncertainty around the browser-observed onset timestamp; physical display scanout, panel response and uncalibrated audio-device delay can still sit outside that band.
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 physicallimit (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 witha 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.
Every Arena result carries the same ± confidence framing and is 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.
A native instrument measures to well under a millisecond. A browser cannot — the gap is roughly 10–40 ms. What a browser cando is measure carefully, report its uncertainty, and stay consistent on your machine. That's what we built.