Modern image formats are next-generation file formats — primarily WebP and AVIF — that achieve significantly smaller file sizes than legacy JPEG, PNG, and GIF at equivalent visual quality. Performance audits flag any JPEG, PNG, or GIF where converting to WebP or AVIF would save more than ~8 KB. On image-heavy pages, that single change is often the largest single byte-weight win available.
Think of legacy formats as shipping a hardback book and modern formats as shipping the same content as a paperback — same story, half the weight, lower postage. The reader can't tell the difference, but everyone in the supply chain feels it.
Images are the single largest contributor to page weight on most sites — typically 40–55% of total bytes (HTTP Archive). That means image format choice has more leverage on perceived speed than almost any other optimization.
Consider a typical 1600×900 hero photograph saved at perceptually equivalent quality across formats. The same source pixels — wildly different bytes on the wire:
Source: hero-1600x900.png (lossless reference)
JPEG (q=80) -> 220 KB baseline
PNG-8 (paletted) -> 480 KB +118% (truecolor PNG would be ~1.6 MB)
WebP (q=80) -> 150 KB -32% vs JPEG
AVIF (q=55) -> 105 KB -52% vs JPEG, -30% vs WebP
Audit triggers when (legacy_size - modern_size) > 8 KB.
Every legacy image above 25 KB is essentially guaranteed to flag.AVIF's extra compression comes from the AV1 video codec — better intra-frame prediction, more efficient entropy coding, and support for 10/12-bit color depth. WebP, derived from the VP8 video codec, sits between JPEG and AVIF on both efficiency and encode speed.
The ~8 KB savings threshold exists because the conversion overhead (extra fallback markup, build-time CPU, multiple stored variants) only pays off when the per-image saving is meaningful. Tiny icons and 5 KB thumbnails are intentionally not flagged — the win isn't worth the engineering tax. Hero images, product photos, and inline article photography almost always clear the bar by 10×.
Modern-format coverage is measured by performance audits as a list of specific URLs that would save more than ~8 KB if converted. Don't guess — pull the list and convert them in priority order.
The <picture> element is the standard pattern: list AVIF first, WebP second, JPEG/PNG as the universal fallback. The browser picks the first <source> it can decode.
<picture>
<source srcset="hero.avif" type="image/avif" />
<source srcset="hero.webp" type="image/webp" />
<img
src="hero.jpg"
alt="Mountain sunrise"
width="1600"
height="900"
loading="eager"
fetchpriority="high"
/>
</picture>Always keep width and height on the inner <img>— they're what the browser uses for layout reservation regardless of which source it picks.
For static and statically-built sites, generate AVIF + WebP + JPEG at build time. The sharp library (the engine behind most build pipelines and Next.js Image) produces all three in a single pass.
import sharp from 'sharp';
const input = sharp('hero.jpg');
await Promise.all([
input.clone().avif({ quality: 55 }).toFile('hero.avif'),
input.clone().webp({ quality: 80 }).toFile('hero.webp'),
input.clone().jpeg({ quality: 80, mozjpeg: true }).toFile('hero.jpg'),
]);Next.js <Image>, Nuxt <NuxtImg>, Astro <Image>, and Gatsby StaticImage all generate WebP/AVIF and emit a <picture> automatically. If you're already on one of these frameworks, switching <img> tags to the framework component fixes the audit globally.
An image-optimization service (a CDN that transforms on the fly based on the Acceptheader) is the lowest-engineering path: upload one master JPEG, and the service returns AVIF to AVIF-capable clients, WebP to others, and the original as a final fallback. Useful when you can't change the build pipeline.
Modern format alone doesn't solve serving a 1600 px hero to a 360 px phone. Combine the format switch with srcset so each device gets the right resolution and the right format.
<picture>
<source
type="image/avif"
srcset="hero-480.avif 480w, hero-960.avif 960w, hero-1600.avif 1600w"
sizes="(max-width: 600px) 100vw, 1600px"
/>
<source
type="image/webp"
srcset="hero-480.webp 480w, hero-960.webp 960w, hero-1600.webp 1600w"
sizes="(max-width: 600px) 100vw, 1600px"
/>
<img
src="hero-960.jpg"
srcset="hero-480.jpg 480w, hero-960.jpg 960w, hero-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 1600px"
alt="Mountain sunrise"
width="1600"
height="900"
/>
</picture>AVIF at quality 55 is visually indistinguishable from JPEG at quality 90 for most photographic content. Default quality presets are usually conservative — drop AVIF to q=50–60 and WebP to q=75–82and re-eyeball the worst-case images. Don't leave a 50% saving on the table.
CSS background-image doesn't use <picture>, so use image-set() to give the browser a format choice.
.hero {
background-image: image-set(
"hero.avif" type("image/avif"),
"hero.webp" type("image/webp"),
"hero.jpg" type("image/jpeg")
);
}Most sites have years of legacy image uploads. A one-time batch job that walks the asset folder and emits AVIF + WebP next to every JPEG/PNG fixes the entire backlog. Re-run it whenever new images land — wire it into the build, not a one-off script.
What's happening: The encoder is at default settings, which are tuned for slow, high-quality encodes. AVIF is sensitive to encoder settings — bad presets can produce files larger than the JPEG.
Fix: Use quality: 50–60 and effort: 4–6 in sharp (or cqLevel in libavif). Validate by spot-checking 5 images: AVIF should beat WebP by ~20% at equivalent visual quality.
What's happening: The <source> elements are missing the type attribute, or the source order is wrong. Without type, the browser falls through.
Fix: Every <source> needs type="image/avif" or type="image/webp". Order matters — most-efficient first (AVIF), then WebP, then the <img> fallback.
What's happening: Older CMS platforms whitelist a fixed set of MIME types and reject modern formats at upload time.
Fix: Don't upload modern formats — upload the original JPEG/PNG and convert at delivery time, either via a build-step transform or an image-optimization service. The CMS keeps the master, the CDN serves the modern variant.
What's happening: The CDN has the legacy URL cached and isn't respecting the Accept header for variant selection.
Fix: Either include the Accept header in the cache key (Vary: Accept) or use distinct URLs per format (hero.avif, hero.webp, hero.jpg). The latter is more cache-friendly.
| Format | Typical Size vs JPEG | Browser Support (2026) | Best Used For |
|---|---|---|---|
| AVIF | ~50% smaller | ~95% (Safari 16+, Chrome 85+, Firefox 93+) | Hero photography, large product shots — anywhere bytes matter most |
| WebP | 25–35% smaller | ~97% (everything since 2020) | Universal modern fallback; lossless replacement for PNG |
| JPEG (mozjpeg) | baseline | 100% | Final fallback inside <picture> for the long tail |
| PNG | +50–200% larger | 100% | Only when truly lossless and transparency are both required and WebP/AVIF aren't options |
| GIF | +200–500% larger | 100% | Avoid — replace with animated WebP, AVIF, or an MP4/WebM video |
| SVG | n/a (vector) | 100% | Logos, icons, illustrations — any image that's drawn rather than photographed |
Use both, with <picture>. Browsers that support AVIF (~95% as of 2026) will pick it for the largest savings; the rest fall back to WebP (~97% support); the long-tail 2–3% get JPEG. You don't pick one — you serve the best one each browser can handle.
For most consumer audiences, yes — WebP support is at 97%+ in 2026. But the <picture> + JPEG fallback adds almost no engineering cost and protects the long tail (older devices, niche browsers, embedded webviews). Keep the fallback.
No. Google indexes WebP and AVIF directly and has done so for years. The performance gains (lower LCP, lower page weight) actually help rankings via Core Web Vitals. Make sure alt text and surrounding context still describe the image clearly.
Yes, urgently. Animated GIFs are typically 5–10× larger than the equivalent animated WebP, and 10–20× larger than an MP4 or WebM video at equivalent quality. For anything over a few seconds, use <video autoplay muted loop playsinline> with an MP4/WebM source.
Yes. Always keep the lossless or highest-quality original — re-encoding from a lossy WebP/AVIF compounds compression artifacts. The master JPEG/PNG (or ideally the source RAW/PSD) is the input to every future format you might generate.
Not directly — they cite text. But AI answer engines disproportionately cite pages that rank well in traditional search, and Core Web Vitals (especially LCP, which is image-driven on most pages) feed those rankings. Heavy images hurt LCP, which hurts rank, which hurts your citation odds in AI Overviews and Perplexity. The chain is real even if it's indirect.
Roughly 1.5–1.8× the original storage when you keep AVIF + WebP + JPEG variants. That's usually trivial compared to the bandwidth saved on every request — most sites recoup the storage cost within their first month of bandwidth bills.
Modern image formats are the highest-leverage performance fix on most sites — a single change that cuts 25–50% of image bytes, directly improves LCP, lowers bandwidth bills, and feeds every Core Web Vital that matters for ranking. The 8 KB audit threshold means the win is real on every flagged image; you're not chasing rounding errors.
The pattern is settled: <picture> with AVIF, WebP, and a JPEG fallback, plus srcset for responsive sizing. Build it once into your image pipeline (or your framework's image component) and every future upload inherits the optimization for free. Run a Greadme deep scan to get the exact list of images to convert first, ranked by byte savings.