Comments on: Optimizing Images for Web Performance

By: Dragan

Dragan — Sat, 03 May 2025 07:57:02 +0000

PNG sory totally changes after you try oxipng/pngcrush/optipng. Oxipng can create really optimized images without any percieved quality changes but hugely reduced file size. It does use a lot of computing resources but you can use it once and stor results.

By: John Allsopp

John Allsopp — Thu, 13 Feb 2025 20:32:32 +0000

Might I put in a word for the humble SVG? I suspect your sloth wearing sunglasses would be in the order of a few 100 bytes as an SVG.

By: toastal

toastal — Wed, 12 Feb 2025 06:15:14 +0000

You forgot to mention JPEG XL which is supported in Safari & Firefox Nightly or Librewolf behind the easy-to-enable image.jxl.enabled about:config flag. Unlike the video-codec-based options, JXL offers progressive decoding, lossless JPEG compression, & better clarity for photograph-style raster graphics. You can use it now in a <picture> <source> stack on image-set.

By: Jason Grigsby

Jason Grigsby — Tue, 11 Feb 2025 00:32:46 +0000

Thanks for the spreading the word about image performance!

I have a couple of minor suggestions for article.

First, PNG24 and PNG32 are lossless, but PNG8 is lossy. PNG8 doesn’t make sense for photographic images, but it can still be useful for line art and other images with a limited color palette. It still has a small place in the web image arsenal.

Second, the picture element isn’t required in order to use srcset and sizes. The picture element makes the most sense when supporting an art direction use case where you want to switch what the image looks like instead of the more common resolution switching use case.

If a picture element only has a single source element inside of it and if the source isn’t using a media or type attribute, it shouldn’t use the picture element. In this example, the srcset and sizes attributes can be applied directly to the img element and the rest of the surrounding markup can be deleted.

I’ve written more on why we shouldn’t use picture most of the time here: https://cloudfour.com/thinks/dont-use-picture-most-of-the-time/

Finally, it is a small nit, but the article states, “For images that are critical for rendering, like your LCP element, you should override lazy-loading with fetchpriority=’high'”. Yes, you can and sometime should use fetchpriority=”high” for LCP images, but you’re not overriding lazy loading by doing so.

The example you give is correct. There is no lazyloading attribute on the LCP image which means the browser will load it when it encounters in the document. The fact there is no lazyloading attribute means that there is no lazyloading to override. By adding fetchpriority, you’re suggesting to the browser that this image is higher priority than other assets.

Again, thank you for spreading the image performance gospel!

By: pd

pd — Tue, 11 Feb 2025 00:32:04 +0000

Didn't realise loading=lazy and fetchpriority=high were universally supported natively. Looking at them in isolation like that, they may have been better named like this: priority="delayed|immediate" ... but at least such performance-aiding browser features are now trivial to use. Fantastic!

By: Lucas

Lucas — Mon, 10 Feb 2025 17:45:09 +0000

AVIF – Even better compression than WebP, but not universally supported yet.

I think that is wrong. If you look at “Can I Use”, you will see:

AVIF is at 95% (https://caniuse.com/avif)
WebP is at 96% (https://caniuse.com/?search=webp)

I don’t think this is a meaningful difference?