Optimizing images with the HTML <picture> tag

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.

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

Yup, exactly. Seems like a strange omission. Using the <picture> tag should make that obsolete though, as the browser can chose which image to fetch without involving the backend, maybe that's why?

WTF!? Jpeg xl was looking awesome, with lots of community interest: https://jpegxl.info/

This sucks.

> - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL - The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default

I don't know much about AVIF (I guess the same concern applies though), but for JPEG XL there are actually two knobs for compression: distance or quality (`-quality` in ImageMagick) and effort (`-define jxl:effort`).

Distance is the target perceptual metric (Butteraugli), while effort controls a variance of the perceptual metric of the encoded image---which can be never accurate. Higher effort means more consistent quality but more computation as well. The default for cjxl, and probably also ImageMagick, is 7 ("squirrel"), which is very high and very slow as you noted. This is much like Brotli defaulting to the highest setting (-11) because both assume that you can spend much more time in compression. If it's not your assumption you should change that.

I do feel that this aspect of JPEG XL is not well communicated. Normally you have a single knob (quality) and increasing quality means more time spent for compression, but in JPEG XL this can be easily decoupled---very useful concept but also relatively alien one. A common mistake is to set the highest effort (9, nicknamed quite appropriately, "tortoise") for speed benchmark, which suggests that there will be people doing this in the production and complaining that JPEG XL compression is very slow, not realizing they can live with much lower efforts.

Yep, we do about 30TB of user images a month, looked into converting to avif for storage savings, but the processing time basically stopped that. Ended up on webp.

> avif conversion: 67.96s > jxl conversion: 42.74s

Holy shit-balls? Also I thought that quad bayer would come down to 12MP for the output?

try sharp

https://sharp.pixelplumbing.com/

Set width and height to the ratio of the image to prevent those layout shifts.

Are you sure about the browser support for WEBP being low? I thought that it didn't work with Safari before but they added it?

> I’ll also add a super low-res placeholder image in the background to prevent the slightly jarring layout jumps on slow desktop connections.

I try that, but don't end to work fine, thanks to the alt text showing, and displacing the background placeholder image

Google search result do this weird trick. When you hover on a link the line at the bottom the your browser window shows the actual URL. But if you do "copy link URL" on it, you get a Google tracker URL in your clipboard.

Couldn't one do the same thing to make users get jpegs when they try to save a wepb? How bad would it be?

A significant downside to the <picture> 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

Certainly not the case with WebP, which was announced by Google 12 years ago. On a recent version of macOS, Preview, the Mac’s default image and pdf viewer can open WebP and AVIF files, making it easy for Mac users to convert to another format if they wish. Also 3rd party graphics apps have supported WebP for years now.

AVIF support isn’t as widespread yet but that will quickly change now.

BTW, the iOS defaults to saving photographs in HEIC, which the average consumer has never heard of.

Nitpick: The image is loaded when it’s near the viewport so loading is likely finished when the user reaches the image.

Thank you, this is exactly what I've been looking for and didn't know it.

yeah I should've thought of that. fixed it now

The article says

  The final <img> tag also specifies common attributes like width, height and alt text. Those attributes will apply regardless of which source the browser chooses!

  The picture element is a container which provides multiple sources to its contained img element to allow authors to declaratively control or give hints to the user agent about which image resource to use, based on the screen pixel density, viewport size, image format, and other factors. It represents its children.

It's also the img tag that you style in CSS. So for all layout purpose, it's still the img element that defines the container and the picture element is more a syntactical bracket to associate other source-sets with it. (This isn't very HTML-y, but, well…)

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.

Yes, all attributes from <img> applies to the selected image, not just width or height.