What a browser is really timing — and how much of the result is not you.
Take three typing tests and you will get three different speeds. Take three reaction-time tests and the spread can be larger still. Neither is evidence that the tests are broken; it is evidence that "how fast are you" is a less well-defined question than it appears, and that a browser measures your equipment alongside you.
Typing speed is quoted in words per minute, but a "word" here is not a word. The standard definition, used since mechanical typewriter testing, is that one word equals five characters, including spaces and punctuation.
This is a deliberate normalisation. Real words vary from one letter to fifteen, so counting them would make a test's score depend on its vocabulary. Fixing a word at five characters means a passage of short words and one of long words score comparably.
gross WPM = (characters typed / 5) / minutes elapsedSo typing 250 characters in one minute is 50 WPM regardless of how many actual words that was.
Gross WPM ignores mistakes entirely, which makes it easy to inflate by typing quickly and badly. Net WPM applies a penalty:
net WPM = gross WPM - (uncorrected errors / minutes elapsed)Each uncorrected error costs one word per minute. A test reporting 80 WPM gross with eight errors in a minute is reporting 72 net — and net is the figure worth caring about, since text you have to go back and fix was not really produced at that speed.
This is the first reason tests disagree: some report gross, some net, and many do not say which.
None of these is wrong. They are simply different measurements sharing a name, which is why a score is only meaningful alongside the test that produced it.
A reaction test looks trivial — note when the stimulus appears, note when the click arrives, subtract. But the interval it captures contains considerably more than your nervous system.
Human simple visual reaction time — one stimulus, one response, no decision — is genuinely around 200 to 250 milliseconds for a healthy adult. Anything a browser reports below roughly 150 ms indicates anticipation rather than reaction.
Between the code deciding to show a stimulus and your click being recorded, the following accumulate:
| Stage | Typical cost |
|---|---|
| Browser paints the next frame | 0–16.7 ms at 60 Hz |
| Display processing and pixel response | 5–40 ms, depending heavily on the panel |
| Your actual reaction | 200–250 ms |
| Switch travel and debounce | 5–20 ms |
| USB polling interval | 1–8 ms |
| Event dispatch and handler scheduling | 1–10 ms |
The overhead totals somewhere between roughly 15 and 90 ms depending entirely on hardware. A gaming monitor at 144 Hz with a wired mouse sits at the bottom of that range; a budget laptop with a 60 Hz panel and a Bluetooth mouse sits near the top.
So a browser reaction test measures you plus your equipment, and the equipment contribution can exceed 30% of the difference between a "good" and an "average" score. Comparing your result against a stranger's largely compares hardware.
A stimulus can only appear when a frame is drawn. At 60 Hz that is every 16.7 ms, so the true appearance time is quantised to that grid and carries up to 16.7 ms of uncertainty before anything else. No amount of precise timing in software removes it — the screen simply cannot show the stimulus sooner.
Browsers once offered microsecond timing via performance.now(). Following the Spectre class of attacks — which used high-resolution timers to infer memory contents through cache timing — browsers deliberately coarsened it, typically to somewhere between 0.1 and 5 ms, sometimes with added jitter.
For measuring human reaction this is irrelevant; a millisecond of timer noise is nothing against 200 ms of human latency. It is worth knowing simply because it means a browser cannot honestly report reaction time to three decimal places, and any test that does is displaying precision it does not have.
Click-rate tests measure something more mechanical, and the constraints shift accordingly. Sustained alternate-finger clicking of around 6–8 per second is typical; higher rates generally involve specific techniques rather than faster fingers.
Two hardware limits apply. Mice have a debounce interval — a few milliseconds after a click during which further transitions are ignored, to stop a physically bouncing switch registering twice. This caps the maximum genuine rate. And USB polling means clicks are collected at fixed intervals rather than instantaneously, so two clicks within one interval may be reported together.
Consequently a click test also measures the mouse. A high polling rate and low debounce will produce better numbers with identical fingers.
The honest position: they are good for comparing you against yourself, on the same machine, over time. All the hardware overhead is constant in that comparison, so a genuine improvement shows up clearly.
They are poor for comparing against other people, because you are also comparing monitors, input devices and browsers. And leaderboards are worth treating with scepticism, since the systematic advantages above are real and automation is trivial.
For typing specifically, a few things do measure real progress: track net rather than gross WPM, use the same test repeatedly rather than shopping for a flattering one, and watch accuracy first — speed gained at the cost of errors is not gained at all, because correction time is part of real-world throughput.
One practical note for reaction tests: take at least five attempts and use the median rather than the best. A single fast result is as likely to be a lucky anticipation as a genuine reaction, and the median is far more stable against both flukes and lapses.