Measured, versioned, reproducible.
A score is useful only when you can tell how it was produced. PCBenchmark stores raw units alongside every category score, identifies the workload and scoring version, and keeps incompatible GPU backends separate.
Every timed phase executes deterministic computation, memory transfer or rendering on the local device.
Short compilation and warm-up passes are excluded from scored timing.
Reports retain ops/s, estimated shader workload, FPS, frame-time and transfer units—not just a badge.
WebGPU results are not ranked against WebGL 2 results or a different engine version.
Single-worker and parallel sustained throughput.
CPU phases run in dedicated Web Workers so the interface stays responsive while the timed workload keeps the selected workers busy. Engine 1.2 mixes data-dependent integer, floating-point and cache work in continuous slices; synchronized multi-worker starts reduce launch skew, and checksums prevent the kernel from becoming a no-op.
operations / secondSustained throughput from one worker inside the active browser engine.
operations / secondAggregate sustained throughput across a bounded worker pool.
MB / secondMixed branch, integer and typed-array work on one worker.
WebGPU first, a labelled fallback second.
On supported browsers, engine 1.2 combines a vector WGSL compute shader over a bounded multi-megabyte storage working set with repeated offscreen fragment rendering. A discarded warm-up and three calibration samples select a safe batch size for the current adapter.
During measurement, two mobile or three desktop batches remain in flight. PCBenchmark waits only for the oldest completion fence before submitting more work, which removes the idle gaps caused by draining the entire queue after every small batch. Batch size continues to adapt while remaining bounded for cancellation and browser watchdog safety.
The compute figure is an estimated shader workload rate derived from the suite’s versioned operation model. It is not a measurement of native hardware FLOPS or driver-reported utilization and should only be compared within the same PCBenchmark engine and backend.
If WebGPU is unavailable, PCBenchmark uses a sustained WebGL 2 fragment-shader workload with an asynchronous fence ring instead of refresh-rate pacing. Because the pipelines do different work, they remain distinct benchmark families. Stress mode adds an unscored concurrent CPU + GPU soak after the measured phases to expose short-term performance variation under combined pressure.
- 01 Versioned shaders and bounded profile-specific working sets
- 02 Warm-up outside the scoring window
- 03 Adaptive batches with a bounded in-flight queue
- 04 Backend stored with every public report
System memory and browser-accessible GPU memory.
The system-memory phase uses typed arrays and reports effective bandwidth for a versioned access pattern. The optional Device Memory value is a coarse RAM class: browsers round it to a power-of-two bucket and may cap high-memory systems. A 32 GB class can therefore represent a PC with 64 GB or more; it is never an exact capacity reading and never describes VRAM.
The GPU-memory phase creates bounded browser-visible buffers, repeatedly uploads and touches their contents, measures effective transfer throughput and records allocation or device errors. It is an allocation-and-upload pressure test; the report shows tested MB, not “detected VRAM.”
Automatic GPU matching, with explicit limits.
When the browser discloses a graphics adapter or WebGL renderer string, PCBenchmark sends that value transiently to its matching endpoint as a JSON POST request using no-store cache mode. The matcher returns a conservative catalog candidate; ambiguous, mobile or software-renderer strings are not forced onto a desktop product.
The raw renderer string is not persisted with the benchmark result. If a catalog match is accepted, the report can save the canonical GPU ID and a name snapshot; CPU selection and any manual hardware label work the same way. These fields improve grouping, but they are identification hints rather than hardware attestation.
Raw points stay fixed. The scale can improve.
The browser submits only raw measurements. Laravel validates their structure and computes unbounded CPU and GPU performance points before mapping them to a 0–100 scale. Categories outside the selected suite remain NOT RUN, represented separately from a measured score of zero.
Adaptive v2 calculates score = 100 × run points / cohort anchor, capped at 100. CPU points combine single-thread, multi-thread and compression throughput with a weighted geometric mean, so no subtest saturates early. GPU points come only from the measured shader workload; refresh rate and frame pacing remain diagnostics.
A cohort is locked to the workload signature, Quick/Standard/Stress mode and, for GPU, WebGPU/WebGL backend. A hardware model can influence the anchor only after at least three public, administrator-approved, excellent-quality runs. Its representative value is the median, and the fastest eligible model median becomes 100. One isolated outlier cannot move the scale.
Each published scale is an immutable snapshot. A faster validated device creates a new snapshot and reprojects compatible historical runs, so an RTX 3060 that was once 100 can become 50 when a device with twice its measured throughput becomes the anchor. The original score, raw metrics and previous snapshot remain stored for audit and rollback.
Only the Full system suite produces a composite PC Score and grade. CPU-only and GPU-only suites expose an explicitly partial category score. VRAM remains a pass/fail browser-pressure diagnostic and is excluded from the composite score.
A score and its confidence are different things.
Run quality reflects whether the requested stages completed, whether the page remained visible, whether the graphics device stayed available, and whether the timing distribution was internally consistent. It does not certify the hardware identity or make client-side data tamper-proof.
All stages complete; timing signals are suitable for ordinary comparison.
Usable run with missing capability or higher timing variation.
Incomplete or noisy run; informative, but unsuitable for rankings.
Data we refuse to invent.
No standard browser API exposes a reliable CPU model name.
Web pages cannot read hardware thermals, wattage or clock telemetry reliably.
GPU API resource limits and successful allocations are not installed capacity.
A browser-only run can be sanity checked, but client payloads can ultimately be modified.
Adapter details may also be masked for privacy. A catalog match or user-provided CPU/GPU name is a useful display label, not independently verified inventory.
How to get a fair rerun.
- 1
Use the same browser and keep it updated.
- 2
Connect power, disable battery saver and let the device reach an idle state.
- 3
Close heavy apps and keep the benchmark tab visible.
- 4
Compare the same suite, engine version, mode and graphics backend.