It was still encoding in the morning
The exciting new format arrived this fall, and the older one quietly became safe to use everywhere.
I pointed an AVIF encoder at a client’s product photography before bed and it was still running when I opened the laptop in the morning. A few hundred images. It hadn’t gotten to the ones I actually cared about.
The files it had finished were beautiful. About half the size of the JPEGs sitting next to them, better than half on the big lifestyle shots. I put a few pairs side by side at full size and couldn’t pick them apart.
Then I turned it off, because the thing that changed my week wasn’t that one.
The understudy goes on
Two things happened to image formats this fall and ofc I’ve only been sent links about one of them.
Chrome added AVIF in August. A genuinely new format, built out of a video codec, smaller files than anything else we’ve got. That’s the one with the posts about it.
And Safari 14 added WebP in September, which means WebP now works in every browser anybody is actually using.
WebP has been around since 2010 and in Chrome nearly that long. The only reason it never became anyone’s default is that Safari didn’t have it, so every site kept a full set of JPEGs for the Safari share of its traffic. Which meant maintaining two sets of files to save bytes for some of your visitors, and most people did that cost-benefit and reasonably declined.
For photographs it’s usually 25 to 35% smaller than a JPEG at a quality nobody can tell apart. It does transparency, so it takes over from the enormous PNGs that exist purely because something needed an alpha channel. It does animation, so the 4 MB GIF can finally die. None of that is new. You can just use it now.
You still keep a fallback, because you always keep a fallback, and old browsers and email clients and whatever a client pastes into a newsletter all still want a JPEG. But the fallback is a fallback now instead of being what most of your visitors get.
The one thing worth doing today is turning WebP on for photographs and not thinking about it again.
Three strikes
None of which is me being down on AVIF. It’s a bigger jump than WebP by a wide margin, and on gradients and large photographic backgrounds the difference isn’t subtle. It also comes apart much more gracefully, staying coherent at sizes where a JPEG has already turned into a mess of blocks.
It’s just that three things make it impractical this year, and the first one is why I have a story.
Encoding is slow. Not “a bit slower,” seriously slow. The better part of a minute on a large photograph where a JPEG is finished before you’ve let go of the mouse. On a catalog that’s an overnight job, and on a site with a few hundred images it turns a build you can run on every commit into one you have to schedule and babysit.
It’s one engine. Chrome and Chromium, with Opera behind it. Firefox has it behind a flag you have to go and turn on yourself. Safari isn’t in the conversation, having only just gotten to WebP. So AVIF isn’t a replacement for anything, it’s an addition, and you’re now generating three formats of every photograph and maintaining a fallback for your fallback.
And it isn’t better at everything, which I did not expect. It came out of a video codec, and video codecs are tuned for what video contains, meaning photographs of the world. Push it on a screenshot, or on a product shot with a printed label in it, and the type goes soft. JPEG’s failure mode is blocky and obviously an artifact. AVIF’s is a faint blur. I think that’s worse, because it doesn’t read as damage, it reads as a bad photo.
The one image anybody commented on from that test page was a box shot with the ingredients panel facing camera. The note said the photo looked out of focus.
It wasn’t the photo.
Draw me a flowchart
Everybody wants a decision tree for this, me included. I’ve tried to draw one twice and it doesn’t work. I suspect that’s because the right answer depends on what’s in the picture instead of on what kind of file somebody handed you.
So here are the questions I ask instead, roughly in order.
Was it drawn, or was it photographed? If a person drew it, it’s SVG, and this is the least ambiguous rule in the whole business. Logos, icons, diagrams, charts. Resolution-independent, usually tiny, styleable with CSS, and it compresses beautifully because underneath it’s text. Every logo I’ve ever been handed as a 300 KB PNG should have been 4 KB of SVG.
Is there text or a hard edge in it? A screenshot of an interface, a photo of a document, a chart exported as a bitmap. PNG is often the right answer here and will beat everything else, because lossless compression of flat color is the exact thing it’s for, and every lossy format is going to fuzz the type. The ingredients panel again.
Is it a photograph? Then you’re in a compression trade, which is where WebP and AVIF live and where the percentages further up apply.
Does it move? Then it’s a video file, not an animated anything. An MP4 of a looping animation is routinely a tenth the size of the equivalent GIF, and that’s been true for about a decade.
First one wins
If you do generate more than one format, the browser picks, and the order in the markup matters, because the first type it recognizes is the one it takes.
<picture>
<source type="image/avif" srcset="hero-800.avif 800w, hero-1600.avif 1600w" sizes="…">
<source type="image/webp" srcset="hero-800.webp 800w, hero-1600.webp 1600w" sizes="…">
<img src="hero-800.jpg"
srcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
sizes="(min-width: 60rem) 40rem, 100vw"
width="1600" height="900"
alt="…">
</picture>The <img> is doing all the real work in there. It carries the alt text, the dimensions, the loading behavior and the fallback, and the <source> elements are advice. The width and height are for the layout jumping around while the page loads instead of for sizing. And sizes is the attribute everybody forgets, which will cost you more than the format choice ever will.
This should be generated and never typed. It’s an include, a partial, a shortcode. If a person is writing it by hand more than once, you’ve built a maintenance problem and filed it under optimization.
Neither of these is a codec
For my money the two things that beat every format decision on this page put together are both dull, and neither one is a format.
The dimensions. A 3000px image sitting in a 600px slot is throwing away 96% of what you paid to send, and converting it to AVIF just makes it a smaller waste. I wrote more or less this paragraph in 2015 about a hero I had never once opened, and it has held up depressingly well.
The quality setting. Most images go out at whatever number was in the box when somebody exported them, which is higher than anyone needs. Dropping a JPEG from quality 90 to 75 typically halves the file and is invisible in a blind comparison. That’s the same order of saving as switching format entirely, for no build complexity at all.
I’d add a third, which is whether anybody has opened the file and looked at it since it left the designer’s machine. On most sites the answer is no. The largest saving available is usually not a codec, it’s somebody sitting down with the network tab open and sorting by size.
What I actually turned on
SVG for anything drawn. PNG for text and flat graphics. WebP as the default for photographs with a JPEG behind it, now that WebP means everyone. AVIF by hand on the two or three biggest images on a site, where a minute of encoding buys something worth having, and not on the other few hundred.
I keep noticing that the format which changed what I do is the one with no news in it. Safari picked up something Chrome has had since I was in a different career, and the whole story is that a fallback I’ve been maintaining for years is finally just a fallback. Nothing to benchmark, nothing to demo, no reason for anyone to send it to me. It’s on a handful of client sites now and it took roughly 30% off the image weight of the photo-heavy pages, which is more than the exciting one has done for anybody yet. And I’d never have gone and checked if there hadn’t been an encoder sitting there at 7 am with the rest of the catalog still to go.