Live data from Hacker News

The irony of Apple homepage and Safari WebP support

mobilerank.co

21–30 of 75 posts

Re: The irony of Apple homepage and Safari WebP support

#21
Note that it's not only Apple who's been slow to adopt WebP. Mozilla was pretty skeptical for many years and only implemented this ~a year ago (instead they did a lot of improvements to JPEG encoders in the meantime).

At this point I'd be more interesting in Safari supporting AVIF, though for compat reasons WebP would be nice to have as well.

I'm not defending Apple, but I think the issue is that if Apple implements a new file format, it has to work reliably across whole Apple ecosystem (OS, image editing programs), not only in the browser. This is probably a huge undertaking. You don't want to download a picture and then your image viewer not being able to open it.

Re: The irony of Apple homepage and Safari WebP support

#23
I get the argument, but the estimated savings are bogus.

All the images on the mobile version of apple.com add up to a grand total of 500KB. If reducing their sizes by ~40% (that is, 200KB) would save 2.25s, it means the whole page (just over 3.5MB) currently takes 40 seconds to load. But obviously nobody in the developed world is waiting 40 seconds for apple.com to load. The real savings are probably somewhere between 0.05s and 0.5s depending on network conditions. Not insignificant, but much less than what is promised.

If you really wanted to minimize the time it takes to load apple.com, you should start with the 10 scripts, 7 stylesheets, and 9 webfonts that together make up over 80% of the page size and consume a considerable amount of resources to parse and execute. But the benchmark doesn't tell you that. It's just a checklist of micro-optimizations that doesn't even start with realistic assumptions.

Re: The irony of Apple homepage and Safari WebP support

#24
post #12
post #3

At the expense of quality, at least it was Apple's argument against supporting webp. And no, they didn't ignore it, it was included in one of the previous betas of macOS and iOS and removed later. Don't remember which.

I was also wondering about this and what exactly happened there, I wonder if there are some underlying issues either technical or political there.

Or equally possible they didn’t see meaningful real world improvements?

Re: The irony of Apple homepage and Safari WebP support

#25
post #5

The webp issue is truly infuriating. I'd like to support it in my own websites, but I literally can't since a huge chunk of visitors use Safari. The only hope seems to be mobile linux initiatives like PinePhone, etc. But I'm not holding my breath.

There is webpjs I think.

http://webpjs.appspot.com/

Basically if a browser does support webp, the script does nothing, but otherwise I think this script ends up supporting the image via javascript.

Re: The irony of Apple homepage and Safari WebP support

#26
post #18

Earlier quoted context omitted.

> I'd like to support it in my own websites, but I literally can't since a huge chunk of visitors use Safari. Wouldn’t using the element[0] allow this this? It’s pretty widely supported (every browser that supports WebP and Safari)[1] and allows a fallback to a JPEG in an tag. [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi... [1] https://caniuse.com/#feat=picture

Would this be susceptible to tracking issues? E.g. place a hidden picture that loads WebP or PNG otherwise, to track which users support it and which don't

I would assume that’s entirely possible, but something like this could be done using the HTML5 or elements for video or audio codecs (there’s even a DOM API to do it! [0]), and some browsers advertised WebP support via the HTTP Accept header [1]. For tracking, I’d assume it’s not very useful these days apart from determining who’s using Safari?

Edit: Not to mention that the onerror event handler on the tag has always been able to find out if an image didn’t display [2].

[0] https://html.spec.whatwg.org/multipage/media.html#dom-naviga...

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_ne...

[2] https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageEl...

Re: The irony of Apple homepage and Safari WebP support

#27
post #24
post #12

Earlier quoted context omitted.

I was also wondering about this and what exactly happened there, I wonder if there are some underlying issues either technical or political there.

Or equally possible they didn’t see meaningful real world improvements?

Yeah sure but why implement it at all in a beta? I remember reading that years ago employees from both Mozilla and Apple looked into the format and both concluded it wasn't worth implementing. Firefox dragged it's feet with this too and eventually caved early last year, probably due to pressure from web developers looking at Google's lighthouse score telling them to use webp.

Re: The irony of Apple homepage and Safari WebP support

#28
post #25
post #5

The webp issue is truly infuriating. I'd like to support it in my own websites, but I literally can't since a huge chunk of visitors use Safari. The only hope seems to be mobile linux initiatives like PinePhone, etc. But I'm not holding my breath.

There is webpjs I think. http://webpjs.appspot.com/ Basically if a browser does support webp, the script does nothing, but otherwise I think this script ends up supporting the image via javascript.

Please don’t drain my battery with crap like this when my phone has dedicated hardware for JPEG decoding.

Re: The irony of Apple homepage and Safari WebP support

#29
post #18

Earlier quoted context omitted.

> I'd like to support it in my own websites, but I literally can't since a huge chunk of visitors use Safari. Wouldn’t using the element[0] allow this this? It’s pretty widely supported (every browser that supports WebP and Safari)[1] and allows a fallback to a JPEG in an tag. [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi... [1] https://caniuse.com/#feat=picture

Would this be susceptible to tracking issues? E.g. place a hidden picture that loads WebP or PNG otherwise, to track which users support it and which don't

Browsers tend to advertise what formats they accept outside of a very basic set to the server on requests via the HTTP Accept header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

For example, Firefox on macOS sent this Accept header for this request: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8

Chrome sent text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9

Re: The irony of Apple homepage and Safari WebP support

#30

At this point, I don't think it's too fringey a conspiracy theory that Apple is opposed to the advancement of web technology, while trying to plausibly appear to be in favor of it. Their motive would be obvious. Keep the native app experience superior.

Or webkit is just a smaller team prioritising other features over every random, new API and standard that the Chrome team comes up with and later abandons.
Post reply on HN