Optimizing images with the HTML <picture> tag

&gt; 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<p>Isn&#x27;t it the purpose of the &quot;Accept&quot; HTTP header? For example the last version of Firefox sends &quot;Accept: text&#x2F;html,application&#x2F;xhtml+xml,application&#x2F;xml;q=0.9,image&#x2F;avif,image&#x2F;webp,<i>&#x2F;</i>;q=0.8&quot; when fetching a page.

&gt; I’d still recommend including JPEG XL versions of your images, because chances are that browser support will come eventually.<p>Likely not. Chrome is actually deprecating JPEG XL, the news broke yesterday.<p><a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;news&#x2F;Chrome-Deprecating-JPEG-XL" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;news&#x2F;Chrome-Deprecating-JPEG-XL</a>

One caution here, as I&#x27;m just recently was working on automated image encoding for user submitted images - be careful of AVIF&#x2F;JXL&#x27;s encoding time.<p>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.<p>jpg conversion: 1.74s<p>webp conversion: 3.77s<p>avif conversion: 67.96s<p>jxl conversion: 42.74s<p>Of course there&#x27;s ways to optimize these, but still it&#x27;s worth considering that these newer formats require an order of magnitude (if not more) increase in time to encode. If you&#x27;re doing this for your own static site, it&#x27;s worth doing. If you&#x27;re dealing with user submitted images, make sure you understand the tradeoffs.

I 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&#x2F;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.<p>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).<p>The picture tag and the aspect-ratio CSS rule are real MVPs for dealing with photographs.<p>[1] <a href="https:&#x2F;&#x2F;44hz.de" rel="nofollow">https:&#x2F;&#x2F;44hz.de</a>

A significant downside to the &lt;picture&gt; element, and alternative image formats in general, is that when <i>most</i> 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.<p>It&#x27;s disappointing that browser vendors haven&#x27;t picked up on this and offered a &quot;Save as PNG&#x2F;JPEG&#x2F;GIF&quot; option when downloading images, but for now if it seems reasonable that if any user would want to download an image you&#x27;re displaying then you should probably stick to the legacy formats.

For me the biggest win in pages with lots of images is the img loading=lazy flag- <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;Performance&#x2F;Lazy_loading" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;Performance&#x2F;Laz...</a><p>This only loads the image when it scrolls into view

&gt; Safari doesn’t support the image&#x2F;avif MIME type, so it will skip that one.<p>With iOS 16, current one, and newest Safari with macOS Ventura that support was added, see <a href="https:&#x2F;&#x2F;caniuse.com&#x2F;avif" rel="nofollow">https:&#x2F;&#x2F;caniuse.com&#x2F;avif</a>

Fun fact: the &quot;Your browser support avif&quot; image in that post at <a href="https:&#x2F;&#x2F;jfhr.me&#x2F;your-browser-supports.avif" rel="nofollow">https:&#x2F;&#x2F;jfhr.me&#x2F;your-browser-supports.avif</a> is currently... a png file.<p><pre><code> $ curl -s https:&#x2F;&#x2F;jfhr.me&#x2F;your-browser-supports.avif | file - &#x2F;dev&#x2F;stdin: PNG image data, 400 x 100, 8-bit grayscale, non-interlaced </code></pre> (same for the jxl one, but firefox apparently doesn&#x27;t try to load it because of the type. The webp and jpeg ones are what they say they are.)

I would not use HTTP2 Server Push for anything, see: <a href="https:&#x2F;&#x2F;developer.chrome.com&#x2F;blog&#x2F;removing-push&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developer.chrome.com&#x2F;blog&#x2F;removing-push&#x2F;</a>

The title lost the essential &quot;picture&quot; tag part of it, probably to html sanitization

MDN 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?

You can also use the picture tag to serve different images based on the browser&#x27;s dimensions, to serve the best content and fast. So people with a TV get a wide image while a phone gets a small version, for example. The browser itself makes the choice and GETs the image from a list in the picture tag.<p>This could also conceivably be used for user tracking purposes as a way to determine <i>without javascript</i> the user&#x27;s browser window setting. (I assume CSS can do this too.)

This made me look up jpeg2000 support. And then that made me sad :D

FTFY: HTML &lt;picture&gt; tag