Skip to content
Back to Learn

Web-browser RT timing — what you can and cannot measure

Reaction-time data in the browser is useful for a much narrower set of questions than most researchers realise. The pipeline between a key press and a JavaScript event fires through the USB driver, the OS compositor, the browser's event queue, and V8 — each layer adding a few milliseconds of latency and a handful of milliseconds of jitter.

Where the noise comes from

1. Display refresh. A 60 Hz screen paints every 16.67 ms. Stimulus onset is quantised to whichever frame the browser managed to catch. Without a paint anchor you cannot know whether »time zero« is when React setState ran, when the browser decided to paint, or when the pixels actually changed colour.

2. Event-loop latency. Long tasks — layout, image decode, background workers — can delay the keydown handler by tens of milliseconds on slow hardware.

3. Input device. USB keyboards poll every 1–8 ms; Bluetooth keyboards can be much worse. Touch screens fire synthetic click events 300 ms after touchstart unless touch-action is declared.

What SciBLIND does about it

  • Double-rAF paint anchor. RT clocks from the second requestAnimationFrame after a stimulus component mounts, so we count from an actual paint, not a setState.
  • Timing audit grade. Every published study gets a Reimers-Stewart grade (A / B / C / D) stamped on the export. If your study is below »A«, report the grade alongside your results.
  • Sub-two-frame flag. Any RT under ~32 ms is marked with _rt_quality = 'too_fast' on export — almost certainly a paint race, not a human response.

What you can trust

Differences ≥25 ms between conditions reproduce cleanly across browsers, machines, and OS combinations. Classical effects (Stroop interference ~80 ms, Simon effect ~30 ms, lexical decision frequency ~40 ms) are all well within the browser's resolution.

What you cannot

Sub-10 ms effects — mental-chronometry decomposition, subliminal priming latencies, motor-program timing — need lab-grade equipment. The browser cannot deliver that precision, and no amount of audit software can recover what the operating system's compositor discarded.

Reference

Reimers, S., & Stewart, N. (2015). Presentation and response timing accuracy in Adobe Flash and HTML5/JavaScript Web experiments. Behavior Research Methods, 47(2), 309–327.

Discussion

No comments yet — be the first to weigh in.

Sign in to join the discussion. The thread below is public.

Loading comments…