Browser reaction time tests can be useful, but they are not lab instruments by default. A browser can timestamp input events, align visual changes with the rendering cycle, and schedule audio. It cannot directly observe your monitor's first photon, your retina, your muscle activation, or the inside of your Bluetooth headset.
The difference between a toy test and a useful test is whether it admits those boundaries — which is exactly what PulsarMS documents on its how we measure page.
What browsers can measure well
Browsers can provide:
- high-resolution timing in modern contexts,
- input event timestamps,
- frame callbacks through
requestAnimationFrame, - audio scheduling through the Web Audio API,
- stable local comparisons when hardware is unchanged.
That is enough to build a good reaction time test for personal baselines and same-setup comparison.
What browsers cannot know
Browsers cannot directly know:
- exact physical display scanout,
- pixel response time,
- display processing lag,
- exact sound leaving your headphones,
- Bluetooth codec buffering,
- muscle activation start,
- neural processing time alone.
That is why a web test should not claim pure neural reaction time. It measures a practical response loop through the browser and hardware.
Why PulsarMS uses confidence bands
PulsarMS reports a confidence band because millisecond precision without uncertainty is misleading. A 60 Hz visual result has more display-side uncertainty than a 600 Hz result. An audio result through Bluetooth has more output uncertainty than a wired result. A tiny improvement that sits inside the confidence band is not yet a real improvement.
Every limit in the list above widens that band rather than disappearing. A low refresh rate, a Bluetooth output path, or a throttled background tab all show up as more uncertainty around the same browser-observed onset timestamp — not as a hidden "true" number the page is quietly withholding. That is the honest version of browser accuracy: measure carefully, then show how wide the result really is.
Read reaction time score interpretation before judging small changes.
Browser accuracy checklist
For a cleaner browser test:
- Use a foreground tab.
- Avoid battery saver.
- Use a stable input device.
- Use a high-refresh monitor for visual tests.
- Use wired output for audio tests.
- Compare medians across repeated sessions.
- Keep hardware notes with every result.
Sources & context
For browser APIs, see MDN's requestAnimationFrame and Web Audio API references. Human Benchmark's reaction time test also notes that computer and monitor latency affect scores. PulsarMS's position is simple: browser tests are valuable when they are transparent about what they can and cannot observe — the full account of where PulsarMS draws that line is on how we measure.