Google's Core Web Vitals — specifically LCP (Largest Contentful Paint) — are directly impacted by how fast your images load. A 2MB JPEG hero image can be the sole reason a page fails its LCP target. The same image as a well-optimised AVIF might be 300KB, loading in a fraction of the time.
Here's the definitive 2026 answer on format choice for web.
The short answer
- Photographs & product images: AVIF (with WebP fallback via
<picture>) - Logos, icons, UI elements: SVG (vector) or WebP lossless
- Screenshots with text: PNG or WebP lossless
- Animations: WebP animated or video (MP4/WebM)
- Maximum compatibility needed: JPEG (as fallback only)
Why AVIF wins for photos in 2026
AVIF has crossed the browser support threshold that matters. As of early 2026, global support exceeds 93% — meaning you can serve AVIF as your primary format and only need a fallback for roughly 7% of users (mostly on older iOS or Firefox versions predating 2021).
The compression advantage is significant enough to justify the implementation effort. For a typical e-commerce product image at 1200×1200px:
| Format | File size | LCP impact |
|---|---|---|
| JPEG (80% quality) | 320 KB | Baseline |
| WebP (80% quality) | 165 KB | ~48% faster |
| AVIF (80% quality) | 95 KB | ~70% faster |
A 70% reduction in the size of your LCP image is a guaranteed improvement in your Core Web Vitals score. For sites with many images, this also directly reduces CDN costs and mobile data usage for your users.
How to implement AVIF with fallback
The standard pattern for serving AVIF with graceful fallback is the HTML <picture> element:
<picture> <source srcset="image.avif" type="image/avif" /> <source srcset="image.webp" type="image/webp" /> <img src="image.jpg" alt="Description" loading="lazy" /> </picture>
Browsers pick the first format they support. This ensures AVIF for modern browsers, WebP for slightly older ones, and JPEG as the final fallback — all without JavaScript, without detection scripts, and with zero maintenance overhead.
If you're using Next.js, the next/image component handles this automatically — it serves AVIF to supporting browsers and falls back to WebP or JPEG. No manual <picture> elements needed.
WebP: still a very solid choice
If converting to AVIF isn't feasible right now — whether due to CMS limitations, encoding time, or tooling — WebP is still an excellent choice. It offers ~50% size reduction over JPEG with 97% browser support.
WebP is also significantly faster to encode than AVIF, which matters when you have large libraries to convert. For sites with thousands of product images, converting to WebP is faster to execute and still delivers a massive performance improvement over JPEG.
PNG: use it only where lossless matters
PNG should only appear on websites for content that genuinely requires lossless quality: logos, icons, UI elements, screenshots with text. For these, PNG (or better, WebP lossless) is the right call.
Using PNG for photographs on a website is one of the most common and costly performance mistakes. A photo that should be 150KB as AVIF might be 3MB as PNG, with no visible quality benefit to any user. Always use lossy formats for photographic content.
Converting your image library locally
The practical challenge is conversion. You have an existing library of JPEG and PNG files. Converting them all to AVIF or WebP is a batch operation that online tools handle poorly — they impose file size limits, require uploads, and process files one at a time or in small batches.
A local tool like TinyPixels converts your entire image library to AVIF or WebP on your machine, using all available CPU cores simultaneously. On Apple Silicon, converting thousands of images takes minutes rather than hours. No upload, no queue, no per-file limits.
The 2026 recommendation, summarised
Serve AVIF as your primary web format for all photographic content, with a WebP fallback via <picture>. Use WebP lossless or PNG for logos and UI elements. Use SVG where possible for icons. Retire JPEG as a primary format — keep it only as a last-resort fallback.
The technical barrier to adopting AVIF is now low. The performance and cost benefits are significant. The question in 2026 is no longer whether to switch — it's how quickly you can convert your existing library.