Not so fast with AVIF, WebP is still the way

Contents

When I moved to Hugo with my website, I looked to optimise everything and implement new techniques. Once Safari gain native WebP support back in 2020, I implement WebP following PawelGrzybek.com - WebP and AVIF images on a Hugo website. The post introduced not only how to implement WebP (at the time when Hugo <0.83 haven’t support it), but also shown how to go step further by implementing AVIF.

This method require you to have WebP/AVIF files stored along with PNG/JPG and not relay on rendering them when the site is build.

I was interested in implementing this as well, but after some tests in my environment I decided not to, and here I will explain why (and it is not about browser compatibility — Safari incompatibility).


There is so much hype right now about AVIF.

On recent post of @tempertemper - AVIF image compression is incredible shown his impression on this image file format.

Still, based on my tests, this not convinced me to move forward… yet.

Majority of my graphics on my website are in PNG. Only some are in JPG format. Serving them in WebP gave my website significant lightness.

Most people claiming that overall reduction counts towards 75%. That’s a lot, so why I am against?


Even before implementing WebP, I optimise (and still do) my images using an unreplaceable tool/website Optimizilla.

I am using Optimizilla for every website that I am working with, and cannot find a better free solution that will give me such great compression results with some tweak option when needed.

On the @tempertemper website, you can read that, when in some occasions they saw WebP to be bigger in size than PNG/JPG, they not seen this yet with AVIF.

I can say that I have seen it.

This may be up to the settings that they are using comparing to mines, but cannot check that, as post not going as far.

Here how its looking on my side, and why I am not impressed as much.

Sample

Four heavy (optimised) JPG files:

284403  02-podrobka-2-biala-w-opakowaniu-min.jpg
296100  01-podrobka-1-pelny-kolor-w-opakowaniu-min.jpg
499831  35-oryginal-nike-pride-2020-z-gory-min.jpg
549876  28-oryginal-nike-pride-2020-w-pudelku-min.jpg

Will call it as JPG1, JPG2 etc.

Four optimised PNG files with transparent elements:

181186  atom_1_o_aplikacji-min.png
306035  node_errors_3-min.png
338439  wireshark-dns-plain-min.png
358865  wireshark-dns-over-https-tls-min.png

Will call it PNGt1, PNGt2 etc.

Four optimised PNG files without transparency:

13121  wise_2021-min.png
74866  Utternaces_Blog_Post_Issue_Mapping-min.png
117208  volume-limit-control-pl-min.png
333806  czynnosci-ustaw-glosnosc-automatyzacja-min.png

Will call it PNG1, PNG2 etc.

WebP (v1.2.0) compression installed using brew:

brew install webp

And here is my compression command for WebP:

find ./ -type f -name '*.png' -exec sh -c 'cwebp -q 75 $1 -o "${1%.png}.webp"' _ {} \;
find ./ -type f -name '*.jpg' -exec sh -c 'cwebp -q 75 $1 -o "${1%.jpg}.webp"' _ {} \;

AVIF (v0.9.0) compression installed using brew:

brew install joedrago/repo/avifenc

And here is the one used for AVIF:

find ./ -type f -name '*.png' -exec sh -c 'avifenc --min 10 --max 30 $1 "${1%.png}.avif"' _ {} \;
find ./ -type f -name '*.jpg' -exec sh -c 'avifenc --min 10 --max 30 $1 "${1%.jpg}.avif"' _ {} \;

Results

FileSizeWebPAVIF
JPG12844036084079104
JPG22961006685486324
JPG3499831180972228604
JPG4549876215306276431

WebP 4, AVIF 0

FileSizeWebPAVIF
PNGt118118665870242066
PNGt2306035419860734210
PNGt3338439236288405783
PNGt4358865243666409365

Original 1, WebP 3 WebP 4, AVIF 0

FileSizeWebPAVIF
PNG113121140068820
PNG2748669811894033
PNG31172088456837583
PNG433380611947061995

Original 2, WebP 2 Original 1, AVIF 3 WebP 0, AVIF 4

Conclusions

Firstly, the compression time to WebP was significantly shorter than to AVIF, especially on PNG with transparency.

In JPG test, you can clearly see that both compression methods win over original (optimised) file, however WebP been better each time comparing to AVIF.

In PNG, the transparency situation slightly changed. WebP in one instance was greater in size than original. However, comparing this to AVIF, WebP win 4 to 0. Also, AVIF resulted increase even up to 100%!

Difference been seen in compression of PNG files that doesn’t contain any transparencies. In two instances, WebP loses to Original, where AVIF loses only once. However, AVIF win significantly to WebP 4 to 0.


I know that this test is not a scientifically based. On @tempertemper, it was highlighted that smaller file is better for various reasons. Concentrating on that, you cannot say that AVIF is the winner, as WebP prove the right choice for now.

On larger sample, when I decided to convert all my images I noticed, that there is no point at this stage for me to go into AVIF.

Of course, AVIF been developed back in 2019 (initial release 2018), where WebP is on the market for whey longer (2010). The algorithms and compressors improved over the time, so we can expect that AVIF will develop in the future as well.

Only hope that we will not need to wait another 10 years until it will be implemented in the Apple ecosystem. Unless they don’t see the future in it, like they don’t see in Adobe Flash, and we all know how it ends and who win.

Regards.

Comments
Categories