Web

AVIF for Website Speed: Bandwidth Savings and Core Web Vitals

Images make up as much as 60–70% of an average web page's weight. They're the usual reason pages load slowly and tank their Google speed score. AVIF tackles the problem head-on: the same images weigh half as much. Let's unpack how that turns into a fast site, better Core Web Vitals and higher rankings — with ready-to-use code to ship.

A website open on a laptop — page load speed is largely determined by the weight of its images
Images are a page's heavyweight. Making them lighter is the most direct way to speed up a site. Photo: Pexels

Why images slow down a site

Open the developer tools on any website and look at the Network tab. Odds are images turn out to be the heaviest resources — heavier than all the HTML, CSS and JavaScript combined. According to web almanacs, media consistently accounts for the bulk of page weight.

The logic is simple: the more bytes you have to download, the longer the page takes to load — especially on mobile networks. And a slow page loses visitors: people just close the tab before it finishes. That's why "make the images lighter" is the single most effective lever for speeding up almost any site.

The gist in one paragraph

AVIF doesn't make your server faster. It makes the image files themselves smaller — about half the size of JPEG. Fewer bytes → faster load → better speed metrics → higher rankings and happier visitors.

How much bandwidth AVIF really saves

At comparable quality AVIF weighs about 50% less than JPEG and 20–30% less than WebP. Let's translate that into practice. Say you run an online store:

~50%weight saved vs JPEG
×30photos on a catalogue page
100s of GBbandwidth saved per month

For one image, a 250 KB difference seems trivial. But multiply it by dozens of images and thousands of visits per day, and you save hundreds of gigabytes of bandwidth a month. That cuts hosting/CDN bills and, more importantly, speeds up the page for every single visitor.

A website with bold banners and photos on a laptop — media-heavy pages benefit from AVIF the most
The heavier a page is on images, the bigger the speedup AVIF delivers. Photo: Pexels

AVIF and Core Web Vitals (LCP)

Google measures a site's real-world speed with the Core Web Vitals set and factors them into ranking. The most image-centric of them is LCP (Largest Contentful Paint): the time it takes to render the largest element on screen. On most sites that element is the main image (a banner, an article cover, a product photo).

The conclusion writes itself: if you make the main image half the weight, it loads faster and LCP improves. And a good LCP means:

  • A green score in PageSpeed Insights and Search Console.
  • A ranking boost — speed is one of Google's signals.
  • Lower bounce rate — visitors don't abandon a slow page.
LCP almost always comes down to the weight of the main image. Lighten it with AVIF and the metric improves almost automatically.

How to deploy it: picture tag with fallback

The main fear about AVIF is "what if it doesn't open for someone?" The solution is elegant: the <picture> tag. You list several formats in descending order of "modernity," and the browser takes the first one it understands.

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description" width="1200" height="800" loading="lazy">
</picture>

Here's how it works: Chrome and Firefox grab the .avif, older Safari takes the .webp, and a very old browser falls back to the .jpg in the <img> tag. Everyone sees the picture, but modern browsers get the lightest file. The width and height attributes are mandatory — they reserve space and keep the layout from "jumping" (which improves the CLS metric).

Tip

For the main above-the-fold image (the LCP element) use loading="eager" and, where possible, fetchpriority="high"; use loading="lazy" for everything else. That way the browser loads the hero image first and the secondary ones as you scroll.

Common mistakes when moving to AVIF

To keep the rollout from backfiring, avoid the usual slip-ups:

MistakeThe riskThe right way
Serving only AVIF, no fallbacksome users see no imagesalways use picture with JPG/WebP
AVIF quality set too highfile no lighter than JPEGpick quality ~50–65
Converting from a squeezed JPGartifacts get baked inencode from the original
No width/height on imglayout shifts (poor CLS)always specify dimensions

Choosing between AVIF and WebP as your primary format is a topic of its own. If your audience is on older devices, it's sometimes wiser to start with WebP. We covered this in WebP vs AVIF.

How to make AVIF versions of images

To serve AVIF you first have to create it from your originals. For a large site, build tools (avifenc, sharp, CMS plugins) are convenient. But for small projects and one-off tasks, converting online is simplest:

1

Take the original

Best is the source JPG or PNG at full quality, not re-compressed.

2

Convert to AVIF

Upload the file to a converter and get a light .avif back.

3

Add it to picture

Place the AVIF next to JPG/WebP and reference them in the tag.

Make your images lighter for the web

The FormatZ converter turns your JPGs into compact AVIF — preserving EXIF and the ICC profile. All in your browser, free, no install.

Convert JPG to AVIF

If your originals are PNG, use PNG to AVIF. And to test what a given AVIF looks like, you can always convert it back to JPG.

Who benefits the most

AVIF pays off most where there are many images and speed matters:

  • Online stores — hundreds of product photos, with a direct link between speed and conversion.
  • Media and blogs — heavy covers and illustrations in every article.
  • Landing pages — a big hero banner that is itself the LCP element.
  • Portals with mobile audiences — where every saved kilobyte speeds up loading on a weak network.
A laptop with an open website outdoors — on mobile and slow networks the savings on image weight are especially noticeable
On mobile internet a light AVIF is especially valuable: fewer bytes, faster load. Photo: Pexels
There's no direct CPU speedup — the win is that images weigh about half as much as JPEG. On pages where images dominate the weight (most sites), switching to AVIF cuts download size by 40–60% and noticeably improves the time to render the main content (LCP).
Yes, indirectly. Google factors Core Web Vitals into ranking, and the key LCP metric depends directly on the weight of the main image. A light AVIF loads faster, LCP drops, the page scores better on speed — and that's one of the ranking signals.
Nothing bad, if you use the picture tag. The browser picks the first supported format itself: it tries AVIF, falls back to WebP if that fails, and to JPG as a last resort. The user always sees an image; modern browsers just get the lightest variant.
No — quite the opposite. Keep JPG (or WebP) as a fallback inside the picture tag for browsers without AVIF support. The ideal setup is to hold each image in two or three formats and let the browser choose. It uses little extra space and keeps compatibility at 100%.
Convert your originals (JPG or PNG) to AVIF — for example in the FormatZ online converter. For batch-processing many files, command-line tools like avifenc or sharp are handy, but for one-off tasks and small sites a converter is more than enough.