Live data from Hacker News

Speedometer 3.0: A shared browser benchmark for web application responsiveness

browserbench.org

11–20 of 183 posts

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

#15

Got "Infinity" after testing my Firefox Dev Edition 123b9. Is this because of my FF config because my browser is perhaps blocking something (e.g. canvas, fingerprint, etc) or any result north of 140 is considered infinity?

Do you see anything (errors or something else) in the web console?

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

#16

Got "Infinity" after testing my Firefox Dev Edition 123b9. Is this because of my FF config because my browser is perhaps blocking something (e.g. canvas, fingerprint, etc) or any result north of 140 is considered infinity?

Do you see anything (errors or something else) in the web console?

Please file a bug there if necessary => https://github.com/WebKit/Speedometer/issues/new :-)

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

#17
post #4

Hopefully at some point actual click latency will be fixed in general after some dark decades. Still incredible that a gameboy or an 80's computer with a CRT feels more responsive than most devices these days. Bring back tactility. I'm convinced the choppiness and weird waits are actually psychologically stressing us out. That's why good keyboards + old low latency OS'es or typewriters are so soothing to use.

What is the latency being referred to here?

I don’t see noticeable lag on pressing/tapping buttons or other ui components in day to day browsing, even on my quite old iPhone.

There are obviously ways to make delays in web content anyway (user action->synchronous network request being the canonical one), but assuming there’s nothing silly like that lag isn’t an issue I’ve noticed.

Actual execution latency is something I worked on for many years in JSC, and so there are a lot of engine optimizations to reduce that latency as much as possible (the interpreter itself, the interpreter performance, byte code caches, hilarious amounts of lazy parsing and source skipping, etc) so even the first time you have a ui element trigger code there shouldn’t be any significant delay.

Obviously if a developer makes poor choices there’s only so much you can do, but by and large there aren’t that many bad things a web developer can do that a native dev can’t also do (and devs in both environments frequently do :-/).

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

#18
This may be a dumb question, but what do the scores even mean? Is this explained anywhere? Neither https://browserbench.org/Speedometer3.0/about.html nor https://browserbench.org/Speedometer3.0/instructions.html appear to explain it. Are lower scores better, or higher scores?

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

#19
post #18

This may be a dumb question, but what do the scores even mean? Is this explained anywhere? Neither https://browserbench.org/Speedometer3.0/about.html nor https://browserbench.org/Speedometer3.0/instructions.html appear to explain it. Are lower scores better, or higher scores?

Higher is better. The analogy is speed. You want more speed.

It's not a physical speed, just a benchmark number. Think of it as arbitrary units, which allows you to compare different version of browsers on the same machine.

Post reply on HN