Speedometer 3.0: A Shared Browser Benchmark for Web Application Responsiveness (browserbench.org) 15
Contributors from Apple, Google, Microsoft, and Mozilla, writing for BrowserBench: Since the initial version of the Speedometer benchmark was released in 2014 by the WebKit team, it has become a key tool for browser engines to drive performance optimizations as users and developers continue to demand richer and smoother experiences online.
We're proud to release Speedometer 3.0 today as a collaborative effort between the three major browser engines: Blink, Gecko, and WebKit. Like previous releases (Speedometer 2 in 2018 and Speedometer 1 in 2014), it's designed to measure web application responsiveness by simulating user interactions on real web pages. Today's release of Speedometer 3.0 marks a major step forward in web browser performance testing: it introduces a better way of measuring performance and a more representative set of tests that reflect the modern Web.
This is the first time the Speedometer benchmark, or any major browser benchmark, has been developed through a cross-industry collaboration supported by each major browser engine: Blink/V8, Gecko/SpiderMonkey, and WebKit/JavaScriptCore. It's been developed under a new governance model, driven by consensus, and is hosted in a shared repository that's open to contribution. This new structure involves a lot of collective effort: discussions, research, debates, decisions, and hundreds of PRs since we announced the project in December 2022.
Speedometer 3 adds many new tests. We started designing this new benchmark by identifying some key scenarios and user interactions that we felt were important for browsers to optimize. In particular, we added new tests that simulate rendering canvas and SVG charts (React Stockcharts, Chart.js, Perf Dashboard, and Observable Plot), code editing (CodeMirror), WYSIWYG editing (TipTap), and reading news sites (Next.js and Nuxt.js).
We're proud to release Speedometer 3.0 today as a collaborative effort between the three major browser engines: Blink, Gecko, and WebKit. Like previous releases (Speedometer 2 in 2018 and Speedometer 1 in 2014), it's designed to measure web application responsiveness by simulating user interactions on real web pages. Today's release of Speedometer 3.0 marks a major step forward in web browser performance testing: it introduces a better way of measuring performance and a more representative set of tests that reflect the modern Web.
This is the first time the Speedometer benchmark, or any major browser benchmark, has been developed through a cross-industry collaboration supported by each major browser engine: Blink/V8, Gecko/SpiderMonkey, and WebKit/JavaScriptCore. It's been developed under a new governance model, driven by consensus, and is hosted in a shared repository that's open to contribution. This new structure involves a lot of collective effort: discussions, research, debates, decisions, and hundreds of PRs since we announced the project in December 2022.
Speedometer 3 adds many new tests. We started designing this new benchmark by identifying some key scenarios and user interactions that we felt were important for browsers to optimize. In particular, we added new tests that simulate rendering canvas and SVG charts (React Stockcharts, Chart.js, Perf Dashboard, and Observable Plot), code editing (CodeMirror), WYSIWYG editing (TipTap), and reading news sites (Next.js and Nuxt.js).
AI? (Score:1)
Re:Good (Score:4, Interesting)
Performance wouldn't be a problem at all if modern development practices weren't so astonishingly poor. Between the complete lack of thought given to memory management and the countless third-party libraries that themselves include countless third-party libraries, it's a wonder that things work as well as they do.
User time is more important than developer time!
I don't think anyone under 40 has thought about how much of their own time they waste trying to avoid writing code.
Better instrumentation tools are good to see.
Ironically, "better" tools are what enable the monstrosities created by today's agile "software development by accretion".
Re: (Score:2)
The developers aren't entirely to blame here. Management demands things be done quickly and cheaply, and how much of your RAM they waste is of little concern to the bottom line.
Re: (Score:2)
I'm talking about the performance implications of poor memory management, not the amount of memory needed.
As for "demands things be done quickly and cheaply", I explain in my post that developers waste considerable time and effort in foolishly trying save time and effort with countless third-party libraries. That could be a manager problem in some cases, but odds are good that its a developer problem.
Re: (Score:2)
Well, "Web Application Responsiveness"? We didn't need much benchmarking before web application became as bloated as they are today when web developers knew what they were doing and understood how the network and other things work.
Re: (Score:2)
Infinity before your web app responds? Interesting! /s
I don't need a benchmark suite to know they suck (Score:1)
Re: (Score:2)
I have yet to run across a website that works properly without JS and/or CSS enabled. Most can work (somewhat) with JS disabled/blocked, but without CSS give it up, the site is busted beyond recognition.
Re: (Score:1)
Is it the app that is slow? (Score:2)
SeaMonkey (Score:1)
I guess that's the best possible score
score interpretation (Score:1)