The web platform exposes computation but not instrumentation. A page can run work and time it, but cannot read any hardware sensor.
- Temperature, power draw, fan RPM, VRAM capacity, and core clocks have no web API at all; there is no permission that unlocks them.
- Timer resolution is deliberately coarsened against side-channel attacks, so browser benchmarks must measure sustained intervals rather than individual operations.
- Browser benchmarks measure relative change on one machine accurately, and absolute hardware capability only directionally.
- SystemCheck reports decay as a behavioural proxy for thermal limiting, not as a temperature reading, and points to HWiNFO or vendor tools when sensor values are what you need.
Computation is exposed; instrumentation is not
The web platform gives a page a surprising amount of compute. Web Workers provide real OS threads, one per logical processor if you ask for them. WebGL2 and WebGPU give access to the graphics pipeline, including compute shaders. SharedArrayBuffer and Atomics allow genuine parallel coordination. You can saturate a modern CPU and a modern GPU from a browser tab without much difficulty.
What the platform deliberately withholds is instrumentation. Every sensor a native monitoring tool reads (die temperature, package power, board power, fan tachometer, VRM temperature, memory temperature, per-core frequency) is simply absent from the web API surface. This is not an oversight awaiting a specification. Sensor access is a fingerprinting and side-channel surface, and the platform's position is that pages do not get it.
So a browser benchmark can generate load and observe the result of load. It cannot observe the physical state that produced the result.
The timing constraint
Browsers reduced timer precision after Spectre because high-resolution timers make cache timing attacks practical. performance.now() is quantised, and how coarsely depends on the browser and on whether the document is cross-origin isolated.
This rules out an entire class of measurement. You cannot reliably time one operation, one frame, or one kernel launch from a page. What survives is measuring a lot of work over a long enough interval that the accumulated duration is large relative to the timer's granularity, which is why SystemCheck's stages run for tens of seconds and report throughput and its variation over time rather than instantaneous figures.
What survives, and is genuinely worth measuring
Sustained throughput under a saturating multi-core load. SystemCheck spawns one Web Worker per logical processor and runs a floating-point workload continuously, keeping the throughput series rather than collapsing it to an average.
Decay across that run: how far the plateau sits below the early peak. This is a behavioural proxy for thermal and power limiting and it is a real measurement of a real effect. It is not a temperature, and describing it as one would be dishonest.
Consistency: how tightly per-interval results cluster. This maps to perceived smoothness better than any average and reliably exposes background contention.
GPU frame time and stability under calibrated raster pressure, and path-tracing samples per second with their own consistency figure. Both are achieved throughput on a real workload, which is often more predictive than a theoretical number anyway.
And the relative effect of any change you make: cleaning a heatsink, altering a fan curve, applying an undervolt, closing a background process. Hold the browser and conditions constant and the confounds become constants, leaving your variable as the thing that moved.
The boundary, stated as a rule
Use a browser benchmark when the question is about behaviour: is this machine slowing down under load, did my change help, how does this system deliver over time. Those questions are answerable accurately from a tab.
Use a native tool when the question is about physical state or absolute capability: what temperature is the die reaching, how many watts is the package pulling, how much VRAM does this card have, is this overclock stable, how does this chip rank against that chip. HWiNFO64 and HWMonitor for sensors; Prime95, OCCT, or y-cruncher for stability; AIDA64 for memory; CapFrameX or PresentMon for per-game frame times.
There is no shame in a tool naming what it cannot do. The alternative, implying sensor access that does not exist, is how users end up trusting a number that was never measured.
Terms used here
Questions
- Will browsers ever expose temperature sensors?
- It is unlikely. Sensor access is a fingerprinting surface and a side-channel risk, and the platform's consistent direction has been to reduce rather than expand hardware-identifying APIs. Assume it will not happen and plan measurement around behaviour instead.
- Can a web page tell how much VRAM my GPU has?
- No. WebGPU exposes adapter limits, which are specification-defined ceilings a device must meet, not the physical memory installed on the card. A page cannot distinguish an 8GB card from a 24GB one on that basis.
- If a browser cannot read temperature, how does SystemCheck report thermal behaviour?
- By measuring throughput continuously under sustained load and reporting how far it decays from its early peak. Decay is a behavioural consequence of thermal and power limiting. It tells you the machine slowed and by how much; it does not tell you what temperature it reached.