←back to thread

Firefox 120 to Firefox 141 Web Browser Benchmarks

(www.phoronix.com)
119 points mikece | 1 comments | 02 Jul 25 15:11 UTC | HN request time: 0s | source
Show context
Night_Thastus ◴[02 Jul 25 15:33 UTC] No.44444992[source]▶
I find that these days the browsers are all about the same performance-wise and it ends up not mattering much. PCs are so fast that it's very rarely the browser that is the bottleneck. Cool that they're still working to keep it snappy though.

I will say mobile is a bit different. I prefer mobile browser to apps when possible so I can have ad-blocking, but some websites run like complete garbage on mobile browser. They're so slow it's almost unusable. I'm almost 100% certain that's not on the browser itself though.

replies(4): >>44445562 #>>44445768 #>>44445924 #>>44478382 #
cosmic_cheese ◴[02 Jul 25 16:18 UTC] No.44445562[source]▶
In my experience speed differences between browsers are indeed negligible on properly engineered sites/apps. Every so often I run into one that was only ever developed for and tested against Chromium and has major performance issues under Gecko and/or WebKit. Some of it might come down to poorly pruned or outdated polyfills, which in many cases are filling in for features that those engines gained support for quite some time ago.

I wish there were something that could thwart the “Chromium by default” assumption at large amongst devs, because it’s making the web worse than it needs to be.

replies(4): >>44445868 #>>44446168 #>>44446922 #>>44447040 #
OkayPhysicist ◴[02 Jul 25 17:06 UTC] No.44446168[source]▶
I daily drive Firefox serving a Chrome User-Agent, out of frustration with a couple applications that work perfectly on Firefox, but because they didn't test on Firefox, they just assume it won't work and block my connection (If there's any Devs at Snapchat who wants a free ticket completion, you can "Add Firefox support" by deleting your UA check)

I noticed this exact thing. While a lot of sites worked perfectly fine when I was informing them I was using Firefox, when I started lying, they ran faster. Drove me nuts.

Frontend Devs: If your code reads the user-agent string for any reason but logging/spying, you're doing it wrong.

replies(1): >>44446617 #
cosmic_cheese ◴[02 Jul 25 17:40 UTC] No.44446617[source]▶
This is the natural consequence of the notion at large that non-Blink web engines are lightyears behind, which was never true in the strictest sense and has only become less true with time as the gap has narrowed. Besides that, even if you’re relying on some feature that Chrome has implemented as an early draft spec thing or something, maybe consider toggling off that one feature instead of blocking off the whole app.
replies(1): >>44446802 #
OkayPhysicist ◴[02 Jul 25 17:56 UTC] No.44446802[source]▶
To clarify, I didn't mean don't check if the feature you want to use exists on the user's browser. I meant don't come to that conclusion using User-Agent strings. JavaScript makes if very easy to check if a method you want to use exists or not: just check if the function is undefined.

If you do it the right way, if/when another browser implements the feature you used, suddenly you support that browser, with no code changes. If you check UAs, then you need to keep tabs on browser updates and manually update your website when features get added to browsers, and you need to check what version people are using because maybe it's out of date, it's a whole thing.

What drives me nuts is that the right way is the easy way.

replies(1): >>44447686 #
1. cosmic_cheese ◴[02 Jul 25 19:14 UTC] No.44447686{3}[source]▶
We’re in full agreement here, all I was saying is that the menality that leads to user agent sniffing is likely the idea that engines that aren't Blink are so incapable and will break the site/app so badly that it’s better to just rule out their usage altogether. Checking on a per-function basis (or alternatively, just not insisting on using bleeding edge features in the first place) is absolutely the way to go about avoiding brokeness.