There is generally interest in capturing more complex HTML/CSS workloads (including news and social feed type pages), but also methodology challenges to doing that within Speedometer. In particular we need to avoid network calls and atm we're only able to capture measurements synchronously (although the latter is being worked on).

I have some experiments with testing native HTML element interactions like toggling <details> (main...bgrins:Speedometer:mdn) and <dialog> elements which can cover some of these use cases neatly within the existing runner.

I've also played around with full and partial page rendering tests (https://bgrins.github.io/data-ui-tests/layout/) which also fit within the current runner although they don't perfectly represent the user experience with types of applications you are talking about since they don't include network & parsing within the measured time.

I am glad you are thinking more along these lines. Network calls can be avoided by caching content to be displayed or loading it from a static pre-included file.

There is so much more that browsers do then run heavy JS frameworks.

Here is just an example of types of benchmarks that can be included for the hollistic coverage of browsers performance.

HTML5 - For example https://testdrive-archive.azurewebsites.net/performance/chalkboard/
CSS3 https://testdrive-archive.azurewebsites.net/performance/mazesolver/default.html
WebAssembly https://pspdfkit.com/webassembly-benchmark/
WebGL https://luic.github.io/WebGL-Performance-Benchmark/

I like the CSS-heavy workload you suggested, and we're working towards adding more DOM and CSS heavy workloads for the current release.

Some comment regarding the other workloads:

• WebAssembly benchmarks are typically better suited for an upcoming JetStream release (they can be easily run standalone and typically don't stress DOM interactions / Web APIs too much)
• WebGL and CSS animations are more suited for MotionMark since you quickly get into framerate-based metrics. Speedometer is currently not meant to handle this

Thanks for acknowledgment. I listed those other options as a way to bring attention to the other parts of browser performance that can be measured vs strict focus on arbitrary JS frameworks that the test currently almost exclusively focuses on (which is in no shape or form reflective of the real-world Web unless we want to embrace a dystopian view of the "web" being whatever the current top 10 biggest websites are).

Including CSS heavy workload is certainly a great first step.

I also previously suggested this: #35

To me this is an interesting part of browser performance that is not measured anywhere (construction and traversing the DOM tree etc) where all curent browsers are miserably slow for some reason.

Thanks everyone for doing a great job with Speedometer 3!