WebP vs AVIF in 2026: Was Du für Deine Website verwenden solltest
Ehrlicher 2026-Vergleich: WebP vs AVIF für Web-Performance, Browser-Support, Dateigröße, Encoding-Geschwindigkeit und die praktische Fallback-Kette mit echten Benchmarks.
WebP kam 2010 raus. AVIF kam 2019 raus. Bis 2026 sind beide ausgereift, beide haben ~94%+ globalen Browser-Support, und beide schlagen JPG/PNG bei der Dateigröße. Aber die Wahl zwischen ihnen oder wie man beide nutzt, bringt Entwickler und Content-Manager weiterhin durcheinander. Diese Anleitung gibt Dir echte Benchmarks und eine saubere Entscheidungsregel.
TL;DR, die 2026-Antwort
Für statische Sites und vorgebaute Assets: AVIF zuerst, WebP-Fallback, JPG/PNG zuletzt. Der <picture>-Tag handhabt die Kette automatisch.
<picture>
<source srcset="/img/foto.avif" type="image/avif" />
<source srcset="/img/foto.webp" type="image/webp" />
<img src="/img/foto.jpg" alt="..." />
</picture>Für dynamisches Resizing, Echtzeit-Generierung oder begrenzte CPU-Budgets: nur WebP. AVIF-Encoding ist zu schwer zur Anfragezeit.
Die Entscheidung in einem Satz
Wenn das Bild einmal generiert und für immer ausgeliefert wird, verwende AVIF + WebP-Fallback. Wenn es pro Anfrage generiert wird, verwende nur WebP.
Echte Benchmarks: gleiche Quelle, beide Formate
10 repräsentative Fotos komprimiert bei “visuell verlustfreier” Qualität (SSIM ≥ 0,99 vs Original):
| Quelle (4000×3000 JPG) | JPG q90 | WebP q80 | AVIF q60 | AVIF vs JPG |
|---|---|---|---|---|
| Strandfoto (Verlaufshimmel) | 2,4 MB | 1,3 MB | 0,7 MB | −71% |
| Porträt (Hauttöne) | 1,8 MB | 0,9 MB | 0,55 MB | −69% |
| Produkt auf weißem HG | 1,1 MB | 0,45 MB | 0,28 MB | −75% |
| Stadtbild (hohe Detailfülle) | 3,2 MB | 1,8 MB | 1,1 MB | −66% |
| Food-Fotografie | 2,1 MB | 1,0 MB | 0,62 MB | −70% |
| Landschaft mit Textur | 2,7 MB | 1,6 MB | 1,0 MB | −63% |
| Logo / Illustration | 380 KB | 120 KB | 95 KB | −75% |
| Screenshot (UI) | 540 KB | 210 KB | 165 KB | −69% |
| Mode (hoher Kontrast) | 1,9 MB | 0,95 MB | 0,58 MB | −69% |
| Makro / Naturdetail | 2,5 MB | 1,4 MB | 0,85 MB | −66% |
| Durchschnitt | 1,86 MB | 0,97 MB | 0,61 MB | −70% |
Für ein typisches Bild spart AVIF ~70% gegenüber JPG, ~37% gegenüber WebP. Die Einsparungen sind massiv im Maßstab: 100 Fotos = 130 MB JPG, 60 MB WebP, 36 MB AVIF.
Browser-Support-Realitätscheck
| Browser | WebP | AVIF | Marktanteil (2026) |
|---|---|---|---|
| Chrome (Desktop + Android) | 2014+ | Aug 2020+ | 65% |
| Edge | 2018+ | 2021+ | 5% |
| Firefox | 2019+ | Okt 2021+ | 3% |
| Safari (iOS + macOS) | 2020 (14+) | März 2022 (16+) | 19% |
| Samsung Internet | 2019+ | 2021+ | 3% |
| Opera | 2014+ | 2020+ | 2% |
| Alter IE / IE-Modus | Nie | Nie | <1% |
| Kombinierter Support | ~99% | ~94% | n.z. |
Die 6%-AVIF-Lücke
Die 6% ohne AVIF sind meist: (a) Android < 7 noch in einigen Regionen im Einsatz, (b) alte Unternehmens-Edge/IE-Holdouts, (c) eingebettete WebViews in älteren Apps. Liefere immer einen WebP-Fallback aus, das deckt sie alle ab.
Encoding-Geschwindigkeit: der WebP-Vorteil
AVIF-Kompression ist schwerer, weil der Codec komplexer ist (HEVC-abgeleitet). Bei einer typischen Arbeitslast:
| Operation | WebP (libwebp) | AVIF (libaom) | Unterschied |
|---|---|---|---|
| 4 MP Foto → q80 | 0,8 s | 4,2 s | 5× langsamer |
| 4 MP Foto → q60 | 0,6 s | 3,5 s | 5,8× langsamer |
| 12 MP Foto → q80 | 2,1 s | 12 s | 5,7× langsamer |
| 100 Thumbnails (300×300) | 8 s | 38 s | 4,7× langsamer |
| Komplette Bildbibliothek bauen (1000 Bilder) | 14 min | 1h 12min | 5,1× langsamer |
Für statische Site-Builds ist das okay, einmal kodieren, für immer ausliefern. Für dynamisches Resizing (z.B. Nutzer laden Avatare zur Anfragezeit hoch) sind die 5× Kosten prohibitiv.
Wann WebP wählen
Nur WebP wählen, wenn
- Du Bilder zur Anfragezeit generierst (dynamisches Resizing)
- Build-CPU/Zeit begrenzt ist
- Du einfacheres Tooling willst (breitere Bibliotheksunterstützung)
- Dein CDN AVIF noch nicht unterstützt
- Deine Zielgruppe sehr-altes-Android skewt (Regionen mit alten Geräten)
AVIF + WebP-Fallback wählen, wenn
- Statische Site mit vorgebauten Assets
- Foto-lastige Site (E-Commerce, Portfolio, Nachrichten)
- Bandbreitenkosten zählen (CDN-Rechnungen, Mobil-Nutzer)
- Core Web Vitals kritisch (Bildgewicht ist Engpass)
- Du Build-Time-CPU entbehren kannst
Die Fallback-Kette in der Praxis
Das HTML <picture>-Element ist der Standardweg, mehrere Formate auszuliefern. Der Browser wählt das erste Format, das er versteht.
<picture>
<source type="image/avif" srcset="/img/hero.avif" />
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Hero-Bild" loading="lazy" />
</picture>Moderne Frameworks generieren das automatisch:
| Framework | Wie |
|---|---|
| Astro | <Image src=... formats={['avif', 'webp']} /> |
| Next.js | next/image + images.formats Config |
| Gatsby | gatsby-plugin-image mit formats |
| Vite | vite-imagetools Plugin |
| Nuxt | @nuxt/image mit format-Array |
| Hugo | Page Resources + Resize + Convert |
Liefere AVIF nicht ohne WebP aus
Die 6% Nutzer ohne AVIF-Support sehen kein "kaputtes Bild", sie sehen nichts. Der <picture>-Tag fällt durch zum <img>, wenn alle <source>-Einträge versagen. Schließe immer WebP (oder JPG) als Sicherheitsnetz ein.
Qualitätsregler-Mapping
Die Zahl, die Du in q= für AVIF setzt, mappt nicht zu JPG/WebP. Grobe Äquivalente:
| Visuelle Qualität | JPG q | WebP q | AVIF q |
|---|---|---|---|
| Fast verlustfrei | 95 | 95 | 80 |
| Visuell verlustfrei | 90 | 85 | 65 |
| Scharf bei normalem Betrachten | 85 | 80 | 60 |
| Akzeptabel | 75 | 70 | 50 |
| Sichtbare Kompression | 60 | 55 | 35 |
| Starke Artefakte | 40 | 35 | 20 |
Standard fürs Web: JPG 85, WebP 80, AVIF 60, alle produzieren visuell identische Ausgabe.
Encoding-Tipps für beste Ergebnisse
- Immer aus dem Original kodieren (nicht aus einem JPG → neu kodiertem WebP), sonst summieren sich Verluste.
- Für Fotos q60 AVIF / q80 WebP verwenden, der Sweet Spot.
- Für Grafiken mit scharfen Kanten zu verlustfreiem WebP wechseln oder PNG-Fallback. AVIF verlustbehaftet kann feine Linien verwischen.
- Mit AVIF nicht für Thumbnails unter 100×100 bemühen, der Dateigrößenunterschied ist winzig vs. Encoding-Kosten.
- Metadaten entfernen (EXIF, ICC) wenn möglich, spart weitere 10-30 KB pro Bild.
Was ist mit JPEG XL?
JPEG XL (JXL) ist ein neueres Format, das manche 2022 “AVIF-Killer” nannten. Stand 2026:
- Chrome hat Unterstützung 2023 entfernt (umstrittene Entscheidung).
- Safari unterstützt es (seit iOS 17).
- Firefox: hinter Flag.
Es lohnt sich noch nicht, in der Produktion zu deployen. Die Browser-Support-Story ist zu unsicher. 2027 erneut prüfen.
Zusammenfassung
Für 90% der Websites in 2026:
- Build-Pipeline kodiert jedes Bild zu AVIF + WebP + JPG/PNG.
<picture>-Tag in HTML liefert das richtige basierend auf Browser.- JPG-Qualität 85, WebP 80, AVIF 60 als Standard, visuell identisch.
- AVIF nur für winzige Bilder oder dynamische Generierungspfade überspringen.
- Mit Core Web Vitals vor und nach messen, Bildgewicht sollte ~70% fallen.
Du kannst Deine bestehenden Assets gerade jetzt mit JPG zu WebP, PNG zu WebP konvertieren oder per Stapel über Bild umwandeln verarbeiten. Alles läuft lokal, kein Upload, kein Server.