> Safari doesn’t support the image/avif MIME type, so it will skip that one.
With iOS 16, current one, and newest Safari with macOS Ventura that support was added, see https://caniuse.com/avif
Optimizing images with the HTML tag
11–20 of 52 posts
Re: Optimizing images with the HTML <picture> tag
#12> I don’t think there’s a perfect answer. You simply cannot predict with 100% certainty what the browser would choose. But you can get a good approximation by parsing the User-Agent header Isn't it the purpose of the "Accept" HTTP header? For example the last version of Firefox sends "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp, / ;q=0.8" when fetching a page.
Yup, exactly. Seems like a strange omission. Using the tag should make that obsolete though, as the browser can chose which image to fetch without involving the backend, maybe that's why?
[deleted]
Re: Optimizing images with the HTML <picture> tag
#13I am using the picture tag on my photography blog [1] to serve optimized images for a range of breakpoints. I also used to serve WEBP versions of the photos but noticed that (in my audience) the browser support was sufficiently low to drop the generation step for them and just serve various size/quality combinations of JPG.
If time allows, I’ll also add a super low-res placeholder image in the background to prevent the slightly jarring layout jumps on slow desktop connections.
In combination with static hosting from S3 with CloudFront for caching, handwritten CSS + JS (except from Turbo), this yields a close-to-SPA snappiness and feel even on meager connections (as tested from rural Germany, fellow Germans may understand the implications).
The picture tag and the aspect-ratio CSS rule are real MVPs for dealing with photographs.
[1] https://44hz.de
Re: Optimizing images with the HTML <picture> tag
#14> I don’t think there’s a perfect answer. You simply cannot predict with 100% certainty what the browser would choose. But you can get a good approximation by parsing the User-Agent header Isn't it the purpose of the "Accept" HTTP header? For example the last version of Firefox sends "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp, / ;q=0.8" when fetching a page.
I've been surprised lately by the number of people that don't know about or understand HTTP headers. One discussion I saw was on a project that was trying to decide what language to serve a webpage in. They spent a good amount of time choosing a geo-location provider and library and then deciding what language to default to for locations that often had multiple languages. I asked why they didn't just use the Accept-Language header, which they weren't aware of.
Re: Optimizing images with the HTML <picture> tag
#15MDN says that img tag purpose is not just to serve as a fallback, but also to specify size “and other attributes”. Does it also include alt attribute? This is important. Can someone confirm that?
Adding something I don’t currently see mentioned explicitly: the img tag is the actual presented media element, picture/source are not displayed without an img tag. So the img tag itself isn’t even a fallback, only its src attribute.
Re: Optimizing images with the HTML <picture> tag
#16For me the biggest win in pages with lots of images is the img loading=lazy flag-
https://developer.mozilla.org/en-US/docs/Web/Performance/Laz...
This only loads the image when it scrolls into view
Re: Optimizing images with the HTML <picture> tag
#17This made me look up jpeg2000 support. And then that made me sad :D
Re: Optimizing images with the HTML <picture> tag
#18One caution here, as I'm just recently was working on automated image encoding for user submitted images - be careful of AVIF/JXL's encoding time.
I ran some benchmarks with a raw 48mp iPhone 14 dng file (converted to png to start with since jxl had issues going from dng directly) with imagemagick to illustrate.
jpg conversion: 1.74s
webp conversion: 3.77s
avif conversion: 67.96s
jxl conversion: 42.74s
Of course there's ways to optimize these, but still it's worth considering that these newer formats require an order of magnitude (if not more) increase in time to encode. If you're doing this for your own static site, it's worth doing. If you're dealing with user submitted images, make sure you understand the tradeoffs.
Re: Optimizing images with the HTML <picture> tag
#19> I don’t think there’s a perfect answer. You simply cannot predict with 100% certainty what the browser would choose. But you can get a good approximation by parsing the User-Agent header Isn't it the purpose of the "Accept" HTTP header? For example the last version of Firefox sends "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp, / ;q=0.8" when fetching a page.
You can't easily use that with a plain* CDN though - you would need to add a Vary: Accept header and cache misses will increase as every variant of Accept: will cache a different version
* it seems fixable with things like Lambda@Edge and I wouldn't be surprised if a smart CDN which already does on-the-fly image compression had implemented this too
Re: Optimizing images with the HTML <picture> tag
#20A significant downside to the element, and alternative image formats in general, is that when most users wanna download the image they expect an image format they already know how to work with. To most users an .avif or .webp are an annoyance because they reasonable expect most of their tools to be unable to open these.
It's disappointing that browser vendors haven't picked up on this and offered a "Save as PNG/JPEG/GIF" option when downloading images, but for now if it seems reasonable that if any user would want to download an image you're displaying then you should probably stick to the legacy formats.