Speedometer 2.0: Benchmark für Browser in neuer Version
von André Westphal | 15 Kommentare
Speedometer 2.0 ist da. Dabei handelt es sich um ein neues Benchmark-Tool um die potentielle Schnelligkeit von Web-Apps im Browser zu testen. Bereits 2014 erschien Speedometer 1.0, entwickelt durch das WebKit-Team bei Apple. Das Benchmark-Tool soll auch Entwicklern helfen ihre Web-Applikationen im Hinblick auf die Geschwindigkeit zu optimieren. Speedometer 2.0 wurde gemeinsam von den Teams hinter WebKit und Chromium entwickelt. Das Benchmark ist nun deutlich besser auf die aktuellen Frameworks und Werkzeuge zugeschnitten, die im Web bzw. bei Entwicklern zum Einsatz kommen.
Etwa hat man die Unterstützung für aktuelle JavaScript-Frameworks und -Bibliotheken hinzugefügt. Etwa kann man mit Speedometer 2.0 nun auch Preact und Inferno in den Tests einbeziehen. Selbiges gilt auch für die beliebten React und Redux. Auch die beliebten Bundler Webpack und RollUp sind nun in den Tests von Speedometer 2.0 berücksichtigt. Weitere Optimierungen betreffen die Messungen zu Ember.js und Vue.js. Gleichzeitig berücksichtigt man aber auch ältere Libraries bzw. Implementierungen von AngularJS, Backbone.js und Flight. Zu finden ist Speedometer 2.0, falls ihr mal in euerem Browser einen Test durchführen wollt, direkt hier.
Generell haben die Entwickler Speedometer 2.0 so angepasst, dass die Messungen deutlich besser aktuelle Web-Applikationen widerspiegeln sollen. Auch hat man neue Trends wie die zunehmende Verwendung von Elm und PureScript berücksichtigt. Auch wird die Endpunktzahl in Speedometer 2.0 nun anders berechnet als noch in der ersten Version. Dadurch soll ein arithmetischer-geometrischer Mittelwert errechnet werden, der alle Tests mit ihren einzelnen Ergebnissen besser zusammenfasst.
Mit Speedometer 2.0 soll es natürlich nicht enden: Die Entwickler erhoffen sich für die Zukunft noch intensivere Kooperationen mit den Erstellern von Frameworks, der Entwickler-Community.
Wird geladen ...
64,2
83,2; iOS; Safari.
Was sagt mir das jetzt? 😉 Ist das gut, schlecht, mittelmäßig?
66,38
76 – auf Chrome mit einem i5-6600k und GTX1060 6GB – falls das relevant ist
80,6 iPad Pro (Safari) 🙂
29,6 Chrome auf Huawei Mate 10 Pro.
Dauert mir zu lange….
@Anonymous
Sag nur!?
Wirt vom Internet Explorer 11 erst gar nicht unterstützt
WELCHE Sites habt ihr denn gemessen???
Ich stieß auf https://testmysite.withgoogle.com/intl/de-de und testete auf Lanzarote/WLAN mit Brave Caschys https://stadt-bremerhaven.de.
Es passierte Etliches, dafür war die Meldung am Ende mager:
– Ladezeitbindung): 5 Sek / gut, Geschätzter Besucherverlust (aufgrund der Ladezeit) 19%.
– Der Test wird über eine 3G-Standardverbindung durchgeführt…Bis 2020 erfolgen 70 % der Mobilfunkverbindungen weltweit mit 3G.
@bat
Gar keine, wir haben einfach den Link im Artikel angeklickt..
Chrome, Runs/Minute 4.52 (+/- 0.96)
Iteration 1 bis 10 runs/min:
3.929, 4.276, 4.323, 4.121, 3.762, 2.358, 6.658, 4.306, 6.942, 4.558
Ich sehe beim Test bei http://browserbench.org/Speedometer2.0/
ein Fenster mit unausfüllbarer Eingabezeile in der steht ‚What needs to be done‘ und darunter 7 Felder mit ‚Something to do‘ 0 bis 6, die pro Durchlauf nach Kurzem durchgestrichen sind. 480 Durchläufe sind vorgesehen.
Unter dem Fenster mittig die Info z.B.
‚Inferno-ToDo MVC (…/480)‘ – od z.B.
Ember JS-/Ember JS-Debug-/Angular JS/VueJS-…
Die Durchläufe, die insgesamt 45 Minuten benötigten, liefen ab ca 300/480 (schwankend) deutlich schneller.
Nach meiner nach unten folgender englishen Erklärung wohl FALSCHEN (?) Vermutung, werden die Felder ‚Something to do‘ immer deshalb durchgestrichen, weil in dem Feld darüber NICHTS eingegeben ist.
Kann jemand mit ausreichender Kenntnis und englischen Sprachkenntnissen mal was INHALTLICHES über diesen Test sagen?
Im Feld ‚About Speedometer‘, das unter der Detailauswertung auftaucht, steht:
About Speedometer 2.0
Speedometer tests a browser’s Web app responsiveness by timing simulated user interactions.
This benchmark simulates user actions for adding, completing, and removing to-do items using multiple examples in TodoMVC. Each example in TodoMVC implements the same todo application using DOM APIs in different ways. Some call DOM APIs directly from ECMAScript 5 (ES5), ECMASCript 2015 (ES6), ES6 transpiled to ES5, and Elm transpiled to ES5. Others use one of eleven popular JavaScript frameworks: React, React with Redux, Ember.js, Backbone.js, AngularJS, (new) Angular, Vue.js, jQuery, Preact, Inferno, and Flight. Many of these frameworks are used on the most popular websites in the world, such as Facebook and Twitter. The performance of these types of operations depends on the speed of the DOM APIs, the JavaScript engine, CSS style resolution, layout, and other technologies.
Although user-driven actions like mouse movements and keyboard input cannot be accurately emulated in JavaScript, Speedometer does its best to faithfully replay a typical workload within the demo applications. To make the run time long enough to measure with the limited precision, we synchronously execute a large number of the operations, such as adding one hundred to-do items.
Modern browser engines execute some work asynchronously as an optimization strategy to reduce the run time of synchronous operations. While returning control back to JavaScript execution as soon as possible is worth pursuing, the run time cost of such an asynchronous work should still be taken into a holistic measurement of web application performance. In addition, some modern JavaScript frameworks such as Vue.js and Preact call into DOM APIs asynchronously as an optimization technique. Speedometer approximates the run time of this asynchronous work in the UI thread with a zero-second timer that is scheduled immediately after each execution of synchronous operations.
Speedometer does not attempt to measure concurrent asynchronous work that does not directly impact the UI thread, which tends not to affect app responsiveness.
Note: Speedometer should not be used as a way to compare the performance of different JavaScript frameworks as work load differs greatly in each framework.
Gegenüber denen oben geposteten ermittelten Geschwindigkeitswerten sind meine Werte weit abgeschlagen. Moto X Play, Android 7.1.1, WLAN auf Lanzarote [unbekannt Provider/Leistung]
BROWSER – Runs pro Minute:
01 Yandex: 8.83 | ± 0.28
02 Opera: 8.10 | ± 0.14
03 LastPass: 7.50 | ± 0.075
04 Chrome: 7.41 | ± 0.076
05 Via: 7.353 | ± 0.056
06 Habit Browser: 7.34 | ± 0.19
07 Dolphin: 7.33 | ± 0.12
08 Privacy Browser: 7.211 | ± 0.059
09 Yuzu Browser: 7.144 | ± 0.053
10 Browser f Android: 7.05 | ± 0.06 [Easyelife]
11 Browser Lite]: 6.96 | ± 0.09 [iJoysoft
>BEIDE heißen in Einstellungen/Apps: ‚Web Browser‘
12 Brave: 6.80 | ± 0.50
13 Rocket Browser: 6.673 | ± 0.061
14 Lightning Browser: 6.56 | ± 0.078
15 Samsung Internet: 6.32 | ± 0.79
16 CM Browser: 5.35 | ± 0.47
17 Firefox: 2.55 | ± 0.029
@bat
Gute Güte, dass muss ja lange gedauert haben.. habt ihr Pech mit dem Wetter? Komisch, dass die Werte so sehr erniedrigt sind..
@Mo
Wetter ist angenehm.
Ich (75) überlege gern und setze bisweilen falsche Prioritäten – und kenne mich mit den Faktoren, die die Geschwindigkeit beeinträchtigen, viel zu wenig aus.