Consider falling back to webp based on filesize

There are two sides to this, both encoding and decoding. I think encoding is less important, as it only happens once. It's possible that over time decoders will become more efficient, e.g. by using AV1 hardware decoding instead of software decoding.

A few links

• https://fershad.com/writing/power-consumption-jpeg-webp-and-avif/
• https://web.dev/articles/avif-updates-2023
• https://news.ycombinator.com/item?id=38653378

It means to create a new ConvertConditional plugin or extending existing one with extra configuration?

I'm not sure what the answer to #3 is. Updating the issue summary to make this easier to find.

I would suggest adding to the new AvifConvert plugin. What is the logic for the threshold, is it the original file size? File size after converting (tricky)? Dimensions? The first one is fairly useless, the second one I think impossible since the derivative won't exist first time, and third one you can just opt not to use the convert plugin on the image style.

With this title we can just add optional setting to existing plugin when AVIF is selected to configure "file size to start acting"?

Hope it will not break responsive images further

I would have though the threshold would be based on the file size of the original image (e.g. what @andypost says in #6), so wondering why you think it would be useless?

So if the original image is 4mb - avif.

If the original image is 50kb -> webp.

No idea what a good default cut-off point would be though.

Dimensions - I would assume a 1200x1200 jpeg would still see benefit if it was converted to a 1200x1200 avif or webp though?

Agreed that the eventual size of the image is not feasible, no way to know that.

Also I just realised we also have the mime type of the original image available, so we could opt not to convert images that are already webp or avif - this feels obvious but I think the current convert plugins don't include an opt out for mime type either. I think there are rare but non-zero situations where image style conversion can increase file size, if an image was already well optimized manually.

Another problem here is that we need to know the extension when rendering the image style URL, not generating the image style, so it would need the image size at that point - possible to get this but might add some overhead to the URL generation itself.

About skipping it could have option to not convert if size is bigger, which looks counterintuitive...

In perfect world only dimensions probably available but even in AVIF you have a set of images with different sizes in one file.

OTOH would be great to think about this plugin in context of real usage via responsive images, that's where fallback is discussed as well and that's where we can apply complex rules

I would have though the threshold would be based on the file size of the original image (e.g. what @andypost says in #6), so wondering why you think it would be useless?

If your image style is a 16x16 pixel thumbnail and your original image is 100MB the JPG thumbnail will still be very small.

there's no original file infomation and cropping, it's just input with some image file and output to compare or 2 outputs to compare

I don't think we can generate two outputs to compare and pick one to use. The URL to the file is generated before the file is generated and as catch pointed out they would have different file extensions.

If your image style is a 16x16 pixel thumbnail and your original image is 100MB the JPG thumbnail will still be very small.

Yes but we're talking about whether to convert to AVIF or webp, not whether to run the image style at all.

Yes but we're talking about whether to convert to AVIF or webp, not whether to run the image style at all.

Right, same thing. In most cases we already know the dimensions of the output. So if the image style is for a small thumbnail, just enable the convert to webp plugin. If it's for a hero image then enable the convert with fallback plugin (or just convert to avif if you know its supported). Point is, the source image could be very large or very small but the output dimensions are the same.

I've attached an example in a zip since we can't upload webp or avif here. Original image is 7.4 MB. When I upload it to the media library we get a thumbnail by default. As a WEBP that's 3.3 KB but if I convert to AVIF it's 2.6 KB. That would fall under the "not worth the CPU cycles" threshold, but since the original is 7.4 MB we convert it anyway.

Point is, the source image could be very large or very small but the output dimensions are the same.

Doh, of course that makes sense, sorry it took a while.

So if the image style is for a small thumbnail, just enable the convert to webp plugin. If it's for a hero image then enable the convert with fallback plugin (or just convert to avif if you know its supported).

This makes me think we could add a global setting to configure this (with a default) if we want, and just go by the image style dimensiions - you're right that it's possible for someone to set this up correctly manually without any additional features, but there are already a lot of steps to setting up responsive images styles + formatters etc. so if we can do it automatically with the option to tweak, this wouldn't hurt.

Currently someone adding image styles would already need to add the convert action, so I guess this setting would just provide the default format at that point? Or would we look to at the conversion to all image styles? Also, not all image styles have dimensions so I guess the source filesize could be useful there