How Browser Timing Tests Measure Milliseconds
When a browser says “241 ms,” it really did measure an interval with a high-resolution clock. The tricky part is understanding what the interval starts and ends on.
The browser has a high-resolution monotonic clock
Modern web apps can use performance.now(), which provides a high-resolution timestamp designed for measuring durations. Unlike wall-clock time, it is monotonic: it does not jump backwards because a system clock was adjusted.
Timing a reaction test
A simple implementation records a timestamp when the game enters the GO state, then records another when the click event arrives. The difference is displayed as the reaction interval.
The visual signal is not instantaneous
Changing a CSS class or DOM element tells the browser what should change. The browser still has to render a frame and the display has to present it. That means the human may see the signal slightly after the JavaScript timestamp was taken.
Input events also travel through a stack
A physical mouse switch or touchscreen sensor is processed by hardware, drivers, the operating system and the browser before JavaScript receives an event. The game therefore measures an end-to-end interaction, not only neural reaction.
Why this is still useful
Noise does not make the test meaningless. If the same browser, device and setup are used repeatedly, the system latency is relatively stable enough for rough personal comparisons. The mistake is pretending the number is laboratory-grade or perfectly portable across devices.
What we do at EgoTools
- Use high-resolution timing APIs where appropriate.
- Separate false starts from valid reaction scores.
- Store local bests for same-device comparison.
- Describe hardware and browser limitations on the tool page.
- Avoid diagnostic claims.
Try it yourself
Use the explanation above, then run the tool and compare your own repeated results.
See the timing in action →