menu

Should I use AVIF files on my Craft CMS website?

Our case study. Your results my vary.

Published in Web 101 on Sep 25, 2025 by Blue Coast

Facts about AVIF:

  • Introduced by the Alliance for Open Media (AOM), extended the use of the AV1 video codec to still images
  • Supported in Craft since version 3.9.5
  • Has a higher compression efficiency with file sizes 20-30% smaller than WebP
  • Supports transparency, animation and HDR

Seems like using AVIF in Craft is a no brainer. Not so fast.

Here's another fact we weren't aware of until we implemented AVIF on our latest project:

"Converting to and from AVIF with ImageMagick is significantly more resource-intensive, particularly for encoding, compared to older formats like JPEG and WebP. This is due to the advanced and computationally complex compression algorithms used in the AV1 video codec, on which AVIF is based. Implications for ImageMagick users: When using ImageMagick for bulk processing or on servers with limited resources, the high demands of AVIF can lead to performance issues."

How bad could it be though?

Right of the bat, we felt the pain of slow processing our images. After scaling up our server to the following, the processing time was still unacceptable:

RAM: 8 GB, Disk: 50 GB, CPU: 4 Core Processor, Bandwidth: 5 TB

The queue manager filled with image transforms and nothing seemed to be processing so we elected to add: generateTransformsBeforePageLoad(true) in our config file to prevent the queueing from getting overloaded. This resulted in an extensive wait time for pages to render initially which sometime resulted in multiple timeouts.

We are using AWS S3 for storing both the original image as well as the transformed images. This undoubtedly adds to the processing time - although this was never an issue when using WEBP. For reference, here is a sample of our image processing function:

                    
                    .
{% set image = entry.image.one() ?? null %}
{% if image is not null %}

    <picture>
      {% set avifTransform = { format: 'avif', mode: 'fit', quality: 80 } %}
      {% set jpgTransform = { format: 'jpg', mode: 'fit', quality: 80 } %}
      <source type="image/avif" srcset="{{ image.getSrcSet([1032, 2352], avifTransform) }}">
      <source type="image/jpeg" srcset="{{ image.getSrcSet([1032, 2352], jpgTransform) }}">
      <img width="{{ image.width }}" height="{{ image.height }}" alt="{{ image.alt }}">
    </picture>

    {% if image.caption | length %}
	<figcaption>
		{{ image.caption }}
	</figcaption>
    {% endif %}
{% endif %}
                    
                    

As shown above, there are four large hero images being processed by this code which are being downloaded from AWS S3, processed and then re-uploaded to AWS. This is a heavy lift although, once again, manageable when using a combination of JPG and WEBP. Varying the image quality did not seem to effect the processing time.

What we'll do in the future

Although it's possible to tune a server to give more RAM to ImageMagick by increasing it's resource limit, that is not an option for us.

I think there's still a place for AVIF in our workflow - perhaps to process smaller, inline images with fewer srcset variations. For larger and hero images, we're sticking with WEBP for now.

We'd love to hear your thoughts and experiences with AVIF in the comments below.
Blue Coast