Well, that’s a great question! AVIF is an image format derived from the AV1 video codec, much like WebP was an image format derived from the WebM video format. It is intended to improve upon some of the shortcomings of WebP. For example, WebP struggles a bit more with images that include sharp edges and those with high saturation, especially reds and yellows.
In short, it is expected to preserve color and edges better, with higher compression than WebP, and far better than JPG. But what does that look like in practice? There’s a lot of buzz about AVIF as it is still very “new”, but I want to share my own experience working with the format and implementing it on our Easy IO CDN.
*Note: this article may be updated as more folks get their hands on AVIF and we see more use cases.
AVIF Conversion Tools
There are several tools for converting images to AVIF, but not a lot in the WordPress space. And since you can’t upload AVIF images directly to WordPress yet, that has made AVIF adoption a bit slow. With EWWW IO, we have three potential avenues for AVIF conversion, and all of them involve the command line. Not that our users need to use the command line, but that’s how most of our image optimization stuff happens “under the hood”.
For command line conversion, I ultimately landed on the cavif-rs project by image expert Kornel. First, because it is easy to compile compared to the reference library. It took me longer just to find those instructions… Secondly, because it uses the speedier rav1e encoding engine, which we’ll see is important in a moment.
Resource Requirements
So that takes us to the resource requirements/consumption of AVIF, which is kind of a big deal with AVIF. For WebP, it was always said that there was a bit more overhead on both the encoding and decoding, but it was acceptable compared to the bandwidth gains.
The first image I converted from JPG to AVIF about made me give up right then and there. On the default speed 4 setting for cavif-rs, it took 46 seconds to encode. That’s a whopping 56x times slower than WebP! Fortunately, increasing the speed setting to 5 gets it down to 8 seconds, but that’s still 10x slower. Further increases to speed don’t yield substantial improvements, and decrease the resulting quality.
As I was researching AVIF, I found that Cloudflare had AVIF capability, and it was interesting to find that they put some heavy restrictions on the use of AVIF conversion. Notably, Cloudflare restricts the size of the image, and how many conversions you can do per minute. I couldn’t find the exact limits, but it would seem this is a big part of why they only offer limited AVIF support on their platform.
Savings & Compression
Not surprisingly, the amount of savings is affected by changing the quality level for AVIF. But an interesting note is that the quality setting can typically go lower with AVIF than it can with WebP. As we’ve seen with JPG quality, different tools use different quality scales, and this is just one more example of that.
I started with quality 60 and found that was too high to get any gains over WebP. Dropping the quality to 50 started to get us some good data, and I finally settled on 45. Compared to WebP, that yielded about 11% additional savings on my sample set, with only a small decrease in measurable quality.
While doing large scale tests, I made sure to use a machine that had lots of CPU cores just like our Easy IO servers, and this showed we could get the compression time down to 4x (cavif-rs compared to cwebp).
Update: The quality scale changed in cavif-rs 1.5.0, such that quality 60 is similar to the former quality 45, and 70 is identical to what quality 50 used to do.
Limitations of AVIF
Now we know we can get comparable quality, with more savings than even the impressive WebP format. But besides resource constraints, are there any other issues? I mentioned earlier that AVIF is supposed to excel with images that have sharp edges, but that comes at a cost. Oddly enough, many “sharpening” algorithms actually use blurring in order to make edges sharper.
While AVIF certainly looks pretty good in most cases, images with a lot of texture tend to lose some of that fine detail. Most folks won’t notice, especially since we’re keeping the quality loss far under the acceptable thresholds. But there were definitely some images for which I would not use AVIF conversion, and most of those were in the PNG format.
When it comes to PNG images, AVIF tends to struggle in comparison to other tools like pngquant, and so that’s something we’ll be keeping a close eye on as more folks use AVIF on Easy IO. Sometimes, very subtle artifacts in an image would get magnified, making the image look quite ugly.
Best uses for AVIF
Ultimately, the best use for AVIF is meant to be saving images directly from the source, rather than converting resized JPG images. However, one can’t really upload AVIF images (yet) in WordPress, and creating thumbnails of AVIF images via WordPress/PHP is nearly impossible at the moment. WP uses the ImageMagick or GD libraries for creating thumbnails, and while they both now have AVIF support, it is going to take a while before newer versions of those libraries are readily available.
On the flip side, browser support is already quite good at 70%, and with Apple and Microsoft both members of the AOM, the remaining “major” browsers will likely adopt AVIF faster than they did WebP. So instead of waiting for WP core to add AVIF support, we’re making AVIF available now with our Easy IO CDN.
Why Easy IO?
Because it’s easy? No really, if you have Easy IO, go over to your Easy IO Sites page, click the gear next to a site, and enable AVIF. This quick on/off makes it simple for anyone to try out AVIF without going through a lot of work, or filling up their server with yet more copies of their images in the AVIF format.
We are setting some limits on AVIF conversion, similar to Cloudflare’s implementation. As of September 2023, these limits are:
- Any images over 2 megapixels will not be converted. That works out to just about any image that’s smaller than a full-screen 1920×1080 image–multiply the width and height and see if it is under 2,000,000.
- Any image over 200kb will not be converted. If an image is under 2MP, but over 200kb, there’s a good chance that it cannot be compressed “easily” and will require much more CPU power with AVIF.
- No image may take take longer than 2 seconds to convert. With the above limits, this is pretty rare, but is an added safety measure to keep the CDN performant.
- We’re starting with a higher quality level for PNG images so some of those might end up better compressed by WebP or Pngquant.
At this point, there is no way we could ever ship a free AVIF converter, as that would require using a minimum of 10x more resources than what we’re already doing with the free mode in EWWW IO. That would be a quick way for web hosts to start banning our plugin all over again–or for you to get your account suspended. And no one wants either of those to happen!
I’m also loathe to clutter up server hard drives with yet more copies of images: JPG + WebP + AVIF. Plus, it’s a lot more difficult to implement conditional AVIF delivery with local images than it is with Easy IO. So while we could likely implement AVIF conversion on the Compress API, that’s not in the cards at the moment.
Feedback
So go on and give AVIF a try, see if it works for your site. Let us know how it works (or doesn’t)! Your feedback is what continues to shape EWWW IO, and I’m (tentatively) excited to see how things play out with AVIF.
