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.
> 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.
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.
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.
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.
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.
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.
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 <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].
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."
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.
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.
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.
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.