What to know about AVIF on Cloudinary

I just enabled AVIF on Cloudinary and... WOW. My image file sizes dropped by around 37-50% with equal quality.

Most of how to use AVIF on Cloudinary is covered by How to Adopt AVIF for Images With Cloudinary by Eric Portis. In this post, I want to cover some gotchas and things to know.

What is AVIF? #

Before we get started, let's get the back story.

AVIF is a new image format derived from the keyframes of AV1 video.

— Jake Archibald from AVIF has landed

This is not a technical post about image codecs. If you want to nerd out on the technical stuff, I highly recommend AVIF for Next-Generation Image Coding from the Netflix Technology Blog.

Instead, let's look at the difference between formats with equal quality (using q_auto). Note that you will only see all these images on browsers that support both AVIF and WEBP...

How low can we go? Now let's look at equal-ish file sizes with different quality (compression)...

Which browsers support AVIF? #

At the time of writing, AVIF is only supported on Chrome, Opera, Samsung Internet, and a few others. You can also enable it in Firefox. Check caniuse for AVIF for the latest numbers.

Currently, 61.27% of my blog's traffic supports AVIF (67.24% globally). Did you know that you can import your Google Analytics data into caniuse to see what percent of your traffic has support for a given feature? See Google Analytics + caniuse = MAGIC.

How do you use AVIF on Cloudinary? #

You can use AVIF on Cloudinary one of two ways:

• Use the f_avif format transformation
• Use the f_auto auto format transformation, but only after you sign up for the beta

I am lazy. I am not ashamed of this. I love the f_auto transformation because it means that instead of markup like this:

<picture>
    <source
      srcset="[baseURL]/q_auto,f_avif,w_300/file.jpg 300w, [baseURL]/q_auto,f_avif,w_600/file.jpg 600w, [baseURL]/q_auto,f_avif,w_928/file.jpg 928w, [baseURL]/q_auto,f_avif,w_1856/file.jpg 1856w"
      sizes="(min-width: 980px) 928px, calc(95.15vw + 15px)"
      type="image/avif"
      >
    <source
      srcset="[baseURL]/q_auto,f_webp,w_300/file.jpg 300w, [baseURL]/q_auto,f_webp,w_600/file.jpg 600w, [baseURL]/q_auto,f_webp,w_928/file.jpg 928w,[baseURL]/q_auto,f_webp,w_1856/file.jpg 1856w"
      sizes="(min-width: 980px) 928px, calc(95.15vw + 15px)"
      type="image/webp"
      >
    <img
      src="[baseURL]/q_auto,w_680/file.jpg"
      sizes="(min-width: 980px) 928px, calc(95.15vw + 15px)"
      alt="Large buffalo blocking the roadway" width="4001" height="2671" loading="lazy"
      >
</picture>

I can write much shorter markup and let Cloudinary do the work:

<img
  src="[baseURL]/q_auto,f_auto,w_680/file.jpg"
  srcset="[baseURL]/q_auto,f_auto,w_300/file.jpg 300w, [baseURL]/q_auto,f_auto,w_600/file.jpg 600w, [baseURL]/q_auto,f_auto,w_928/file.jpg 928w, [baseURL]/q_auto,f_auto,w_1856/file.jpg 1856w"
  sizes="(min-width: 980px) 928px, calc(95.15vw + 15px)"
  alt="Large buffalo blocking the roadway" width="4001" height="2671" loading="lazy"
  >

With f_auto, Cloudinary will pick the best file format based on the user's browser.

What are the tradeoffs of using AVIF on Cloudinary? #

Before you sprint to your code editor...

• AVIF transformations are slow
• AVIF transformations use up your credits faster

Let's talk about how to overcome those problems.

Reduce delays for your users #

Using AVIF increases your transformations usage because AVIF is intensive to encode. This also means that it takes longer for the transformation to occur. It's noticeable with delays of a few seconds.

For my blog, I overcome this obstacle by viewing new posts at different screens sizes before publishing. Then Cloudinary caches my AVIF images so they are ready for the next request.

This is not reasonable for larger projects. Instead, you can use eager transformations to transform on upload through the API.

The credit usage details #

At the time of writing (July 2021), Cloudinary counts AVIF transformations as follows:

• Images 2MP and below count as 1 transformation
• Each 1MP above 2MP will count as another 0.5 transformations

This seems high cost on the surface but is a good deal. I understood this once I saw how long AVIF transformations take compared to other formats. AVIF transforms are 70x-100x more CPU intensive than that of JPEG!

If you want to sign up for the f_auto beta, you can contact Cloudinary.

Results and next steps #

The buffalo picture (from my recent post on render-blocking resources) went from 198 kB to 97 kB. The results around my site vary based on the image, and the savings increase on larger (width) images.

Nowadays, we have devices with 2x, 3x, and higher DPR (device pixel ratio) screens. Humans can't see much better than 2x. Also, we can't detect lower quality as well on higher DPR images.

So my next step is to manually DPR-cap to 2x sizes with higher compression (lower quality) on the 2x srcset. I've implemented this for one client and saw great results. Now it's time to apply it to my blog!

Jake Archibald wrote up how to do this in Half the size of images by optimising for high density displays.

Yoav Weiss wants to run an origin trial for adding a max DPR value to srcsets. That will be exciting if it happens!

Have you started using AVIF images on your sites yet? What method are you using?

Don't miss a post. Sign up for my newsletter!

Pug photo credit: Karsten Winegeart on Unsplash.

Images WebPerf