Will implement Features Suggestion: Support for AVIF

Dear Rudd,

First of all, thank you for your great extension!
Today, I’d like to suggest implementing support for AVIF. Compared to WebP, AVIF delivers approximately 20–30% smaller file sizes while offering even higher image quality, for example by supporting HDR. According to caniuse.com, 94.5% of users can display AVIF — just 2% less than WebP support. While most websites still stick with WebP, I’ve recently noticed that some major websites (e.g., online shops) are starting to adopt AVIF. Since my website makes heavy use of images, a 20% reduction in transferred bytes would be a significant improvement.
In my opinion, the core focus of your extension is to optimize image handling as much as possible (e.g., via conversion, resizing, or HTML attributes) to speed up client-side page load times. To me, AVIF support aligns perfectly with this goal and would help keep your extension among the best in the years to come.More specifically, I suggest adding a new flag, “Convert images to AVIF format,” next to the existing “Convert images to WebP format” flag, so both formats can be enabled or disabled independently. As far as I know, the PHP GD library has supported AVIF since PHP 8.1 (GD: AVIF image support – PHP 8.1 • PHP.Watch), which means all currently supported and patched PHP versions are compatible.

Kind regards,

Markus

Hi Markus,
thanks for your kind words!
Yes, avif format is already on the todo list for ochResponsiveImages.
Still needs sosme checking e.g. the brower reports to the server if it is able to use webp, if not then ochResponsiveImages will set the jpg/png images. Need to check if that is also possible for avif images.

Things like that... and time to do it

I will prioritize this now that I know somebody actually requested it.

So thanks for your request.
Will follow up here.

have a nice weekend.
regards,
Ruud

Hi Markus,

so in the Private message tab there is a download link to a test version that has avif support.
in the configuration you can now choose if you want webp or avif.

Note that altough avif filesize is (a lot) smaller then webp, browser support isn't completely there yet. and also the jury is still out if this is actually an improvement over webp format: due to higher compression, it is functioning poorly on slower devices as the decrompression of the images is more cpu intensive.

That said:
ochResponsiveImages will check if avif is supported (both on the server for creating the images, as well as on the visitor browser) : if not supported the original image format (e.g. jpg) is offered as a fallback.

When installing this version and activating avif, the images need to be created: this will take some cpu power, so be aware of this. it will NOT remove the webp images, if you stick with avif format then you can delete these manually from the ./images/ochri directory.

Looking forward to your feedback!

regards,
Ruud.

Hi Ruud,

thanks for your blazing fast implementation and your thoughtful notes! I'll test the version over the weekend and give you feedback.

regards,

Markus

Hi Markus,

take you time.

this weekend and next week will be mostly offline due to (if I may say so myself) well deserved holiday

Hi Ruud,

I've tested the new version with a local copy of my site using a XAMPP server.

First, I noticed a significant difference in CPU usage. I deleted all cached versions of one specific image and measured the creation time for WEBP and AVIF in medium quality. While WEBP (and JPEG) cache creation took 3.4 seconds, AVIF (and JPEG) needed 24.4 seconds. I'm not quite sure if my production web server could handle a sevenfold increase in load while generating images compared to WEBP, since WEBP presents already a reasonable challenge, even with the generation of only one image per request due to multiple requests per second.

Second, at some quality levels, the size of an ordinary image is slightly higher with AVIF compared to WEBP.
Source JPEG image size: 467 KB
Quality levels (AVIF vs. WEBP in KB) for same image, not a resized version:
Low:      283 / 314
Medium:   431 / 408
High:     567 / 665
Maximum: 2330 / 1010

As you can see, for medium and maximum quality, the AVIF image is larger than the WEBP variant. Since medium quality is my sweet spot for both WEBP and AVIF, the result is disappointing because it means more CPU resources for larger file sizes. If we can't find any further optimization, I'm not going to switch to AVIF.


Just a quick note: my XAMPP didn't add the correct content type for AVIF images until I added "AddType image/avif .avif" to my .htaccess. Interestingly, even without the content type, the AVIF image was displayed correctly on the website. When trying to open the image directly in a new tab, the content type was required. Otherwise, I only saw binary data. I should mention I'm using a rather old XAMPP configuration with PHP 8.1, so chances are good more modern web servers add the content type out of the box. Still, it's something worth remembering in case someone runs into a similar issue.

Regards,

Markus

Hi Markus,

I see the same filesizes (relative) when using medium.
Thing here is that when I use webp then Google Pagespeed states that my images can be optimized, where when using avif (with larger images sizes), it states that the images are 'perfect'.
I think that for SEO this is what counts.

As for pageload / cpu: didn't test that as for I'm running on a VPS and there I do not notice a difference in speed.

That said, on slower servers there are multiple strategies:

1. set the max amount of images to convert per visit. Although as you said on a busy site that will not help
2. set conversion of images only to a specific logged in user: When you set that to e.g. your account, image creation will only happen when you are logged in and not the other visitors. You are then in full control.
3. create a backup site and have that create the images, then copy over the complete ochri directy with the avif /jpg /webp images to the production site

Note that this load is only one time: when creating the images. Once they are created, then there is no additional cpu power needed anymore as the images are already created.

The only difference that we have then is that decompressing the avif images is slower then the webp images: on the visitor browser (so this will not have impact on your server cpu).
What I read this is only an potential slowdown on very old devices as they lack the cpu power.

That said: it is all about what is important for your 'conversion'. For me the Google pagespeed analysis is more important as that is what I think is weighted into the pagerank. That is where my visitors / customers come from. If that means slightly more filesize / download / cpu then that is okay as having that perfect but less visitors is not good for me

 

Hi Ruud,

your feedback is valid and even with roughly the same file size, SEO is better optimized. I'll test AVIF on my production server sometime after the new version has been released and I'll see if the image generation is slowed down less than on my localhost. If I'm not happy, I might stick with WEBP.
I'm surprised the file size is not smaller compared to WEBP because the internet promised otherwise. I wonder if the quality can be a little bit lower than with webp to decrease the file size while maintaining the same image quality, but 50% instead of 75% quality is too much.
The dropdown values for Cache Image Quality did not clarify which quality is used for avif, that's something you should change. Maybe you could consider to set "Medium (jpg/webp: 75%, avif: 65%, png: 3)" to achieve roughly the same image quality regardless of the image format.

Regards,

Markus

Hi Markus,
I noticed that some images are smaller in size (avif compared to webp) and some larger, So I think that it depends on the image itself (level of detail etc.).

I have changed the image quality dropdown in a 'number' where you can change the value in the range of 1 and 100 with steps of 1.

That way you have more fine grained control over the resulting image (compression). Note that the compression level is used for jpg/webp and avif. for png it is converted (as that has a different compression value), where <50 = 9, 50 - 74 = 6 and 75-89 = 3, 90+ = 0

above download link to  latest dev version!