The irony of Apple homepage and Safari WebP support | Hacker News Reader

The irony of Apple homepage and Safari WebP support

mobilerank.co

72 pointsv3nom72 comments

That is to save 146KB on one image an 99KB on another, to save 2 seconds you'd have to using a 1mbps connection.

The first random internet article I pulled for real world cellular speeds suggests even unwired, people are getting 30mbps so that changes the article to:

Apple could load 66ms faster by adopting WebP

… but these are cached resources, so maybe…

Apple could perform the initial load 66ms faster by adopting WebP

… would be better.

Looking at the assets needed for an initial load, the fonts alone weigh in at about twice those images, so it probably wouldn't be noticeable.

1) “real world” cellular speeds at 30mbps? That sounds ludicrous to me. Maybe in America, definitely not in many countries across the world.

2) I don’t know a lot of people who are repeat visitors to apple.com. Mentioning the fact that the time is initial load time would be redundant.

> Maybe in America I'd say maybe outside America. Our cell service is pretty terrible if you leave major metropolitan areas, or if you try to actually use your "unlimited" data.

It’s inconsistent.

I live in rural Arkansas, and typical get about 50Mpbs via LTE in a hammock on the shore of the lake.

The speed of small transfers is going to be dominated by congestion window limiting, not bandwidth. So round trip time matters more than bandwidth.

All that said, Apple primarily cares about existing Apple users at this point, why would they optimize images for non-Apple users? They're much more likely to push HEIC if they care --- which for 250kB of images in the modern web, I kind of don't think they would.

The other question is -- how does it affect battery life? New codecs usually take more CPU.

I think there are more images than just the first two shown in the cropped screenshot.

i just checked and according to speedtest.net, here in Indiana, I have 12. 29mbps down.

This is only one half of the story. Given the increased network bandwidth, decoding speed matters. And here, JPEG is much faster. Also note that the JPEG decompression algorithms are highly optimized and coded in assembly language, and there are maybe even hardware decoders.

On android:

WebP 66% less file size than JPG, 267% more time to decode.

WebP 38% less file size than JPG, 258% more time to decode.

WebP 89% less file size than JPG, 319% more time to decode.

https://stackoverflow.com/questions/37812950/jpg-vs-webp-per...

On Android, JPG decoder lib may or may not use a DSP on Qualcomm SoCs, WebP doesn't have any hardware decoding support.

Any size gains will be much more noticeable in the context of network transmission.

Which comes back to people having good phones most probably will have better internet and people habing cheap phones will have less good internet.

So you‘ll lose time either on transfer or decoding.

Firstly, i don't get what apple has to gain by not supporting webp... Nevertheless:

The screenshot puzzles me, it shows two assets, and states that compressing these by an extra ~ 250 kb would save 2 seconds. Maybe on very slow connections?

Also

> Lack of proper support for [...] web notifications on mobile

I can do without these i guess

The author didn't actually compare the different images in each encoding with examples of file size and image quality tradeoffs, just a screenshot from lighthouse.

The screenshot is cropped, there are more than just two assets that would benefit from being in WebP.

"i don't get what apple has to gain by not supporting webp"

I am not totally savvy as to the difficulty of the feat but, at least in principle, would it not cost them less in time and maintenance to not implement or support a feature?

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.

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.

I'm happy that Apple hasn't adopted WebP. JPEG XL and AVIF are better formats. Even Google is considering creating WebP2. WebP is already an outdated format (no HDR support), which should just die.

Disagree.

There's various web standards that export to webp: web recording, video conferencing etc. [1]

Apple have effectively veto'd a web standard, pushing developers and users into their ecosystem yet again.

[1] https://developer.mozilla.org/en-US/docs/Web/API/MediaRecord...

>web recording, video conferencing

Why cant those be done on H.264?

Whether they can or can’t is besides the question.

They’re not in the standard.

And Apple have thereby again damaged an open standard’s wider-scale adoption.

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.

Huh, I didn’t know this. Doing a bit of Googling, looks like it was iOS 10 / macOS Sierra.

https://www.macobserver.com/news/webp-comes-ios-10-macos-sie...

Edit: Now I kind of want to see if I can hack in support on other OS X versions by copying files around...

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.

https://www.cnet.com/news/apple-ios-macos-tests-googles-webp...

Apple doesn't even support their own HEIF on Safari. Why would one expect them to support WebP? Not to mention the gain on WebP is actually relatively small. JPEG, despite its age is still getting encoder improvement.

You would have expected or assumed nearly 30 years since the introduction of JPEG, we could compress an image at 0.5 bpp ( bit per pixel ) that has higher quality than the best JPEG with 1.0 bpp.

It turns out that is still not the case, Not with WebP, AVIF is closer but still not there. Just like in Audio, Despite all the marketing claims about mp3pro, HE-AAC... etc having mp3 128kbps quality at half the bitrate. It took us nearly 30 years to get an Audio Codec that sounds better than the best mp3 encoder at lower than 128Kbps bitrate. And that was Opus at 96Kbps. ( At this point no body cares about those bitrate savings any more )

That is not to say image compression aren't improving. [1] Is an 4K image compressed by the next generation VVC Reference Encoder at 350KB.

[1] https://imgsli.com/MTI1NDA

Could anyone one please tell me what is the purpose of the Web Notifications, other than invasive marketing.

It's one of the few remaining features needed to create fully functional web applications, on par with the functionality of a native app.

As an example, I refuse to install a native Facebook application because of privacy concerns, but a web version with push notification support could provide the same functionality.

- Calendar event notifications

- Instant messaging notifications (e.g. Riot.im, Glowing Bear, WhatsApp, Discord, Slack)

- Changes to files in cloud/collaboration services

Basically, any time you would use a push notification on a mobile device, but when the "desktop application" is essentially just an electron wrapper of the web UI.

Redash sends you a web notification when a long running query has finished. Clicking on the notification opens Firefox to the right tab where you can see the results.

Just one example of legit use not for ads.

Here's a nice use case: I wouldn't mind getting a notification whenever someone responds to my comments on HN.

I also run Microsoft Teams in the browser, getting notifications for messages is quite useful.

I guess you have some notifications on your phone, right? That's the point, notifications for things. If someone sends you a text then you need a notification so you actually notice it.

They're useful on desktop, for having things like Gmail open in the background, but they're not hugely useful on mobile. Usually if you want notifications you would already have the app installed.

The whole point is that if Apple would allow this, you wouldn't have to install the app. You could just use the website.

Forums are an example where the website is perfectly fine without an app, but I'd really like to be able to choose whether or not I get push notifications from them on my phone.

> The irony comes from the fact that Apple decided not to add WebP support to the Safari browser

I don't get it. Why is this ironic? Did Apple create the performance optimisation tool that suggested WebP?

It’s ironic because it’s apple.com that of all sites would benefit from Apple supporting WebP. (according to the author, not me)

"Apple can save the load time if they use the WebP"

Says the writer who use jpeg on his article.

He probably has to support Safari...

Could this be related to non-network performance? The WebKit team seems very conservative in adding features to preserve/balance CPU usage and Battery Consumption. Which I generally applaud them for.

In general it's far better to reduce network usage in exchange for more CPU processing, not to mention that with faster websites you save on screen time as well.

Apple.com loads in around 1 to 1.5 seconds on either of my phone or my macbook. This is on wifi though, I guess the article presumes 4g.

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.

If you use the <picture> element [0], then you can specify a MIME type on the srcset. Browsers will then use this to load an image they support - so if you have a set of pictures with a MIME type of image/webp and others with image/jpeg, WebP will be used by those browsers that support it and JPEG by those that don't. There's a good example at [1].

Alas although most browsers support the picture element, IE11 is the notable exception [2] and a polyfill is required.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi...

[1] https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...

[2] https://caniuse.com/#feat=picture

You can use HTML <picture> elements to provide provide multiple image format versions for an <img> element e.g. preferentially use webp if browser supported, and fallback to using a widely supported format if not. Sounds like doing that might be of interest to you.

> 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 <picture> 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 <img> 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

I would assume that’s entirely possible, but something like this could be done using the HTML5 <video> or <audio> 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 <img> 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...

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.

That script won't even run unless it's on a browser which doesn't support webp.

I don't have to support ios/safari.

1. Apple's users won't care. The ones who know about "WebP" will explain it away by claiming "Apple rejected it because it doesn't meet their high quality standards. The page looks more beautiful this way; WebP will drain the battery; WebP isn't secure; etc."

2. I'm pretty sure this isn't "irony." https://www.dictionary.com/browse/irony?s=t

As an experiment I grabbed all the images from v/home/f/images/iphone-takeover.

Originals: 584 KB for 18 files. After running them through ImageOptim: 353 KB.

So, I made the images ~40% smaller on average just by running everything through a JPEG optimizer.

When you compare that to the ~50% average reduction the author saw for two of the images, it makes WebP seem even less interesting.

Their stubbornness around WebM is even more frustrating to me, honestly.

Protip: if you are still hellbent on using huge picture with transparency, you can use two JPG files one original, and one as an alpha mask.

Is this utility comparing to the same resulting quality?

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.

I personally think Apple is one company that's able to keep Google in check in ways that no other company or government can do. Safari is a whip that Apple seems to use to good effect. Content blockers in Safari as a native implementation (though one could argue on the demerits of how it's implemented), advanced tracking protection, dragging its feet on PWA support, support for Google created/promoted formats, etc. These could be argued as immoral behavior, but there are some benefits to everyone in not having Google control everything.

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.

That's pretty fringey. Given that Apple devices still use the web a lot, including inside apps.

Easily explained! Apple prefers you to use native widgets to make your app harder to port.

That argument could be used for Qt, GNOME, macOS, or Windows. And besides, React Native is a thing.

Qt and GNOME are released by an organization that also maintains a popular browser. Microsoft recently chromified their flagship browser (despite my personal feelings on the matter). I could be wrong, but I don't think React Native gets any support from Apple.

> Qt and GNOME are released by an organization that also maintains a popular browser.

I think you meant "aren't"?

They're also financially benefiting by pushing competing HEIC and HEVC formats since they're patent owners and collect royalties for big scale implementations. In light of that, it's not surprising they refuse to support royalty free formats.

Apple would paid more for HEVC royalty than they receive, or a break even. I doubt royalty payment is an incentive of any kind to Apple. But much rather patent protection.

I work in video streaming business and I haven't seen anything to support this (if anything, they were exempt from royalties from their own patent pool), can you please link something that confirms this?

I think for Clarity I need some explaining. I dont have any hard data or fact, and I doubt anyone would have because of the sensitive nature.

But it is just some Numbers from Facts and Data put into to it and guess work.

If we look into the list of patents from HEVC from three patents pool, along with those missing such as Technicolor, the list from Apple is comparatively very tiny. As a matter of fact I would be surprised if they even get 2% from it given hundreds of companies are in the license pool.

Lets assume Velos Media is in good faith ( FRAND ) and charges similar to MPEG-LA and HEVC Advance, the total is estimated to be capped at roughly $100M per Enterprise annually. Despite a huge market increase in volume since H.264 era, the amount of Consumer Electronics companies ( Enterprise ) is actually not growing. While we are shipping ~1.2B Smartphone every year, ( A market that doesn't even exist during H.264 invention ) Huawei, Apple, Samsung represent over 50% of the Smartphone unit volume already. Top 10 vendor represent close to 90%. Once you factor in Tablet, PC, are in similar situation and many overlap ( since they are by the same Enterprise and count towards the cap ). The total addressable market from HEVC patents is at best $3B from large volume vendor ( $100M Cap x 30 Enterprise ) . You tie in the loose end from other electronics, Blu Ray disc at $2B per year. You are looking at a Total of ~$5B.

Ignoring the 2% Apple exempt from their own products and they actually paid 100M annually. $100M is exactly within the 2% they received from ~5B pool.

Generally Speaking in Reality Apple has many cross licensing agreement with like Samsung, Qualcomm and LG etc they are highly unlikely to be paying anywhere close to the Cap as they will all be exempt from it. And Apple would also not be getting anywhere close to 2% mark, but the argument is still the same.

Apple supports formats they can hardware accelerate. They have historically picked one format to accelerate in hardware (H.264, now its HEVC), and pay the royalties with the format they pick.

Apple SoCs have VP9 hardware acceleration support already and they still won't support them to push HEVC.

Also there's no reason for them not to HW accelerate WebP with the same system (the frames are compatible) but they chose not to, so I'm not quite sure what your point here is.

Reply on news.ycombinator.com