MethodologyUpdated
What a Browser-Based Hardware Test Can and Can't Measure
How TryYourGear's 12 browser tests work: what each observes, what it can't measure and what result it gives, from key codes to refresh rate and latency.
TryYourGear is made of web pages, so it can only work with what your browser exposes to a page: events (a key went down), streams (audio from a microphone) and values the browser reports (a camera's resolution). It can't read your hardware directly. This page goes through the twelve tests one by one: what each observes, what it doesn't measure, and what kind of result you are looking at.
The descriptions come from how the tests are built. If a test can't show something, it is listed here.
Four kinds of results
- Observation. The browser reported an event or a state and TryYourGear shows it as it is: a key code, a button press, a controller axis.
- Computation. TryYourGear calculates a number from observations or timings: words per minute, clicks per second, an estimated refresh rate, an average latency.
- Browser-reported value. The browser tells TryYourGear a property of a device stream, such as a camera's resolution. TryYourGear doesn't measure it.
- Your judgment. The test produces a sound or an image and you decide what you heard or saw.
Only some results are numbers, and a number is not automatically a measurement of your hardware.
The twelve tests at a glance
| Test | What it observes or measures | What it does not measure | Type of result |
|---|---|---|---|
| Keyboard Test | Every key press and release the browser reports, identified by KeyboardEvent.code; which keys are down at the same time; which keys you have pressed at least once (on a simplified ANSI-style layout of 73 keys drawn on screen, without numeric keypad, arrows or navigation keys; other keys still appear in the last-events list); and whether the browser flags a press as auto-repeat. | The character a key produces or your language layout. Anything below the browser: a key that registers but feels damaged, or why a key is missing when several are held. While the test is open it blocks the default action of Space, Tab and F1–F12. | Observation |
| Mouse Test | Button presses (mousedown) for left, middle, right, back and forward; wheel direction; the time between your last two left presses; and how many mousemove events the browser delivers per second. | Button releases, click or dblclick events, DPI, or the mouse's real polling rate: the movement count is what the browser delivers to the page, not what the mouse sends. Nor your system's double-click speed, drivers or macros. Some drivers send back and forward as keyboard shortcuts, which this test can't see. | Observation, plus one computed interval |
| Click Speed Test | How many click events land in the box during 5, 10, 15 or 30 seconds. CPS is the clicks divided by the duration actually measured with performance.now(), not the nominal one. Your best score is stored only in your browser. | Mouse polling rate, DPI or switch speed. The result also depends on the input method (mouse, trackpad, touchscreen), the browser and the attempt. | Computation |
| Reaction Time Test | The time between the moment the page shows the stimulus and the moment the browser receives your click, tap or Space key. Five valid rounds, each after a random wait of 1.5 to 5 seconds; responding early repeats the round. | Your pure biological reaction time. The number includes display and input delays, the browser and the operating system, so compare results only on the same device and browser. | Computation (includes system delays) |
| Typing Speed Test | The text you type into the box (pasting is disabled). WPM is correctly placed characters ÷ 5 ÷ minutes, from your first keystroke to the last character. Accuracy is the share of typed characters that match the passage, and corrections counts Backspace presses. | A standardized or certified typing score. Accuracy compares the final text, so mistakes you fixed don't lower it: they show up as corrections. Autocorrect, input methods and extensions can interfere. | Computation |
| Controller & Gamepad Test | What the browser's Gamepad API reports, read every 50 ms: each button's pressed state and value, the analog axes as numbers from −1 to 1 (the sticks' x and y with two decimals), and the controller's name string. Button names follow the browser's “standard” layout. | Drift diagnosis, calibration, wear, vibration, latency or battery. A controller shows up only after you press a button on it, a browser requirement. Labels may not match a controller with a non-standard mapping. | Observation |
| Microphone Test | Whether the browser gives TryYourGear an audio stream once you grant permission; a relative level (the signal's RMS from the browser's audio analyser, scaled to 0–100%) with a peak marker; the audio inputs the browser lists; and a 5-second local recording you can play back. | A calibrated sound level (no dB SPL), sensitivity, noise floor or frequency response. It requests the microphone with default settings, so automatic gain or noise suppression may affect what you see. It tells a permission denial apart from every other error, without saying which error. | Relative reading, plus your listening |
| Webcam Test | Whether the browser gives TryYourGear a video stream; a live preview; the resolution and frame rate the browser reports for that stream; the cameras the browser lists; and a snapshot taken from the preview. | Real frame rate, sharpness, colour or low-light performance. The resolution and frame rate are what the browser says the stream is set to, not something TryYourGear measures. | Browser-reported values, plus your judgment of the image |
| Speaker & Headphone Test | Nothing about the sound itself: it generates tones with the Web Audio API (440 Hz on the left, right or both channels; 100 Hz, 1 kHz and 8 kHz; a 20 Hz to 20 kHz sweep over 10 seconds) and asks what you heard. Choosing an output device works only where your browser supports it. | Frequency response, loudness (dB), distortion, channel balance or the quality of your speakers. It can't know whether you heard a sound; only you can. | Your judgment (perceptual) |
| Monitor & Dead Pixel Test | Nothing is measured. It shows full-screen white, black, pure red, green and blue, a mid-gray, a black-to-white gradient and a checkerboard, and you inspect the screen. | It doesn't count or classify defects, or measure brightness, contrast, colour accuracy or response time. What you see also depends on the browser's colour management, the operating-system settings and the panel. | Your judgment (visual) |
| Refresh Rate Test | The timestamps of the browser's animation frames (requestAnimationFrame) for about three seconds after a half-second warm-up. From them it computes a frame rate and an estimated refresh rate, and says when the estimate is consistent with a common rate, irregular or unreliable. It stops if the tab is hidden. | The monitor's real refresh rate, or which setting, cable or port limits it. It measures how often the browser renders frames, which variable refresh rate, power saving, page performance and system load can all affect. | Estimate (computation) |
| Network Latency Test | The round-trip time of small HTTP requests from your browser to TryYourGear's own server: one warm-up and ten samples timed with performance.now(), with average, minimum, maximum and jitter (the mean difference between consecutive samples). | Your latency to any other server or game, ICMP ping, bandwidth or packet loss. It includes browser, HTTP and server overhead, and the result applies to the TryYourGear server only. | Computation from timed requests |
Limits that apply to every test
- Events arrive at the end of a chain. Whatever a browser reports has already passed through the device's firmware, the operating system, drivers and any manufacturer software. A test can show that something arrives, and rarely where it came from.
- Timing has a precision floor. Browsers deliberately coarsen
performance.now(): MDN gives 5 microseconds in cross-origin isolated pages and 100 microseconds otherwise. The timing tests here work in milliseconds, above that floor, but they inherit the delays of the browser and of a busy system. - Permissions and support vary. The microphone and webcam tests need your permission. Some browsers expose a controller only after you press a button on it. Output-device selection in the speaker test depends on browser support.
What leaves your browser
Eleven of the twelve tests run entirely in your browser. The exception is the Network Latency Test, which by design sends small requests to a TryYourGear endpoint that answers with an empty response; TryYourGear doesn't store the results, although, as with any web request, the hosting provider may keep technical logs of it. The Click Speed and Reaction Time tests save your best score in your browser's local storage and nowhere else.
When you need more than a browser can give
If you need a mouse's polling rate or DPI, a calibrated sound level, colour accuracy or your latency to a specific service, use tools built for that: the manufacturer's or operating system's software, a measurement microphone, a colorimeter, or a ping to the service itself. Use TryYourGear to check what your browser sees and to narrow down where a problem sits.
Guides that use the tests to diagnose a problem
Four guides show the tests at work, each one explicit about what its test can't confirm:
- Mouse double-clicking when you click once, with the Mouse Test.
- A high-refresh monitor stuck at 60 Hz, with the Refresh Rate Test.
- A microphone that isn't working, with the Microphone Test.
- Dead and stuck pixels, with the Monitor Test.
Browser behaviour described on this page follows MDN: KeyboardEvent.code, MediaStreamTrack.getSettings(), the Gamepad API and requestAnimationFrame().