Hacker News new | past | comments | ask | show | jobs | submit login

Try it here: https://browserbench.org/Speedometer3.0/

Very unscientific results using a Mac Studio - Chrome: 20.4, Safari: 17.9, Firefox: 20.1.

Safari on an iPhone 13 Pro Max - 16.5.




On my Early 2015 MBP

Safari 17.4. : 5.52

Chrome 122 : 6.25

Firefox 123 : 7.26

The results pretty much confirms my general feeling about how the browser behaves on my machine as well. Where Firefox being the fastest.

And 22.5 on my iPhone 14 on iOS 17.4

That is my smartphone is ~4x faster than my laptop.


What Safari version are you using? For me, with 17.4, Safari is ahead of Chrome and Firefox, though it is close if you use dev channel.


macOS 14.4 for the Mac Studio tests, and iOS 17.4 for the Safari-on-iOS test.


I'm getting 27.7 in Safari 17.4 on an M1 Pro MacBook. I'm puzzled how you got so low on a Mac Studio.


Another Mac Studio M1 with Safari 17.4:

  22.7 with Content Blocker
  28.7 without Content Blocker


That was it, thanks! I thought I'd controlled for this by using a Private Window, but I'm getting 25.9 with extensions disabled (compared to 17.9 in my original post).


PC i7 13700k (chrome) - 29.8

iPhone 15 Pro (safari) - 23.1

MacBook Air M1 (chrome) - 25.9

MacBook Air M1 (safari) - 18.0


[flagged]



> Is it though?

In my experience it's the buggiest browser out of the big three, and is often missing basic features like e.g.:

https://caniuse.com/?search=opus

Supported in Firefox for *12 years* now, in Chrome for 10, still no support in Safari.

They only "support" Opus audio in their special snowflake '.caf' container, which is super buggy and the last time I checked no open source program could even generate Opus '.caf' files that could be played by Safari on all Apple platforms. I ended up writing a custom converter which takes a standard '.opus' file and remuxes it on-the-fly (I only store '.opus' files on my server) into Safari-compatible '.caf' files, taking special care to massage it so that it avoids all of their demuxer/decoder bugs. You shouldn't have to do this to have cross-browser high quality audio!


> You shouldn't have to do this to have cross-browser high quality audio!

You don't, because HE-AACv2 is as universal as MP3 and better than Opus at low bitrates.

That said, Safari for macOS and iOS plays all the examples at https://opus-codec.org/examples/ except the last.


> That said, Safari for macOS and iOS plays all the examples at https://opus-codec.org/examples/ except the last.

That's because none of those samples are Opus files, except the last one. It even says so on the page.

> You don't, because HE-AACv2 is as universal as MP3 and better than Opus at low bitrates.

No. I did evaluate it before picking Opus. It only beats Opus at very low bitrates, and open source encoders for AAC suck.


> That's because none of those samples are Opus files, except the last one.

Ooof, I didn't even imagine that the official examples were WAV files. Here's an Opus audio file that plays fine in Safari on macOS and iOS: https://kur-static.biblica.com/audio/GEN_001.webm (Note: I have no idea what this content is, but could not find any English Opus content in the wild.)

> …and open source encoders for AAC suck.

Yeah, the disparity is a real bummer.


> Here's an Opus audio file that plays fine in Safari on macOS and iOS

Yeah, that has Opus packed into a Matroska container (which people usually use only for videos and not pure audio). I suppose that's another good way of getting around the problem!


Just go to home page https://wpt.fyi/ see chart "Browser-specific failures are the number of WPT tests which fail in exactly one browser." Safari leads by a longshot with over 3800 tests failing only in Safari. Firefox has 1700 and Chrome less which kinda correlates to my own personal development experience.


Interop is only a tiny subset of the entire suite of WPT tests, and it only contains tests that all vendors agreed upon, so no browser will look bad in Interop.

If you look at the full WPT test suite [1], you'll see that Safari is by far the one failing the biggest number of tests, i.e. the most buggy browser.

The Safari team likes to use Interop to trick people into thinking Safari is as good as the others. It's just a PR play.

[1] https://wpt.fyi/results/?label=experimental&label=master&ali...


For a less biased result, use Stable: https://wpt.fyi/results/?label=master&label=stable&aligned

> If you look at the full WPT test suite [1], you'll see that Safari is by far the one failing the biggest number of tests, i.e. the most buggy browser.

In Safari's case, most WPT test fails mean "hasn't been implemented yet".

> Interop is only a tiny subset of the entire suite of WPT tests, and it only contains tests that all vendors agreed upon…

Exactly. If you're happy building "Works with Chrome" web apps, Safari is not for you.


"Browser-specific failures are the number of WPT tests which fail in exactly one browser." From wpt.fyi

In other terms, WPT test failures for Safari means Safari has bugs or unsupported features that both Firefox and Chrome do not have.

As for Interop, it focuses on a specific, very limited areas, like "scrolling" or "subgrid" and is in no way representative of the overall feature set of a browser.

So no, contrary to what you're implying, it's not that Chrome is too advanced, or doing too much, it's really Safari that is buggy and lagging behind both Chrome and Firefox (by a lot).


> In other terms, WPT test failures for Safari means Safari has bugs or unsupported features that both Firefox and Chrome do not have.

Yep! Safari is not the browser for people who need cutting-edge features, especially not for ones still at the proposal stage.


> Nevertheless, it’s still a garbage browser.

That seems like quite an absurd statement. Why do you think so?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: