The Problem Nobody Talks About
When you take a reaction time test online, the number you see is not your reaction time. It is your reaction time plus your hardware latency.
This distinction matters more than most people realize. The total time between a stimulus appearing on screen and your response being registered includes several hardware-dependent stages:
Display latency. Your monitor does not show a frame the instant it is rendered. At 60Hz, a new frame appears every 16.7 milliseconds — meaning on average, the stimulus is delayed by about 8 ms just from display refresh timing. At 144Hz, that average drops to about 3.5 ms. At 240Hz, it is under 2 ms.
Panel processing time. Beyond refresh rate, monitors have inherent pixel response times (how quickly a pixel changes color) and internal image processing delays. A budget IPS panel might add 5-15 ms. A gaming TN panel might add 1-3 ms.
Input device latency. A wired mechanical keyboard typically registers a keypress in 1-5 ms. A wireless membrane keyboard might take 15-30 ms. A Bluetooth keyboard can add 20-40 ms. Mice show similar variation.
Operating system and browser overhead. Input events pass through the OS event queue and browser rendering pipeline before reaching the JavaScript timing code. This adds a variable 2-10 ms depending on system load, browser, and OS.
When you add these up, the total hardware overhead ranges from roughly 15 ms on a high-end gaming setup to 70 ms or more on a basic laptop with Bluetooth peripherals. That is a 55 ms spread — larger than the difference between an average person and a trained esports professional.
In other words, your hardware can matter more than your brain.
Why This Breaks Fair Comparison
Most online cognitive testing platforms, including the popular ones, report raw browser-measured times. This is the simplest and most transparent approach, but it has a critical flaw: scores are not comparable across different hardware configurations.
Consider two users who both have a true neural reaction time of 200 ms:
- User A is on a 240Hz gaming monitor, wired mechanical keyboard, desktop PC. Total hardware overhead: approximately 15 ms. Reported score: 215 ms.
- User B is on a 60Hz laptop screen, built-in keyboard, integrated graphics. Total hardware overhead: approximately 55 ms. Reported score: 255 ms.
User B appears 40 ms slower. On most platforms, that difference would place them in entirely different percentile brackets. But their actual cognitive speed is identical.
This is not a theoretical concern. It systematically biases leaderboards toward users with expensive hardware. It makes longitudinal tracking unreliable if you switch devices. And it undermines the fundamental promise of cognitive testing — that your score reflects your capabilities.
How Senwitt Solves This
Senwitt's hardware latency calibration system addresses this problem through a four-stage process. No additional hardware or manual configuration is required — the system runs automatically in the background.
Stage 1: Display Refresh Rate Detection
The first step is measuring the actual refresh rate of the user's display. Senwitt uses the requestAnimationFrame API to measure the interval between consecutive frame callbacks over a sampling window. By collecting dozens of frame-timing samples and computing the median interval, the system determines the effective refresh rate with high accuracy.
This is more reliable than reading the reported refresh rate from browser APIs (which can be inaccurate due to display scaling, battery-saving modes, or driver configurations). By measuring actual frame delivery, the system captures the real refresh behavior.
From the detected refresh rate, the system computes the expected average display latency contribution. At 60Hz, this is approximately 8.3 ms (half of one frame interval). At 144Hz, approximately 3.5 ms. At 240Hz, approximately 2.1 ms.
Stage 2: Input Lag Estimation
Input device latency is harder to measure directly from the browser — there is no API that reports how long a keypress took to travel from the physical switch to the JavaScript event handler. Instead, Senwitt uses device class fingerprinting.
The system collects signals from the browser environment: whether the device is a desktop or laptop (inferred from screen characteristics and user agent), whether input events arrive via standard HID or Bluetooth protocols (inferred from event timing jitter patterns), and the general device performance class (inferred from rendering benchmarks and frame consistency).
These signals are mapped to empirically validated latency estimates for common device classes. A wired desktop setup is assigned a lower input overhead than a wireless laptop setup. The estimates are conservative — they aim to correct the largest and most systematic sources of bias rather than achieving perfect per-device accuracy.
Stage 3: Latency Offset Subtraction
Once the display latency and input lag estimates are computed, they are summed into a total estimated hardware overhead. This overhead is then subtracted from the user's raw measured reaction time to produce a calibrated reaction time.
The formula in plain English:
Calibrated RT = Raw Measured RT - Estimated Display Latency - Estimated Input Lag
For example:
- Raw score: 255 ms
- Estimated display latency (60Hz panel): 12 ms
- Estimated input lag (laptop, built-in keyboard): 25 ms
- Calibrated score: 218 ms
This calibrated score is a closer approximation of the user's true neural reaction time — the time from photons hitting the retina to the motor cortex firing the finger muscles.
The calibration is not perfect. The estimates carry uncertainty, and individual devices within a class vary. But the goal is not perfection — it is reducing systematic bias. A 30 ms correction that is accurate to within 10 ms is far better than no correction at all.
Stage 4: Cohort Grouping
As an additional fairness layer, Senwitt groups users into device cohorts for leaderboard and percentile calculations. Users on similar hardware configurations are compared against each other, in addition to the global calibrated leaderboard.
This means you can see how your calibrated score ranks globally and how your raw score compares to others with similar setups. If you are on a 60Hz laptop, you can see where you stand among other 60Hz laptop users — an apples-to-apples comparison that requires no calibration at all.
Cohort grouping also serves as a validation mechanism. If the calibration is working correctly, the score distributions across cohorts should be roughly similar. If one cohort consistently shows higher or lower calibrated scores, it suggests the calibration estimates for that device class need adjustment.
The Calibration Algorithm in Plain English
Here is the full calibration flow as a user experiences it:
1. You open a test page. In the background, Senwitt begins measuring your frame rate by timing consecutive animation frames.
2. While you read the instructions and prepare, the system collects enough frame samples to determine your refresh rate (typically 1-2 seconds).
3. The system analyzes your browser environment to estimate your device class and input latency characteristics.
4. You take the test. Your raw reaction time is recorded.
5. The estimated hardware overhead is subtracted from your raw time to produce your calibrated score.
6. Both raw and calibrated scores are stored. Leaderboards default to calibrated scores. Your profile shows both.
The entire process is invisible. There is no setup screen, no "calibrate your device" button, no manual input required. It just works.
Impact on Fairness: Before vs. After
To illustrate the real-world impact, consider a sample of reaction time scores before and after calibration:
Before calibration (raw scores):
- Gaming desktop users average: 215 ms
- Standard desktop users average: 235 ms
- Laptop users average: 260 ms
- Tablet users average: 285 ms
The 70 ms gap between gaming desktops and tablets suggests vastly different cognitive speeds. But much of this gap is hardware.
After calibration:
- Gaming desktop users average: 208 ms
- Standard desktop users average: 213 ms
- Laptop users average: 218 ms
- Tablet users average: 224 ms
The gap narrows from 70 ms to 16 ms. The remaining difference likely reflects genuine population differences (gamers who invest in hardware may also invest more in cognitive training) rather than measurement artifact.
This is what fairer measurement looks like. Not perfect equality, but the removal of the largest systematic biases.
Limitations and Honest Caveats
No calibration system is flawless. Here are the known limitations:
Estimation, not measurement. We estimate hardware latency from indirect signals rather than measuring it directly. Individual devices within a class vary. A high-end gaming laptop and a budget Chromebook both register as "laptop" but have very different latency profiles. We are working on finer-grained device classification.
Browser variability. JavaScript timing precision varies across browsers. Chrome and Firefox handle event timing differently. Safari on macOS has distinct frame scheduling behavior. We account for known browser-specific offsets, but edge cases exist.
Non-standard configurations. Users with unusual setups — external monitors on laptops, gaming mice with built-in keyboards, or virtual desktop environments — may receive less accurate calibration. These cases are detectable and flagged as lower-confidence estimates.
No absolute ground truth. Without a hardware-level measurement device (like a photodiode taped to the screen), we cannot know the exact hardware latency for any given user. Our calibration is validated against measured latencies from a reference device library, but it is an approximation.
Future Improvements
The calibration system is designed to improve over time. We are exploring several enhancements:
Crowd-sourced validation. Users who measure their hardware latency independently (using photodiode tools or specialized apps) can contribute their data to refine our estimation models.
Machine learning models. As we collect more data pairing device fingerprints with known latencies, we can train increasingly accurate prediction models.
WebHID and WebUSB integration. Emerging browser APIs may eventually allow more direct measurement of input device characteristics, reducing reliance on fingerprinting heuristics.
Cross-session consistency tracking. By analyzing a user's score variance across sessions, the system can flag potential calibration inaccuracies and self-correct.
Conclusion
Hardware latency is the single largest source of unfairness in online cognitive testing. A 55 ms spread between devices dwarfs the improvements most people work months to achieve. Ignoring it means your leaderboard ranking reflects your equipment as much as your ability.
Senwitt's calibration system does not eliminate hardware effects entirely — but it reduces them from the dominant factor to a minor one. Combined with cohort grouping, it provides the fairest cross-device comparison available in a browser-based cognitive testing platform.
Your score should reflect your brain, not your budget.
For a deeper technical discussion of our measurement methodology, visit the full methodology page.