Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speedometer 3.0: A shared browser benchmark for web application responsiveness

browserbench.org

Post reply on HN
Print view View original

171–180 of 183 posts

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#171

Post by lapcat »

itishappy wrote: post #169
lapcat wrote: post #165

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=39673609

That's irrelevant. The speedometer reading is an absolute reference. The percentages being discussed are simply comparisons, and they're only being discussed to say "they behave like you'd expect." To directly answer your original question: a reading of 21 is 5% better than a reading of 20 because 21 is 5% greater than 20, and this means that a 21 speed browser should do things 5% faster than a 20 speed browser. TL;D…

> The speedometer reading is an absolute reference.

To what?

I talked about driving a car. Miles and hours are an absolute reference. We still have no absolute reference for Speedometer.

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#173

Post by gcp »

apfsx wrote: post #155
muizelaar wrote: post #129

Earlier quoted context omitted.

What's your score in Firefox with extensions disabled?

Firefox extensions disabled: 16.8 +- 0.59 Brave extensions disabled: 19.0 +- 0.88 Interesting because I have only 5 extensions. The heaviest extension seems to be Dark Reader which causes over 5 point changes.

Yeah, Dark Reader is known to totally plummet Firefox performance.

Not sure if it's a coding issue in the Firefox version of Dark Reader, or it's hitting some slow path in Firefox itself.

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#174

Post by itishappy »

lapcat wrote: post #171
itishappy wrote: post #169

Earlier quoted context omitted.

That's irrelevant. The speedometer reading is an absolute reference. The percentages being discussed are simply comparisons, and they're only being discussed to say "they behave like you'd expect." To directly answer your original question: a reading of 21 is 5% better than a reading of 20 because 21 is 5% greater than 20, and this means that a 21 speed browser should do things 5% faster than a 20 speed browser. TL;D…

> The speedometer reading is an absolute reference. To what? I talked about driving a car. Miles and hours are an absolute reference. We still have no absolute reference for Speedometer.

To... itself? Go measure something. You now have a reference!

If you scratch out the labels of your car speedometer and forget which is which, it still measures speed. 80 is still 33% faster than 60, regardless of the units.

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#175

Post by lapcat »

itishappy wrote: post #174
lapcat wrote: post #171

Earlier quoted context omitted.

> The speedometer reading is an absolute reference. To what? I talked about driving a car. Miles and hours are an absolute reference. We still have no absolute reference for Speedometer.

To... itself? Go measure something. You now have a reference! If you scratch out the labels of your car speedometer and forget which is which, it still measures speed. 80 is still 33% faster than 60, regardless of the units.

This reply is ridiculous. I'm done.

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#176

Post by itishappy »

lapcat wrote: post #175
itishappy wrote: post #174

Earlier quoted context omitted.

To... itself? Go measure something. You now have a reference! If you scratch out the labels of your car speedometer and forget which is which, it still measures speed. 80 is still 33% faster than 60, regardless of the units.

This reply is ridiculous. I'm done.

Suit yourself!

I suspect your questions would be answered better by playing around with the tool in question for a few minutes anyway, as you seem to be asking about capabilities the tool does not purport to have.

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#177

Post by troupo »

MBCook wrote: post #145
troupo wrote: post #105

> The primary goal of Speedometer 3 is to reflect the real-world Web as much as possible, so that users benefit when a browser improves its score on the benchmark. As with any other benchmark its results will be interpreted incorrectly and will have little effect on real world. Google already has vast amounts of real-world data. The end result? "Oh, you should aim for a Largest Contentful Paint of 2.5 seconds or lowe…

The last two versions have lead to demonstrable speedups in major browsers. Why wouldn’t this? Bad developers (or management dictates) will be bad no matter what. That’s not a reason to give up.

The problem is complex and has many sides.

1. These companies themselves don't practice what they preach. No matter how fast Speedometer 3 is, Google's own web.dev takes three seconds to load a list of articles, and breaks client-side navigation. Google's own Lighthouse screams at you for embedding Youtube and suggests third-party alternatives [1]

2. The DOM is a horrendously bad, no-good, insanely slow system for anything dynamic. And apps are dynamic.

There's only so much you can optimise in it, or hack around it, until you run into its limitations. The mere fact that a ToDo app with a measely 6000 nodes is called a complex app in these tests is telling.

And the authors of these tests don't even understand the problem. Here's Edge team: "the complexity of the DOM and CSS rules is an important driver of end-user perceived latency. Inefficient patterns, often encouraged by popular frameworks, have exacerbated the problem, creating new performance cliffs within modern web applications".

The popular frameworks go to extreme lengths to not touch the DOM more than it is necessary. The reason the DOM and CSS end up being complicated is precisely because apps are complex, and the DOM is ill-equipped to deal with that.

This only goes to further show that browser developers have very little understanding of actual web development. And this is on top of the existing problem that web developers have very little understanding of how fast modern machines are and how inefficient web tech is.

This brings us neatly to point number 3:

3. Much of the complexity on the web in the modern web apps is due to the fact that the web has next to no building blocks suitable for anything complex.

https://open-ui.org was started 3(4?) years ago by devs from Microsoft and you can see just from the sheer number of elements and controls just how lacking the web is.

So what do you do when you need a proper stylable control for you app? Oh, you "use inefficient patterns by modern frameworks" because there's literally no other way.

And even if all of those controls do end up being implemented in browsers, it will still not be enough because all the other things will still be unavailable: from DOM efficiency to ability to do proper animations to ability to override control rendering to...

[1] I'm not kidding. Here's the help page it links: https://developer.chrome.com/docs/lighthouse/performance/thi...

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#178

Post by troupo »

ramones13 wrote: post #153
troupo wrote: post #105

> The primary goal of Speedometer 3 is to reflect the real-world Web as much as possible, so that users benefit when a browser improves its score on the benchmark. As with any other benchmark its results will be interpreted incorrectly and will have little effect on real world. Google already has vast amounts of real-world data. The end result? "Oh, you should aim for a Largest Contentful Paint of 2.5 seconds or lowe…

Speedometer 3 is designed to handle the real world you describe. Edge’s post has some details - https://blogs.windows.com/msedgedev/2024/03/11/contributing-...

https://news.ycombinator.com/item?id=39689780

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#179

Post by troupo »

julienwaj wrote: post #164
troupo wrote: post #105

> The primary goal of Speedometer 3 is to reflect the real-world Web as much as possible, so that users benefit when a browser improves its score on the benchmark. As with any other benchmark its results will be interpreted incorrectly and will have little effect on real world. Google already has vast amounts of real-world data. The end result? "Oh, you should aim for a Largest Contentful Paint of 2.5 seconds or lowe…

This _already_ proved effective, as outlined in this post: https://hacks.mozilla.org/2023/10/down-and-to-the-right-fire... Of course website authors should also do their part :-)

https://news.ycombinator.com/item?id=39689780

Re: Speedometer 3.0: A shared browser benchmark for web application responsiveness

#180

Post by zamadatix »

lapcat wrote: post #98
charcircuit wrote: post #80

Earlier quoted context omitted.

It means it is 5% faster. You are overcomplicating it.

Percentages are rarely informative without an absolute reference. A 5% raise for someone who makes $20k per year is $1k, whereas a 5% raise for someone who makes $200k is $10k, which would be a 50% raise for the former.

You've demonstrated you understand how to use the score to compare both inter-browser performance (analogous to the amount each makes per year) as well as individual browser performance improvements (analogous to the amount of the raise). Seems pretty informative to me?
Post reply on HN