You’ve read the guides. AVIF vs WebP vs JPEG vs PNG. Lossy vs lossless. Quality sliders. Responsive breakpoints. Lazy loading libraries with 14 configuration options.
Most of it is noise. Images account for over 60% of total page weight on most websites, but only 3–4 image optimization decisions actually move your LCP score. This isn’t a 15-step encyclopedia. It’s the code review I’d give you on a PR where the hero image is an uncompressed 4000px PNG.
The Format Question, Answered in 30 Seconds
The format wars are over. AVIF won on compression. WebP won on encoding speed. JPEG is the fallback. Ship all three.
Here are real numbers — not percentages. A 2MB PNG hero image compresses to roughly 340KB as WebP and 180KB as AVIF. A 200KB product photo JPEG drops to about 140KB as WebP and 95KB as AVIF.
AVIF is approximately 50% smaller than JPEG at equivalent visual quality. WebP lands 25–34% smaller. Both support transparency. AVIF adds HDR and 10-bit color depth if you need it — WebP tops out at 8-bit. WebP encodes and decodes faster, which matters if your build pipeline processes thousands of images.
Browser support in 2026: AVIF sits at roughly 93%, WebP at 95%. Safari has supported AVIF natively since March 2023. The “browser support” excuse for skipping AVIF died over two years ago.
Quick decision: serve AVIF with WebP fallback for everything. If your build pipeline chokes on AVIF encoding time, WebP-only is still a massive win over JPEG.
But here’s what most AVIF vs WebP comparison articles won’t say: the difference between serving AVIF and WebP matters less than whether you told the browser which image to prioritize.
The 4 Things That Actually Move LCP
Format choice is one of those things. Here are the other three — including the one most devs skip entirely.
1. Serve modern formats with the picture element.
AVIF first, WebP second, original as fallback. Order matters — the browser picks the first source it supports.
<picture>
<source type="image/avif" srcset="hero.avif">
<source type="image/webp" srcset="hero.webp">
<img src="hero.jpg" alt="Description" width="800" height="450">
</picture>
Always include type attributes. Without them, the browser may download the wrong format and waste bytes. Always set width and height on the img to prevent layout shift — that’s a separate Core Web Vitals metric you don’t want to fight.
2. Set fetchpriority="high" on your LCP image.
This is the single biggest LCP win most developers miss. The browser doesn’t know your hero image is the most important resource on the page unless you tell it. The LCP threshold for “good” is under 2.5 seconds, and this attribute alone can shave hundreds of milliseconds off your score.
Pair it with a preload link in the <head>:
<link rel="preload" as="image" type="image/avif"
href="hero.avif" fetchpriority="high">
If you’ve read our lazy loading guide, you already know the corollary: never lazy load your LCP image. That’s the most common mistake I flag in PRs. The hero loads eagerly with fetchpriority="high". Everything else waits.
3. Serve properly sized images.
A 4000px-wide image displayed at 800px wastes 80% of its bytes. Use srcset with sensible breakpoints and a sizes attribute that matches your actual layout:
<img srcset="hero-480.avif 480w,
hero-800.avif 800w,
hero-1200.avif 1200w,
hero-1600.avif 1600w"
sizes="(max-width: 800px) 100vw, 800px"
src="hero-800.jpg"
alt="Description"
width="800" height="450"
fetchpriority="high">
Four breakpoints. That covers phones, tablets, laptops, and desktops. You don’t need eight. You don’t need every 100px increment. This responsive images setup handles 95% of real-world layouts.
4. Lazy load everything below the fold.
Add loading="lazy" to every image outside the initial viewport. Native browser support, no JavaScript library required.
<img src="feature.jpg" alt="Description"
width="600" height="400" loading="lazy">
Those are the four things. If your site scores poorly on image-related core web vitals and you haven’t done all four, start here before touching anything else.
But does that mean you need to convert every single image on your site?
When to Stop Optimizing (The Part No One Tells You)
No. And this is where I’ll save you engineering time that every other image compression best practices guide will happily waste.
A 50KB JPEG that’s already well-compressed? Converting it to AVIF saves maybe 15KB. If you don’t already have format conversion in your build pipeline, that saving isn’t worth adding the complexity.
Below-the-fold decorative images under 100KB? They’re lazy loaded. They don’t touch LCP. Optimize them last — or don’t.
The diminishing returns math: going from an unoptimized PNG to WebP saves 60–70%. Going from WebP to AVIF saves another 20–30%. Going from AVIF at quality 60 to quality 50 saves 10–15% but starts showing compression artifacts. Know where to stop.
The real bottleneck is almost never image format. It’s serving a 2000px image to a 400px viewport. It’s not using fetchpriority. It’s lazy loading the hero image by accident. Fix those structural problems first. Format conversion is the polish, not the foundation.
And if your images are already optimized and LCP is still red? The problem probably isn’t images at all. Check your JavaScript bundle or your third-party scripts — those are the usual culprits hiding behind a clean Lighthouse image audit.
Now let me give you something you can copy straight into production.
The Complete Picture Element (Copy, Paste, Ship)
Here’s a production-ready hero image with everything wired up — AVIF with WebP fallback, responsive srcset, proper sizes, fetchpriority, and the matching preload tag:
<!-- In <head> -->
<link rel="preload" as="image" type="image/avif"
imagesrcset="hero-480.avif 480w,
hero-800.avif 800w,
hero-1200.avif 1200w,
hero-1600.avif 1600w"
imagesizes="(max-width: 800px) 100vw, 800px"
fetchpriority="high">
<!-- In <body> -->
<picture>
<source type="image/avif"
srcset="hero-480.avif 480w,
hero-800.avif 800w,
hero-1200.avif 1200w,
hero-1600.avif 1600w"
sizes="(max-width: 800px) 100vw, 800px">
<source type="image/webp"
srcset="hero-480.webp 480w,
hero-800.webp 800w,
hero-1200.webp 1200w,
hero-1600.webp 1600w"
sizes="(max-width: 800px) 100vw, 800px">
<img src="hero-800.jpg" alt="Description"
width="800" height="450"
fetchpriority="high">
</picture>
Three mistakes I flag in every other review: putting WebP before AVIF (the browser takes the first format it supports, so AVIF should be first), forgetting type attributes (browser guesses wrong and downloads the fallback), and using srcset without sizes (browser can’t calculate which resolution to fetch).
One shortcut worth knowing: if your CDN supports content negotiation — Cloudflare, Fastly, and Imgix all do — you can skip the picture element entirely. One img tag, and the CDN serves the right format based on the browser’s Accept header. Less markup, same result.
That’s the Whole Guide
You came here expecting another 15-step image optimization checklist. You got four things:
- AVIF → WebP → JPEG via
picture fetchpriority="high"on your LCP imagesrcset+sizesfor responsive deliveryloading="lazy"on everything below the fold
Do those four, and you’ve captured the vast majority of available LCP improvement from images. Everything else is diminishing returns — and your engineering time is worth more than 15KB of savings on a below-the-fold decorative image.
If your images are already optimized and LCP is still slow, the problem isn’t images. Look at your JavaScript, your server response time, or your interaction performance. That’s a different code review.
Now go ship the picture element. Your Lighthouse score — and your users on 3G — will notice.