Kalibrierungs-BetaCore Alpha 8 · 16 Workloads

Browser-Leistung, direkt im Browser gemessen

Wie schnell arbeitet dein Browser auf diesem Gerät?

Ein schneller Rechner allein garantiert noch keinen schnellen Browser. BrowserBenchmark.org lässt deinen Browser deshalb 16 typische Aufgaben aus Web-Anwendungen, Grafik, JavaScript, WebAssembly und Browser-Plattformfunktionen erledigen. Am Ende bekommst du einen Beta-Score, vier Teilwerte und vor allem eine Einschätzung, wie sauber die Messung gelaufen ist.

  • Keine Installation, kein Nutzerkonto
  • Während der Messung keine Netzwerkzugriffe
  • Veröffentlichte Suite bleibt unverändert

Die Referenz entsteht jetzt

Aus freiwilligen Messungen wird später eine belastbare Vergleichsbasis

Kalibrierungsstatus ansehen →

Die Seite ist neu. Deshalb sammeln wir zunächst reale Messungen auf möglichst vielen unterschiedlichen Rechnern und Browsern. Entscheidend ist nicht nur die Zahl der Läufe, sondern auch, ob die Daten sauber, wiederholbar und ausreichend vielfältig sind.

Warnungsfreie Desktop-A/B-Läufe1/ 100 als erster Analysepunkt
Grob deduplizierte Desktop-Geräte1/ 30 als erster Analysepunkt

Das sind Planungsmarken, keine automatische Freischaltung. Mobile Messungen laufen zunächst in einem eigenen, explorativen Datenstrang.

Core Suite Alpha 8

Was wird eigentlich gemessen?

Ein Browser macht weit mehr als nur Webseiten anzeigen. Er baut Oberflächen auf, berechnet Layouts, zeichnet Grafiken, führt JavaScript und WebAssembly aus und verschiebt Daten zwischen verschiedenen Browserfunktionen. Genau diese Mischung versuchen die 16 Workloads abzubilden – nicht als theoretischen CPU-Test, sondern möglichst nah an typischer Browserarbeit.

015 Workloads

Web-Anwendungen

Fünf Workloads erzeugen und verändern DOM-Knoten, große Tabellen, Textabsätze und Custom Elements und zwingen den Browser zu Layout- und Style-Arbeit. So wird nicht nur JavaScript-Zeit gemessen, sondern auch, wie effizient Browserengine und Renderingpipeline bei typischen Oberflächenaufgaben zusammenspielen.

Hier geht es um Dinge, die moderne Webseiten ständig tun: Elemente erzeugen, Tabellen aktualisieren, Text bearbeiten und Layout neu berechnen. Ein Browser, der dabei sauber und schnell arbeitet, fühlt sich auch bei komplexeren Web-Anwendungen meist direkter an.

024 Workloads

Grafik

Die Grafiksuite arbeitet mit Canvas, einem dauerhaft aufgebauten SVG, WebGL 2 und einer echten requestAnimationFrame-Zeitreihe. Bei WebGL wird die GPU-Arbeit ausdrücklich abgeschlossen und validiert; die Frame-Messung beobachtet zusätzlich späte Frames und Stabilität statt nur einen theoretischen Maximalwert.

Canvas-Diagramme, SVG-Änderungen, WebGL-2-Partikel und echte Bildfolgen belasten unterschiedliche Grafikpfade. Damit lässt sich besser erkennen, ob ein Browser nur kurz hohe Spitzen schafft oder Grafikarbeit auch über mehrere Messungen stabil verarbeitet.

033 Workloads

Berechnungen

Die drei Compute-Workloads prüfen eine Datenpipeline, einen Parser/Tokenizer und eine Bildverarbeitung in WebAssembly. Der Rechner selbst spielt dabei natürlich eine Rolle, aber gemessen wird immer durch den Browser – also inklusive JavaScript-Engine, WebAssembly-Laufzeit und der jeweiligen Browserimplementierung.

JavaScript ist heute ein zentraler Teil vieler Web-Anwendungen, WebAssembly kommt bei besonders rechenintensiven Aufgaben dazu. Dieser Bereich prüft deshalb, wie flott der Browser Daten verarbeitet, Code analysiert und kompakte Rechenarbeit ausführt.

044 Workloads

Browser-Plattform

Vier Workloads messen Worker-Verarbeitung, Structured-Clone-Kopien, IndexedDB und Transferable-Roundtrips. Das sind Browser-APIs, bei denen nicht nur reine Rechenleistung zählt, sondern auch Datenkopien, Prozess-/Thread-Kommunikation, Speicherverwaltung und die Anbindung an die Plattform.

Worker, IndexedDB und Datentransfers stecken hinter vielen anspruchsvolleren Web-Apps, bleiben für Nutzer aber meist unsichtbar. Genau deshalb testen wir sie separat: Ein Browser kann bei JavaScript schnell sein und bei Plattformfunktionen trotzdem Zeit verlieren.

Warum wir das so machen

Lieber verständlich und ehrlich als eine beeindruckende Zahl ohne Kontext

01Die aktuellen technischen Referenzraten helfen dabei, die unterschiedlichen Workloads zu einem Beta-Score zusammenzuführen. Sie sind aber noch keine wissenschaftlich abgeleitete Vergleichsnorm. Genau dafür sammeln wir jetzt reale Daten auf vielen Geräten; eine endgültige Referenz kommt später in einer neuen, unveränderlichen Suite.

Ehrliche Beta

Der Score darf nützlich sein, ohne schon eine Rangliste zu spielen

Du bekommst bereits einen festen numerischen Wert und kannst eigene Wiederholungen oder Browser auf demselben Gerät vergleichen. Was noch fehlt, ist eine breite Referenz aus sehr vielen unterschiedlichen Systemen. Deshalb behaupten wir derzeit bewusst nicht, dein Browser sei „schneller als X Prozent“ oder gehöre in eine bestimmte Leistungsklasse.

02Jeder Workload wird mehrfach gemessen. Median, robuste Streuung, zeitliche Drift und technische Warnungen fließen in die Qualitätsbewertung ein; besonders instabile Workloads können die Gesamtnote begrenzen. So bleibt sichtbar, wenn ein scheinbar guter Score aus einem unruhigen Lauf stammt.

Messqualität

Ein Ergebnis ist nur so gut wie der Lauf dahinter

Browserleistung schwankt – Hintergrundprogramme, Temperatur, Energiesparmodi oder ein kurzer Scheduling-Ausreißer können hineinspielen. Darum zeigen wir nicht nur den Score, sondern auch eine Qualitätsnote von A bis D und konkrete Warnungen. Auffällige Läufe verschwinden also nicht einfach im Durchschnitt.

03Der Benchmark funktioniert auch ohne Kalibrierungseinwilligung. Wer freiwillig beiträgt, erlaubt zusätzlich die Speicherung des validierten Laufs und datensparsamer Umgebungsdaten für Aufbau und Prüfung der späteren Referenz. Das öffentliche Teilen eines Ergebnisses ist davon nochmals getrennt.

Freiwilliger Beitrag

Testen geht immer. Daten beitragen nur, wenn du es möchtest.

Vor dem Start kannst du entscheiden, ob dein Lauf bei der späteren Referenzkalibrierung helfen soll. Dafür wird zeitweise auch eine technische Gerätesignatur genutzt, damit fünf Läufe vom selben Rechner nicht wie fünf unabhängige Geräte wirken. Öffentliche Freigabe, Reichweitenmessung und Kalibrierungsbeitrag bleiben voneinander getrennt.