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.
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.
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.
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
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.
"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.
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.
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.
- 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.
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.
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.
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.
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.
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."
[+] [-] jws|6 years ago|reply
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.
[+] [-] xrisk|6 years ago|reply
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.
[+] [-] toast0|6 years ago|reply
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.
[+] [-] m463|6 years ago|reply
[+] [-] Flimm|6 years ago|reply
[+] [-] jccalhoun|6 years ago|reply
[+] [-] xenonite|6 years ago|reply
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...
[+] [-] baybal2|6 years ago|reply
Any size gains will be much more noticeable in the context of network transmission.
[+] [-] isoprophlex|6 years ago|reply
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
[+] [-] jamil7|6 years ago|reply
[+] [-] Flimm|6 years ago|reply
[+] [-] birdyrooster|6 years ago|reply
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?
[+] [-] jakub_g|6 years ago|reply
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.
[+] [-] kijin|6 years ago|reply
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.
[+] [-] gardaani|6 years ago|reply
[+] [-] tarkin2|6 years ago|reply
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...
[+] [-] mojuba|6 years ago|reply
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.
[+] [-] Wowfunhappy|6 years ago|reply
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...
[+] [-] jamil7|6 years ago|reply
[+] [-] robterrell|6 years ago|reply
[+] [-] ksec|6 years ago|reply
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
[+] [-] aeonflux|6 years ago|reply
[+] [-] matharmin|6 years ago|reply
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.
[+] [-] sigwinch28|6 years ago|reply
- 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.
[+] [-] st3fan|6 years ago|reply
Just one example of legit use not for ads.
[+] [-] kyriakos|6 years ago|reply
I also run Microsoft Teams in the browser, getting notifications for messages is quite useful.
[+] [-] NightlyDev|6 years ago|reply
[+] [-] snazz|6 years ago|reply
[+] [-] rmsaksida|6 years ago|reply
I don't get it. Why is this ironic? Did Apple create the performance optimisation tool that suggested WebP?
[+] [-] xrisk|6 years ago|reply
[+] [-] ezoe|6 years ago|reply
Says the writer who use jpeg on his article.
[+] [-] ben509|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] tbolt|6 years ago|reply
[+] [-] Jyaif|6 years ago|reply
[+] [-] hmottestad|6 years ago|reply
[+] [-] olah_1|6 years ago|reply
The only hope seems to be mobile linux initiatives like PinePhone, etc. But I'm not holding my breath.
[+] [-] KJKingJ|6 years ago|reply
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
[+] [-] haydenkshaw|6 years ago|reply
[+] [-] thomasfoster96|6 years ago|reply
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
[+] [-] kd913|6 years ago|reply
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.
[+] [-] fortran77|6 years ago|reply
2. I'm pretty sure this isn't "irony." https://www.dictionary.com/browse/irony?s=t
[+] [-] CharlesW|6 years ago|reply
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.
[+] [-] jakejarvis|6 years ago|reply
[+] [-] baybal2|6 years ago|reply
[+] [-] htk|6 years ago|reply
[+] [-] draw_down|6 years ago|reply
[deleted]