Calibration betaCore Alpha 8 · 16 Workloads

Browser performance, measured directly in the browser

How fast does your browser run on this device?

A fast computer alone does not guarantee a fast browser. BrowserBenchmark.org therefore puts your browser through 16 practical tasks covering web applications, graphics, JavaScript, WebAssembly and browser platform features. At the end you receive a beta score, four category values and, importantly, an indication of how cleanly the measurement ran.

Start benchmark How we measure
  • No installation, no user account
  • No network requests during measurement
  • Published suite remains immutable

The reference is being built now

Voluntary measurements will become a reliable comparison base later

View calibration status →

The site is new, so the first step is collecting real measurements across as many different computers and browsers as possible. The number of runs alone is not enough: data quality, repeatability and diversity matter just as much.

Warning-free desktop A/B runs1/ 100 as the first review point
Approximately deduplicated desktop devices1/ 30 as the first review point

These are planning markers, not automatic release gates. Mobile measurements initially remain in a separate exploratory data stream.

Core Suite Alpha 8

What is actually measured?

A browser does far more than display pages. It builds interfaces, calculates layouts, draws graphics, executes JavaScript and WebAssembly, and moves data between browser subsystems. The 16 workloads are designed to cover that mix—not as an abstract CPU benchmark, but as work that is recognisably browser-like.

015 Workloads

Web applications

Five workloads create and modify DOM nodes, large tables, text paragraphs and custom elements and force layout/style work. This measures more than JavaScript execution alone: it also exercises how efficiently the browser engine and rendering pipeline cooperate on typical interface tasks.

This covers work modern sites perform constantly: creating elements, updating tables, processing text and recalculating layout. A browser that handles this efficiently is more likely to feel responsive in complex web applications.

024 Workloads

Graphics

The graphics suite uses Canvas, a persistent SVG scene, WebGL 2 and a real requestAnimationFrame timeline. WebGL work is explicitly completed and validated, while the frame test also observes late frames and stability rather than only a theoretical maximum.

Canvas charts, SVG updates, WebGL 2 particles and real frame sequences exercise different graphics paths. This helps distinguish short performance bursts from graphics work that remains stable across repeated measurements.

033 Workloads

Compute

The three compute workloads cover a data pipeline, a parser/tokenizer and image processing in WebAssembly. The computer itself naturally matters, but everything is measured through the browser, including its JavaScript engine, WebAssembly runtime and implementation choices.

JavaScript is central to modern web applications, with WebAssembly increasingly used for heavier computation. This category therefore looks at how quickly the browser processes data, parses code-like input and executes compact compute work.

044 Workloads

Browser platform

Four workloads measure worker processing, Structured Clone copies, IndexedDB and transferable roundtrips. These browser APIs depend on more than raw compute speed: data copying, process/thread communication, memory management and platform integration all matter.

Workers, IndexedDB and data transfers sit behind many demanding web apps but are largely invisible to users. Testing them separately matters because a browser can be fast at JavaScript yet still lose time in platform APIs.

Why it works this way

Better understandable and honest than an impressive number without context

01Current technical reference rates help combine different workloads into a beta score, but they are not yet a scientifically derived comparison norm. Real measurements across many devices are being collected for that purpose, and the final reference will later appear in a new immutable suite.

Honest beta

The score can be useful without pretending to be a ranking

You already receive a fixed numerical value and can compare your own repeated runs or browsers on the same device. What is still missing is a broad reference across many different systems. That is why we deliberately do not yet claim that your browser is “faster than X percent” or belongs to a performance class.

02Each workload is measured repeatedly. Median, robust variation, temporal drift and technical warnings feed into the quality assessment, and strongly unstable workloads can cap the overall grade. This keeps a seemingly good score from hiding an unreliable run.

Measurement quality

A result is only as good as the run behind it

Browser performance varies—background programs, temperature, power-saving modes or a short scheduling hiccup can all interfere. That is why the result includes not only a score, but also an A–D quality grade and concrete warnings. Suspicious runs do not simply disappear into an average.

03The benchmark works without calibration consent. A voluntary contribution additionally allows the validated run and data-minimised environment information to be stored for building and reviewing the later reference. Public result sharing is a separate choice again.

Voluntary contribution

Testing always works. Contribute data only if you want to.

Before starting, you can decide whether your run should help with later reference calibration. A temporary technical device signature is used for this so that five runs from one computer do not look like five independent devices. Public sharing, audience measurement and calibration contribution remain separate from one another.