Every performance audit I run ends up at the same place: the largest image on the page. It’s nearly always what the browser reports as the Largest Contentful Paint, so its size and format decide how quickly the page feels ready.

The usual advice is “use WebP, or AVIF if you can”. I wanted to know how much difference that actually makes, so I took four images from this site and measured.

How I tested

  • Images: four from this site, chosen for variety. A landscape photo, a portrait photo, a photo with a plain background, and a pencil sketch.
  • Size: each resized to its display width, capped at 1,200 pixels and never enlarged.
  • Encoders: sharp 0.35 (libvips 8.18), the library Next.js uses to optimise images. JPEG went through mozjpeg; WebP and AVIF used sharp’s default settings.
  • Quality levels: 30 to 95 in steps of 5 for each format. That’s 14 levels × 3 formats × 4 images = 168 files.
  • Measurements: file size, time to encode, and SSIM, a standard score for how closely an image matches the original. 1.0 means identical. Above about 0.98, most people can’t spot a difference at normal viewing size.

One caveat: I measured SSIM on brightness only, with 8×8 windows. It’s a well-known method and good enough to compare formats, but it isn’t a substitute for looking at the images yourself.

Result 1: at the same visual quality, AVIF is roughly half the size of JPEG

This table shows the smallest file in each format that scored at least 0.98 SSIM.

ImageJPEGWebPAVIFAVIF vs JPEG
Landscape photo, 1200×62521.4 KB17.5 KB11.9 KB−44%
Portrait photo, 736×130854.1 KB49.8 KB27.2 KB−50%
Photo with plain background, 1080×134917.9 KB13.5 KB6.7 KB−63%
Pencil sketch, 1119×104926.4 KB25.0 KB15.2 KB−42%
Smallest file reaching SSIM ≥ 0.98, from quality settings 30 to 95.

AVIF came out 42–63% smaller than JPEG at the same score. WebP’s advantage was smaller than its reputation: 5–25% smaller than JPEG, and on the pencil sketch barely smaller at all.

Result 2: “quality 75” means something different in each format

This is the result that surprised me most. Encode all three at the same quality setting and AVIF looks like the worst choice:

Portrait photo at quality 75SizeSSIM
JPEG (mozjpeg)64 KB0.986
WebP33 KB0.975
AVIF56 KB0.993

AVIF at quality 75 is 70% bigger than WebP at quality 75. That’s because it’s also far better quality, well past the point anyone would notice. Quality numbers aren’t a shared scale. Each encoder defines its own.

This matters because Next.js uses quality 75 for every format unless you configure otherwise. If you switch on AVIF and keep the default, you get beautiful images that are bigger than they need to be. For AVIF, a quality between 45 and 55 matched what the other formats delivered at 75 in my tests.

Result 3: AVIF is much slower to encode

Portrait photoEncode time at quality 50
JPEG (mozjpeg)42 ms
WebP56 ms
AVIF352 ms
Single encode on an Apple M1 with sharp’s default effort settings.

Across all four images, AVIF took 5 to 9 times longer to encode than JPEG. The Next.js documentation says AVIF “generally takes 50% longer to encode” than WebP. With sharp’s defaults on my machine, the gap was much wider.

Visitors don’t usually feel this. An image is encoded once, cached and then served to everyone. But the first person to request each size waits for it, and a page with many images can keep a small server busy. If you resize images on demand, keep that in mind.

What this means for LCP

Here’s a back-of-envelope calculation at Lighthouse’s mobile speed of 1.6 Mbps, which works out to about 200 KB per second:

Portrait photoSizeDownload time at 1.6 Mbps
The original PNG in the repository823 KB~4.1 s
JPEG, SSIM ≥ 0.9854 KB~0.27 s
AVIF, SSIM ≥ 0.9827 KB~0.14 s

Moving from a well-compressed JPEG to AVIF saves around 130 ms on a slow phone. That’s worth having, but it’s small next to the 4 seconds you save by not sending the original PNG at all. In my audits, the expensive mistakes are almost always the second kind: a 3 MB hero image, a PNG photo, or a 2,400-pixel image squeezed into a 400-pixel box.

My settings for a Next.js site

// next.config.js
module.exports = {
  images: {
    // AVIF for browsers that support it, WebP for the rest.
    formats: ["image/avif", "image/webp"],
    // Next.js 16 only accepts qualities you list here.
    qualities: [50, 75],
  },
};
// The hero image is the LCP element: load it early, at an AVIF-friendly quality.
<Image src={hero} alt="…" sizes="100vw" quality={50} preload />

Next.js caches each format separately, so enabling both roughly doubles image storage. On most sites that’s a fair trade.

In order of impact

  1. Send the right size. Use sizes so a phone never downloads a desktop image. This has the biggest effect on most sites.
  2. Never send PNG for a photo. PNG is for flat graphics and transparency.
  3. Switch on AVIF, and lower its quality setting to match. Expect files 40–60% smaller than JPEG.
  4. Load the LCP image early. Don’t lazy-load it, and let the browser know it matters.
  5. Check with your eyes. Scores like SSIM are a guide. Open the image at full size and look at faces, text and gradients, where compression shows first.

The format debate gets most of the attention, but in my results it was the smaller saving by far. Switching the portrait from JPEG to AVIF saved 27 KB; not sending the original PNG saved 769 KB.