How a BrowserBenchmark result is produced
BrowserBenchmark.org combines 16 browser-native workloads in four categories. The goal is not one isolated maximum value, but different kinds of work a modern browser has to perform in everyday use. Web interfaces, graphics, computation and browser-platform features are measured separately and only then combined into an overall value.
Comparability
A published BrowserBenchmark.org suite is never changed retroactively. Otherwise an old result could later be interpreted under conditions that did not exist when it was measured. Any change that affects measurement, workload quantity or scoring therefore receives a new suite ID. Historical results stay permanently tied to the exact method that produced them.
Measurement environment
Before the run starts, the browser loads the manifest, workload code, workers and other required files. Once the scored measurement phase begins, the suite does not request new network data. This keeps server latency, the internet connection or a temporarily slow download from becoming part of the browser score. LiteStats and the external consent script are deliberately not loaded on the benchmark page either.
Scoring
Each workload first produces its own value, normalised by the amount of work actually performed. Values within a category are not simply added; they are combined using a weighted geometric mean, and the same principle is then used for the overall score. This makes it harder for one unusually high value to dominate everything else. Current reference rates are technical beta anchors only and are explicitly not the final scientific reference.
Quality control
One fast sample is not enough. Workloads are measured repeatedly; robust statistics such as the median and median absolute deviation are used, while temporal drift is tracked as well. Warnings such as high variation, drift, window resizing or missed target-duration windows remain visible with the result. Strong instability in materially weighted workloads can cap the overall grade so that a noisy run is not mistaken for a clean reference measurement.
Fast and slow devices
Very fast and very slow devices would otherwise execute the same workload in unsuitable time ranges. Alpha 8 therefore adjusts only the amount of work to documented target-duration windows before scored measurement; the task itself and later normalisation remain defined. Problematic cold-start paths are additionally stabilised through priming and confirmation. This adaptive runtime sizing is not the same thing as reference calibration: final reference rates will only be derived from a broad real-world dataset and published in a new immutable suite.
Why still beta?
The 16 workloads already run according to a fixed published method. What is still being built is the real-world comparison base: which reference rates make sense across many devices, which platforms need separate treatment, and how stable would later percentiles be? That is what the Public Calibration Beta collects voluntary measurements for. Only when those questions can be answered robustly will a new suite be published with final reference calibration.
16 Workloads
Each row represents a fixed, versioned workload. The percentage is its scoring weight; target durations only control workload sizing and do not indicate whether a browser is “good” or “bad”.
INT-01Web applications7%Beta reference 250 ms · Target 150–400 msINT-02Web applications8%Beta reference 250 ms · Target 150–400 msINT-03Web applications6%Beta reference 250 ms · Target 150–400 msINT-04Web applications7%Beta reference 250 ms · Target 150–400 msINT-05Web applications7%Beta reference 250 ms · Target 150–400 msGFX-01Graphics5%Beta reference 250 ms · Target 150–400 msGFX-02Graphics5%Beta reference 250 ms · Target 150–400 msGFX-03Graphics8%Beta reference 250 ms · Target 150–400 msGFX-04Graphics7%Beta reference 12000 units · Target 800–1500 msCPU-01Compute5%Beta reference 250 ms · Target 150–400 msCPU-02Compute5%Beta reference 250 ms · Target 150–400 msWASM-01Compute10%Beta reference 250 ms · Target 150–400 msPLT-01Browser platform8%Beta reference 250 ms · Target 150–400 msPLT-02Browser platform3%Beta reference 250 ms · Target 150–400 msPLT-04Browser platform2%Beta reference 250 ms · Target 150–400 msPLT-03Browser platform7%Beta reference 350 ms · Target 200–600 ms