About DeviceBench

Eleven groups, each covering one piece of hardware and the ways it fails. The catalog on the homepage lists every test with a line on what it checks.

• Keyboard — 5 tests
• Mouse — 6 tests
• Click speed — 5 tests
• Display — 15 tests
• Camera & mic — 5 tests
• Audio — 7 tests
• Controllers — 4 tests
• Reflex & memory — 6 tests
• Network — 3 tests
• PC build calculators — 6 tests
• Device & browser — 6 tests

Every test on the site shares one measurement module, so a millisecond on one page means the same thing as a millisecond on the next. Six browser APIs do all the work.

1. Timing. requestAnimationFrame and performance.now(). The frame callback fires once per display refresh, which is how the refresh rate test counts hertz, and performance.now() gives sub-millisecond timestamps — deliberately coarsened by browsers to blunt timing attacks, typically to 0.1 ms, which is far below anything on this site.
2. Input. Keyboard and Pointer Events carry the physical key code rather than the character, which is why the key tests work the same on a QWERTY and an AZERTY layout, and why they can tell the two Shift keys apart. getCoalescedEvents() recovers the pointer samples the browser merged into one frame — without it a 1000 Hz mouse looks like a 60 Hz one.
3. Gamepads. The Gamepad API reports nothing at all until a button is pressed, on purpose, so a page cannot silently fingerprint a controller. Values are polled once per frame; there are no events.
4. Camera and microphone. getUserMedia, behind an explicit permission prompt, over HTTPS only. The stream is attached straight to a <video> or an analyser node in the same tab.
5. Sound. Web Audio generates every tone on this site from an oscillator rather than playing a file, so the frequency is exact and the page weighs nothing. Channel routing for the surround test goes through a merger node, and how many channels it can address depends on the output device.
6. Facts about the machine. Screen geometry, pixel ratio, core count, touch points and the WebGL renderer string. Several of these are deliberately rounded for privacy — Device Info marks which.

Six of them, and each is stated on the page it affects rather than only here. A site that hides these is a site you stop trusting the first time you compare it against a real instrument.

Input latency. What a browser can time is the gap between an input event arriving and the next frame it paints. The switch travel, the USB polling interval and the panel’s own response are all outside that window, so the keyboard latency and input lag figures are useful for comparing two devices on one machine and useless as absolute numbers.

Network round trips. There is no ICMP from a web page. The ping, jitter and packet loss pages fetch a tiny file from the nearest edge server and time the HTTP round trip, which includes the server’s own handling and reads higher than a command-line ping. A browser also cannot observe a dropped packet — only a request that failed or came back late.

Mouse DPI. Nothing in a browser reports a sensor’s counts per inch. The DPI test divides pixels moved by a physical distance you measure yourself, which makes it as accurate as your ruler and worthless if pointer acceleration is on.

Hearing range. The hearing test measures your ears, your headphones and your sound card as one chain. Most consumer headphones roll off before 18 kHz, so a low result is often the hardware. It is not an audiogram, which is measured per ear at a calibrated level in a quiet room.

Component pairing. The bottleneck calculator scores parts against a table of published benchmark aggregates, not against your machine. It answers “which of these two is the limit, roughly” and gives bands rather than a percentage, because a percentage there would be invented precision.

Battery health. Cycle count, design capacity and wear are the numbers people want, and no browser exposes any of them. The battery page reads charge level and charging state where the Battery Status API still exists — Firefox and Safari removed it — and otherwise tells you the command that gets the real figure on your own operating system.

Every page is generated ahead of time and served as a static file — there is no server-side code and no API to call. The tests themselves are JavaScript running in your tab, which is why they react within a frame and why most of them keep working with the network disconnected. The three network pages are the exception, for obvious reasons.

One domain for 68 tests is a deliberate choice. Each of these checks is too small to carry a domain of its own, but together they compound: the links between them pass authority around, one name accumulates trust, and someone who came to find out why their mouse double-clicks finds the polling rate test they were going to need next. The cross-links at the foot of each page are that structure made visible.

Nothing you produce here leaves your device. Camera and microphone streams are attached to elements in the same tab and are never recorded to a server; a recording you make on the microphone or video-call page lives in memory until you close the page. Keystrokes, clicks and controller input are read as events and discarded frame by frame. What is written to your own device and nowhere else: the best scores and calibration settings a few pages keep in local storage, and whatever your browser caches to load the pages faster.

This describes what DeviceBench does. It says nothing about what a browser extension, a corporate proxy or the machine itself might see — only that this site adds nothing to that list.