So entsteht ein BrowserBenchmark-Ergebnis
BrowserBenchmark.org kombiniert 16 browsernative Workloads in vier Bereichen. Dabei geht es nicht um einen einzelnen Maximalwert, sondern um unterschiedliche Arten von Arbeit, die ein moderner Browser im Alltag erledigen muss. Die Suite misst deshalb Web-Oberflächen, Grafik, Berechnungen und Browser-Plattformfunktionen getrennt und führt sie erst danach zu einem Gesamtwert zusammen.
Vergleichbarkeit
Eine veröffentlichte Benchmark-Suite wird bei BrowserBenchmark.org nicht nachträglich verändert. Das ist wichtig, weil ein Ergebnis sonst später unter anderen Bedingungen neu interpretiert werden könnte. Wenn eine Änderung die Messung, Arbeitsmenge oder Scorebildung beeinflusst, bekommt sie deshalb eine neue Suite-ID. Alte Ergebnisse bleiben damit immer an genau die Methode gebunden, mit der sie entstanden sind.
Messumgebung
Vor dem eigentlichen Start lädt der Browser Manifest, Workload-Code, Worker und weitere benötigte Dateien. Sobald die bewertete Messphase läuft, fordert die Suite keine neuen Daten aus dem Netz an. Damit sollen Serverlatenz, Internetverbindung oder ein kurzfristig langsamer Download nicht in die Browsermessung hineinspielen. Auch LiteStats und das externe Consent-Script werden auf der Benchmarkseite bewusst nicht geladen.
Scorebildung
Jeder Workload liefert zunächst einen eigenen Messwert, der mit seiner tatsächlich ausgeführten Arbeitsmenge normalisiert wird. Innerhalb eines Teilbereichs werden diese Werte nicht einfach addiert, sondern über ein gewichtetes geometrisches Mittel zusammengeführt; dasselbe Prinzip gilt anschließend für den Gesamtscore. Dadurch kann ein einzelner extrem hoher Wert die übrigen Bereiche weniger leicht überstrahlen. Die heutigen Referenzraten sind noch technische Beta-Anker und ausdrücklich keine endgültige wissenschaftliche Norm.
Qualitätskontrolle
Ein schneller Einzelwert reicht uns nicht. Die Workloads werden mehrfach gemessen; für die Auswertung verwenden wir robuste Kennzahlen wie Median und Median Absolute Deviation und beobachten zusätzlich zeitliche Drift. Warnungen wie starke Streuung, Drift, veränderte Fenstergröße oder verfehlte Zielzeitfenster bleiben am Ergebnis sichtbar. Besonders instabile, relevant gewichtete Workloads können die Gesamtnote begrenzen, damit ein unruhiger Lauf nicht wie eine saubere Referenzmessung aussieht.
Schnelle und langsame Geräte
Sehr schnelle und sehr langsame Geräte können denselben Workload sonst in völlig ungeeigneten Zeitbereichen ausführen. Alpha 8 passt deshalb vor der bewerteten Messung ausschließlich die Arbeitsmenge an dokumentierte Zielzeitfenster an; die eigentliche Aufgabe und die spätere Normierung bleiben definiert. Problematische Kaltstartpfade werden zusätzlich durch Priming und Bestätigung stabilisiert. Diese adaptive Laufzeitsteuerung ist nicht mit der späteren Referenzkalibrierung zu verwechseln: Die endgültigen Referenzraten entstehen erst aus einer breiten realen Datenbasis und werden in einer neuen unveränderlichen Suite veröffentlicht.
Warum noch Beta?
Die 16 Workloads laufen bereits nach einer festen, veröffentlichten Methode. Was noch aufgebaut wird, ist die reale Vergleichsbasis: Welche Referenzraten sind über viele Geräte hinweg sinnvoll, welche Plattformen müssen getrennt betrachtet werden und wie stabil sind spätere Perzentile? Genau dafür sammelt die Public Calibration Beta freiwillige Messungen. Erst wenn diese Fragen belastbar beantwortet sind, entsteht eine neue Suite mit endgültiger Referenzkalibrierung.
16 Workloads
Jede Zeile steht für einen festen, versionierten Workload. Die Prozentangabe ist sein Gewicht innerhalb der Scorebildung; Zielzeiten steuern nur die Arbeitsmenge und sind keine Bewertung, ob ein Browser „gut“ oder „schlecht“ ist.
INT-01Web-Anwendungen7%Beta-Referenz 250 ms · Ziel 150–400 msINT-02Web-Anwendungen8%Beta-Referenz 250 ms · Ziel 150–400 msINT-03Web-Anwendungen6%Beta-Referenz 250 ms · Ziel 150–400 msINT-04Web-Anwendungen7%Beta-Referenz 250 ms · Ziel 150–400 msINT-05Web-Anwendungen7%Beta-Referenz 250 ms · Ziel 150–400 msGFX-01Grafik5%Beta-Referenz 250 ms · Ziel 150–400 msGFX-02Grafik5%Beta-Referenz 250 ms · Ziel 150–400 msGFX-03Grafik8%Beta-Referenz 250 ms · Ziel 150–400 msGFX-04Grafik7%Beta-Referenz 12000 Einheiten · Ziel 800–1500 msCPU-01Berechnungen5%Beta-Referenz 250 ms · Ziel 150–400 msCPU-02Berechnungen5%Beta-Referenz 250 ms · Ziel 150–400 msWASM-01Berechnungen10%Beta-Referenz 250 ms · Ziel 150–400 msPLT-01Browser-Plattform8%Beta-Referenz 250 ms · Ziel 150–400 msPLT-02Browser-Plattform3%Beta-Referenz 250 ms · Ziel 150–400 msPLT-04Browser-Plattform2%Beta-Referenz 250 ms · Ziel 150–400 msPLT-03Browser-Plattform7%Beta-Referenz 350 ms · Ziel 200–600 ms