AVIF, the file format based on the AV1 video codec, is the latest addition to the next-gen image formats. Early reports and comparisons show good results compared to JPEG and WebP. However, even if browser support is good, AVIF is still on the bleeding edge in regards to encoding and decoding. Encoding, decoding, settings and parameters has been well discussed elsewhere.
No doubt, AVIF images generate a smaller payload and are nice looking. In this post, we’ll take a closer look at issues to be aware or before you go all in on AVIF.
1. WebP is Better for Thumbnails
One interesting observation is that for small dimension images, WebP will produce lighter payload images than AVIF.
It’s probably possible to explain why, and tune the encoder to address this case. However, that is not an option for most people. Most people would probably rely on an image optimizer like squoosh.app or an image CDN like ImageEngine. The below comparison uses exactly these two alternatives for AVIF conversion.
We see that WebP will generally produce images with a higher file size than AVIF. On larger dimension images, ImageEngine performs significantly better than squoosh.app.
Now, to the interesting observation. On images around 100px × 100px squoosh.app passes ImageEngine on effectiveness, but then also WebP catches up and for a 80px x 80px image. WebP is actually the most effective image measured in file size.
The test performs relatively consistently on different types of images. For this illustration, this image from Picsum is used.
| Pixels | Original JPEG (bytes) | Optimized WebP (bytes) | ImageEngine AVIF (bytes) | squoosh.app AVIF (bytes) |
|---|---|---|---|---|
| 50 | 1,475 | 598 | 888 | 687 |
| 80 | 2,090 | 1,076 | 1,234 | 1,070 |
| 110 | 3,022 | 1,716 | 1,592 | 1,580 |
| 150 | 4,457 | 2,808 | 2,153 | 2,275 |
| 170 | 5,300 | 3,224 | 2,450 | 2,670 |
| 230 | 7,792 | 4,886 | 3,189 | 3,900 |
| 290 | 10,895 | 6,774 | 4,056 | 5,130 |
2. AVIF Might Not Be the Best for Product Images with High Entropy
Typically, a product page consists of images of the product, and when a user’s mouse hovers over or clicks on the product image, it zooms in to offer a closer look at the details.
It is worth noting that AVIF will in certain cases reduce the level of detail, or perceived sharpness, of the image when zoomed in. Especially on a typical product image where the background is blurred or has low entropy while foreground, and product, has more detail and possibly higher entropy.
Below is a zoomed in portion of a bigger product image (JPEG, AVIF) which clearly illustrates the difference between a regularly optimized JPEG versus an AVIF image optimized by squoosh.app.
The AVIF is indeed much lighter than the JPEG, but in this case the trade off between visual quality and lower file size has gone too far. This effect will not be as perceptible for all types of images, and therefore will be difficult to proactively troubleshoot in an automated build process that relies on responsive images syntax for format selection.
Moreover, unlike JPEG, AVIF does not support progressive rendering. For a typical product detail page, progressive rendering might provide a killer feature to improve key metrics like Largest Contentful Paint and other Core Web Vitals metrics. Even if a JPEG takes a little bit longer time to download due to its larger file size compared to AVIF, chances are that it will start rendering sooner than an AVIF thanks to its progressive rendering mechanism. This case is well illustrated by this video from Jake Achibald.
3. JPEG 2000 is Giving AVIF Tough Competition
The key selling point of AVIF is its extremely low file size relative to an acceptable visual image quality. Early blogs and reports have been focusing on this. However, JPEG2000 (or JP2) may in some cases be a better tool for the job. JPEG2000 is a relatively old file format and does not get the same level of attention as AVIF, even if the Apple side of the universe already supports JPEG2000.
To illustrate, let’s look at this adorable puppy. The AVIF file size optimized by squoosh.app is 27.9 KB with default settings. Converting the image to JPEG2000, again using ImageEngine, the file size is 26.7 KB. Not much difference, but enough to illustrate the case.
What about the visual quality? DSSIM is a popular way to compare how visually similar an image is to the original image. The DSSIM metric compares the original image to a converted file, with a lower value indicating better quality. Losslessly converting the AVIF and JPEG2000 version to PNG, the DSSIM score is like this:
AVIF has slightly better DSSIM but hardly visible to the human eye.
Right Tool for the Job
The key takeaway from this article is that AVIF is hardly the “silver bullet,” or the one image format to rule them all. First of all, it is still very early in the development of both encoders and decoders. In addition, AVIF is yet another format to manage. Like Jake Archibald also concludes in his article, offering 3+ versions of each image on your webpage is a bit of a pain unless the entire workflow (resize, compress, convert, select, deliver) is all automated.
Also, like we’ve seen, just because a browser supports AVIF, it doesn’t mean that it is the best choice for your users.
Using responsive images and adding AVIF to the list of image formats to pre-create is better than not considering AVIF at all. A potential challenge is that the browser will then pick AVIF if it’s supported regardless of whether AVIF is the right tool or not.
However, using an image CDN like ImageEngine, will to a greater extent be able to dynamically choose between supported formats and make a qualified guess whether WEBP, JPEG2000 or AVIF will give the best user experience. Using an image CDN to automate the image optimization process will take into account browser compatibility, image payload size and visual quality.
Thanks for sharing! I’ve been looking to add AVIF for some time now. Another thing is that encoding an AVIF image takes a long time, so you’ll need a smart way of doing that.
Correction, JPEG2000 is an irrelevant format. Otherwise, this is a good article.
I’m interested in the details there! I don’t know much about JPEG2000 at all myself.
Here’s Henri Helvetica and Dr Pierre-Anthony Lemieux in a video about High-Throughput JPEG2000 (or HTJ2K or even HT for short).
A very interesting take on boosting the JPEG 2000 signal. I say that as the format is a solid 20 yrs old. Does that mean much? Maybe not. But the JPEG XL development came as the JPEG format turned 25, and there was belief that it was time to explore an update. As such, the same seems to be happening w/ JPEG 2000: the High-Throughput JPEG 2000 is in experimental phase. But, if we are talking AVIF + JPEG 2000, we’re in a more interesting position. AVIF was adopted quickly: 70% browser coverage as we speak (Chrome, Opera + FF – behind a flag), and we have JPEG 2000 on Safari. But AVIF, borne from the Alliance for Open Media (AOM) who are responsible for the format, is supported by a large group of companies of which Apple is a founding member (along w/ all the major browser vendors). Does that mean much? Maybe not. But they are in full support of AV1/AVIF on paper. So there’s no reason they could not adopt this format in a much more expeditious timeline than say webp. To be continued…
For anyone curious about the High-Throughput JPEG 2000 (HT for short), I curated a series of talks on modern formats, and this was one of them:
https://bit.ly/image_ready_htj2k
Enjoy!
While JPEG2000 is a much overlooked format, it is very effective at image optimization and compression for Apple’s Safari browser (~36% of users). On average, you can get more than 57% image payload reduction. As Henri pointed out, encoding is complicated. For most folks, JPEG 2000’s complexity requires a service like an image CDN to manage encoding without quality loss. Here is a blog that include a video with a discussion about JPEG compression vs. JPEG 2000 conversion.
https://imageengine.io/blog/imageengine-introduces-jp2-jpeg2000-for-apple-devices
The article compares image formats without mentioning the used quality settings, isn’t that a bit useless? I had a hard time, especially with AVIF, to find settings that will produce acceptable results. With AVIF, Squoosh’s min-quality seems to be a key setting. But the again, who really knows how comparable quality settings are across different image formats.
Jan, you are right that tweaking quality settings gets very complicated. That’s why with all the next-gen image format options, offloading all that to an image CDN starts to make sense. An image CDN will handle all the decisions about image format selection and conversions so you don’t need to fiddle with Squoosh or other build time tools. The variety of image formats and optimally matching them to browser device gets very complicated and time consuming. Here is an analysis of image compressors vs. an image CDN.
https://imageengine.io/blog/image-compressors-vs-image-cdns
Full disclosure: I work for imageEngine, an image CDN.
Great article. Thank you for so useful information about JPEG2000, this is information really surprised me.
JPEG 2000 really looks better. Thank you for the article.
AVIF does support progressive decoding. Here is a link to the support of progressive images in AVIF spec: https://aomediacodec.github.io/av1-avif/#layered-items