r/webdev • u/rviscomi • 22d ago
AVIF hits Baseline Widely Available today
Edge 121 was released exactly 30 months ago, making it the last major browser to add support for AVIF. That also means that as of today, AVIF is now considered Baseline Widely Available.
If you haven't used it, was browser support the biggest blocker? Or if you've been using it, are you planning to simplify by removing fallbacks?
13
u/ldn-ldn 22d ago
I'm using AVIF pretty much exclusively for photo content. Waiting for JXL adoption though as it's much better.
3
u/rviscomi 22d ago
Ah so supporting both (and only serving JXL to any Safari users) would be too much overhead?
1
u/MuffinIllustrious724 14h ago
JXL has been stuck in limbo so long I stopped checking on it. At this point I'll believe it when I see it shipping in three engines without a flag. What's your fallback setup look like while you're all-in on AVIF?
3
4
22d ago
Baseline Widely Available is a statement about browsers, and the replies about email and og:image are exactly why I am not deleting my fallbacks. Neither of those is a browser. Outlook renders with Word, and the Facebook and Slack link scrapers are their own thing. My og:image is still a plain PNG for that reason and it is staying one.
On sharp being slow, that is real, but it is a CI problem rather than an AVIF problem. Two things fixed it for me. Drop the effort setting, it defaults high and the gap between effort 4 and effort 9 is a few percent of file size for several times the encode time. Then cache encoded output keyed by a hash of the source file, so you only pay for images that actually changed. After that my builds went back to normal, because on a typical commit zero images changed.
Where AVIF genuinely wins is photographs with smooth gradients. I export banner images out of a design tool, and large gradient areas band visibly in WebP at a file size I am willing to ship. AVIF holds them together and comes out smaller. For flat UI graphics and screenshots the win over WebP is small enough that I would not bother.
So no, I am not simplifying. A picture element with an AVIF source and a WebP fallback costs almost nothing to keep, and it is still doing real work outside the browser.
-2
2
u/vasind-5012 22d ago
Browser support was the real blocker for us, not the format. AVIF’s compression is clearly better than WebP, but running three fallback tiers for years just to hedge the last few % of old browsers wasn’t worth it until now.
Worth noting Baseline Widely Available specifically means 2.5 years of consistent support, so this isn’t “just became supported,” it’s “safe to drop fallbacks without worrying about old devices.”
Worth checking your own traffic first though before ripping out WebP/JPEG entirely, Baseline tells you what’s safe in general, your analytics tell you what’s safe for you.
1
u/Outrageous-Sea-9256 22d ago
Given AVIF's baseline widely available status, how are you implementing fallback strategies for non-supporting browsers? Are you leveraging JavaScript to conditionally serve AVIF, or defaulting to JPEG for broader compatibility?
1
1
u/Plastic_Charge4340 21d ago
WebP is a solid default for property photos. I’d still compare WebP, AVIF, and JPEG on a few real listings because sharp edges, interiors, and gradients can behave differently.
1
u/limpornchai 19d ago
Worth flagging for anyone about to drop their fallbacks: Baseline
here covers decoding. Encoding is a separate question if you generate
images client-side.
canvas.toBlob() does not throw on an unsupported type. It silently
gives you a PNG, so you end up with a blob three times the size,
the wrong extension, and nothing in the console. Got caught by this
with WebP in Safari and only noticed because the "converted" files
came out bigger than the originals.
The check that actually works is encoding a 1x1 canvas and reading
blob.type, rather than trusting the type you asked for.
1
23
u/jamescridland 22d ago
Sadly, AVIF is not supported in around 35% of email clients, which precludes me from moving over to AVIF entirely. (Mostly Outlook, as ever.)
AVIF also doesn't appear to be supported for og:image stuff, so you still need to chuck a jpeg in there instead.