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.
- 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.
Just one example of legit use not for ads.
I also run Microsoft Teams in the browser, getting notifications for messages is quite useful.
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 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.
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.
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 only hope seems to be mobile linux initiatives like PinePhone, etc. But I'm not holding my breath.
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...
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...
Basically if a browser does support webp, the script does nothing, but otherwise I think this script ends up supporting the image via javascript.
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.
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...
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
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?
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...
Any size gains will be much more noticeable in the context of network transmission.
So you‘ll lose time either on transfer or decoding.
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...
I don't get it. Why is this ironic? Did Apple create the performance optimisation tool that suggested WebP?
Says the writer who use jpeg on his article.
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.
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.
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.
2. I'm pretty sure this isn't "irony." https://www.dictionary.com/browse/irony?s=t
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.
