Speed
Aim Trainer
Hit 12 targets as fast as you can. It takes about half a minute.
Your score is how much aiming you got done per second, not how many milliseconds each target took. That sounds like a technicality and isn't: a milliseconds score mostly measures how big your browser window is, so it can't be compared with anyone else's. This one can. Your misses are shown next to it, and the section below explains exactly what was and wasn't counted.
Aim · 12 timed moves
Tap or click the blue circle. The moment you do, the next circle turns blue. Hit that one. Keep going as fast as you can.
The dashed circle is where the next target will be, so you never have to look for it.
Your first click just gets you started and isn't timed. The 12 after it are.
What your equipment contributed
- Display frame period
- does not applyboth ends of the clock are input events
- Constant input lag
- cancelsit delays the start and the stop equally
- Polling jitter adds
- morenot measurable from a web page
This is the one test on BlinkBench where the equipment mostly gets out of the way, and it is worth saying why. Our reaction test times from a frame the display presented to an event your mouse sent, so the frame period and the whole input path land inside the score. Here the clock starts on one pointer event and stops on the next, both travelling the same path — so a steady input lag delays both ends by the same amount and drops out of the subtraction. What does not drop out is the jitter: your pointer is sampled at some interval we cannot see, so each timestamp lands up to one sampling interval late by a different amount. We state that rather than invent a figure for it. The larger limit on this page is not timing at all — it is that your window decides how far apart the targets can be, and therefore how much of the difficulty range the measurement got to cover.
How this is measured
What starts the clock
Your pointerdown on the previous target. Not the appearance of the new one — and that distinction is the reason the next target is always drawn, faintly, before you get to it. Because you can already see where you are going, the interval being timed contains travel and nothing else. If the target only appeared once you arrived, every measurement would silently include the time it took you to find it, and the result would be a reaction test wearing an aim test's name.
What stops it
Your next pointerdown, anywhere in the panel. The timestamp is taken as the very first statement in the handler, before we read the panel's position, before we work out whether you hit anything, and before any state changes. Every time on this page comes from performance.now(), a monotonic clock, rather than the wall clock.
How a move becomes a difficulty
For each move we take the distance from where you actually clicked last to the centre of the new target, and the target's diameter, both in CSS pixels. The difficulty in bits is log2(distance / width + 1) — the Shannon formulation, which is what the reference below recommends because it cannot go negative when a target is wider than the move to it. Throughput is that difficulty divided by the seconds it took. Because difficulty is a ratio, it does not change when the whole layout is scaled up or down, which is precisely what makes it worth reporting.
How the moves are combined
We report the median throughput across your scored moves, not the mean — the same rule every timing test on this site follows, because one fumbled move would drag an average noticeably. Targets are drawn at three different sizes so that difficulty varies across the run; a throughput estimated at a single difficulty has nothing holding it up. Every individual move is listed with its own time and its own difficulty.
What gets discarded, and why you are told
A move faster than 100 ms was already under way before that target became the target, and one slower than 3 seconds stopped being a move at all — both are timed, shown, and excluded from the throughput with the reason named. A missed target is treated the same way: still timed, still listed, but no difficulty was actually achieved, so it cannot contribute a throughput. The miss count is shown next to your score rather than buried, because a fast run bought with misses is not a fast run.
Where this departs from the standard
Four places, and none of them are hidden. Targets are placed at random rather than in the standard's fixed ring, so distances are not controlled conditions. There is one short run rather than repeated blocks per condition. We report a median rather than a mean. And we do not apply the effective-width correction described below, because a 12-move run does not give enough hit-coordinate spread to compute one. Any of those four is enough reason not to treat your figure as a laboratory result.
How your result compares
There is a defensible reference range for this measure, so here it is. A review of 27 years of Fitts' law research in human–computer interaction found that studies which followed the ISO 9241-9 evaluation procedure reported mouse throughput between 3.7 and 4.9 bits per second. Studies that did not follow it reported anywhere from 2.6 to 12.5 bits per second — for the same device. That spread is the entire argument for having a standard, and it is also a warning about any pointing figure quoted without one.
A mouse range, and a laboratory one
3.7–4.9 bits/s describes a mouse on calibrated equipment running the standard's ring task. If you took this test with a trackpad, a stylus or a finger, that range is not yours — those devices have their own throughputs and we are not going to guess them for you. Even with a mouse, the four departures listed above sit between your number and theirs. Read it as a bearing, not a placement.
The same review sets out the effective target width adjustment, which rescales each target after the fact from the spread of where clicks actually landed, normalising every participant to a 4% error rate before throughput is computed. It exists because speed and accuracy trade off directly, so an unadjusted throughput can always be inflated by aiming less carefully. We do not apply it — 12 moves across three target sizes do not supply the hit-coordinate distribution it needs, and computing it from too little data would produce a standard-looking number that isn't one. Your raw error count is shown beside your score instead, which is the honest version of the same information.
No percentile is shown, here or anywhere on this site, unless a published source supports one. The review reports a range of study means, not the distribution of individual people within them, so there is nothing to place you on. A percentile computed from BlinkBench's own visitors would be worse still: that sample is self-selected, unvetted, and spread across pointing devices we know nothing about.
Source: Soukoreff, R. W., & MacKenzie, I. S. (2004). Towards a standard for pointing device evaluation, perspectives on 27 years of Fitts' law research in HCI. International Journal of Human-Computer Studies, 61(6), 751–789.
Last reviewed: July 2026
Frequently asked questions
Why is the score in bits per second rather than milliseconds?
Because milliseconds would be a measurement of your browser window, not of you. How long a move takes depends on how far it was and how big the target was, and on a web page both of those are decided by whatever size your window happens to be — so the same person gets a different number on a phone and on a 32-inch monitor. Fitts' law fixes this by scoring the difficulty of each move as a ratio of distance to target width, which is scale-free, and dividing it by the time taken. That gives bits per second, and it is the figure published pointing studies actually report. The median movement time is shown too, clearly labelled as the number that is not comparable with anyone else's.
Why is my throughput lower than the 3.7–4.9 bits/s range you cite?
Most likely because this is not the standard's task and you are not on the standard's rig. ISO 9241-9 uses a fixed ring of targets at set distances and sizes, run on calibrated equipment, with the throughput averaged over several blocks per condition. This test drops targets at random inside your browser window, over one short run, on hardware we know nothing about. It also gives you a smaller range of difficulties to work across than a laboratory setup does — the bar under your score shows exactly how much of that range your screen could present. Read the published range as a bearing, not as a pass mark.
Does a gaming mouse, a higher DPI or a higher polling rate improve this score?
Some of it is real and some of it is not measured here. A higher polling rate genuinely reduces the jitter in when your clicks are timestamped, and pointer acceleration settings change how a given hand movement maps onto screen distance — both of those touch the number. But note what this test does and does not include: the clock starts on one click and stops on the next, so any steady lag in your input path delays the start and the stop by the same amount and cancels out of the result. That is why this page does not carry the same equipment caveat our reaction time test does. Comparing your own runs across two different pointing devices is still not meaningful — a mouse, a trackpad and a finger are three different instruments.
Why do missed targets count against me instead of just making me slower?
Because otherwise the fastest strategy would be to click at random. Speed and accuracy trade off directly in pointing: you can always go faster by aiming less carefully, so a time-only score rewards missing. The standard handles this with an "effective target width" adjustment, which resizes each target after the fact based on where your clicks actually landed, normalising everyone to a 4% error rate. We do not apply that adjustment — it needs the spread of hit coordinates across many trials at each condition, which a twelve-move run does not supply. So we do the honest alternative: a missed target is timed, shown, and excluded from throughput, and the error count sits directly beside the score. A throughput figure with a high miss count next to it should be read as inflated.