- WebP und AVIF sind moderne Bildformate, die JPEG und PNG in den meisten Fällen ersetzen sollten. AVIF spart bei vergleichbarer Qualität typischerweise rund 50 Prozent Dateigröße gegenüber JPEG, WebP rund 25 bis 34 Prozent.
- Beide Formate sind 2026 in allen relevanten Browsern verfügbar. Die Frage ist nicht mehr ob, sondern wie man sie richtig einsetzt.
- Das
<picture>-Element mit AVIF als erstersource, WebP als Rückfallebene und JPEG als Fallback funktioniert in jedem Browser korrekt. - WordPress-Plugins wie Imagify oder ShortPixel übernehmen die Konvertierung automatisch beim Upload. Manueller Eingriff ist nicht nötig.
Wer heute eine neue Website baut oder einen Onlineshop überarbeitet, stößt früh auf die Frage nach den richtigen Bildformaten. JPEG und PNG haben über zwanzig Jahre lang gut funktioniert, aber sie sind für heutige Verbindungsrealitäten nicht mehr optimal. WebP und AVIF komprimieren deutlich besser, sind in allen aktuellen Browsern verfügbar und lassen sich ohne sichtbaren Qualitätsverlust einsetzen. Dieser Artikel beschreibt, was die Formate technisch unterscheidet, welches wann sinnvoll ist und wie der Einsatz in WordPress konkret aussieht. Den allgemeinen Überblick über Bildoptimierung für das Web behandelt ein eigener Ratgeber.
Was WebP und AVIF sind
JPEG wurde 1992 standardisiert. Es komprimiert Fotos gut, hat aber keine Transparenz und arbeitet mit einem Algorithmus, der bei niedrigen Qualitätsstufen deutliche Artefakte erzeugt. PNG entstand als Patent-freie Alternative zu GIF und speichert verlustfrei, aber mit deutlich größeren Dateien als JPEG bei Fotos.
WebP wurde entwickelt, um beides besser zu machen: bessere Komprimierung als JPEG bei Fotos, bessere Komprimierung als PNG bei Grafiken mit Transparenz, und Animationen als GIF-Ersatz. Technisch basiert es auf dem Intra-Frame-Kompressionsverfahren aus VP8. Google dokumentiert, dass verlustbehaftete WebP-Bilder bei vergleichbarer Wahrnehmungsqualität 25 bis 34 Prozent kleiner sind als JPEG, verlustfreie WebP-Dateien rund 26 Prozent kleiner als PNG.
AVIF geht weiter. Das Format basiert auf AV1, einem Videocodec, der speziell für effiziente Komprimierung bei hoher Qualität entwickelt wurde. Laut MDN Web Docs sind verlustbehaftete AVIF-Bilder typischerweise rund 50 Prozent kleiner als das JPEG-Äquivalent. AVIF unterstützt zusätzlich HDR, breite Farbräume (Wide Color Gamut) und Alpha-Kanal. Was es nicht kann: Progressive Rendering, also das schrittweise Laden eines Bildes von grob nach scharf. Das spielt in der Praxis bei kleinen bis mittleren Bildgrößen kaum eine Rolle, da AVIF-Dateien so viel kleiner sind, dass sie trotzdem schneller vollständig geladen werden.
Kompression im Vergleich zu JPEG und PNG
Die Zahlenbasis kommt direkt aus den Spezifikationen und Messreihen der Formatentwickler. Google gibt für WebP gegenüber JPEG 25 bis 34 Prozent Einsparung bei verlustbehafteter Komprimierung an, für verlustfreies WebP gegenüber PNG etwa 26 Prozent. Diese Werte beziehen sich auf vergleichbare visuelle Qualität, nicht auf unkomprimierte Originale.
Für AVIF nennt web.dev Einsparungen von über 50 Prozent gegenüber JPEG. MDN zitiert einen Vergleich, nach dem AVIF im Median 50 Prozent komprimiert, WebP 30 Prozent, bei gleichem JPEG-Ausgangsset. In der Praxis variiert das stark nach Bildinhalt: Fotos mit vielen Farbübergängen profitieren mehr als Grafiken mit harten Kanten.
Ein konkretes Beispiel verdeutlicht die Auswirkung auf die Ladezeit. Ein typisches Produktfoto in einem WooCommerce-Shop, 1200 x 900 Pixel, wog in einem unserer Projekte als JPEG rund 280 Kilobyte. Als WebP mit Qualitätsstufe 80 waren es 190 Kilobyte, als AVIF mit Qualitätsstufe 70 noch 130 Kilobyte. Das ist keine theoretische Übung, sondern die Differenz, die Google Lighthouse in den PageSpeed Insights sieht und bei der LCP-Bewertung einrechnet. Mehr dazu im Ratgeber zum Largest Contentful Paint verbessern.
Browser-Unterstützung 2026
WebP wird von Chrome, Edge, Firefox, Safari und Opera unterstützt. Der einzige nennenswerte Außenseiter war der Internet Explorer 11, der jedoch offiziell seit Juni 2022 von Microsoft abgekündigt ist und dessen Marktanteil in Deutschland unter 0,5 Prozent liegt. Für jede professionelle Website ist WebP heute ohne Einschränkung einsetzbar.
AVIF ist etwas jünger im Browser-Ökosystem. Chrome unterstützt das Format seit Version 85 (August 2020), Firefox seit Version 93 (Oktober 2021), Safari seit Version 16.4 (März 2023, iOS 16.4), Edge seit Version 121. Laut Can I use liegt die globale Browser-Abdeckung für AVIF damit bei über 95 Prozent. Für die Nutzerschaft einer typischen deutschen Unternehmenswebsite oder eines Onlineshops ist das ausreichend für den produktiven Einsatz, solange ein Fallback vorhanden ist.
WebP hat laut Can I use (WebP) eine noch breitere Abdeckung und kann daher als sichere Rückfallebene zwischen AVIF und JPEG dienen. Wer sich die Arbeit macht, alle drei Formate anzubieten, bekommt für praktisch jeden Besucher das jeweils kleinste Format. Wie das im HTML-Markup konkret aussieht, zeigt der nächste Abschnitt.
AVIF oder WebP: wann welches Format passt
Eine pauschale Antwort gibt es nicht, aber eine klare Empfehlung: Wer neu anfängt, sollte AVIF als Primärformat und WebP als Rückfallebene nutzen. Das ist der Stand der Technik 2026 und spiegelt sich auch in den Empfehlungen von Google Lighthouse wider.
AVIF ist bei Fotos mit vielen Farbverläufen und natürlichen Texturen im Vorteil. Bei grafischen Elementen mit harten Kanten und wenigen Farben, etwa Logos oder Illustrationen, fällt der Vorsprung geringer aus, ist aber in der Regel immer noch vorhanden. AVIF ist außerdem die bessere Wahl bei Bildern mit Transparenz, weil es den Alpha-Kanal effizienter kodiert als WebP.
WebP hat einen praktischen Vorteil: Die Encoding-Geschwindigkeit ist deutlich höher als bei AVIF. Das spielt eine Rolle, wenn Bilder in Echtzeit oder bei sehr großen Mengen konvertiert werden müssen. Bei normalem WordPress-Betrieb, wo Bilder einmalig beim Upload verarbeitet werden, ist das kein Argument gegen AVIF. Nur bei Systemen mit sehr hohem Upload-Volumen und knapper Serverkapazität kann WebP als Primärformat sinnvoll sein.
Im Zusammenhang mit Core Web Vitals ist besonders der Largest Contentful Paint relevant. Das erste große sichtbare Bild im Viewport sollte so klein wie möglich sein, ohne Qualitätsverlust zu zeigen. AVIF ist dafür die bessere Wahl, weil es die höchste Komprimierung bei niedrigster Artefaktdichte bietet.
Das picture-Element mit Fallback
Das HTML-<picture>-Element ermöglicht es, mehrere Bildquellen in Prioritätsreihenfolge anzugeben. Der Browser lädt die erste <source>, deren Format er unterstützt, und greift auf das <img>-Tag als Fallback zurück. Das funktioniert ohne JavaScript und ohne serverseitige Logik.
<picture>
<source srcset="produkt.avif" type="image/avif">
<source srcset="produkt.webp" type="image/webp">
<img src="produkt.jpg" alt="Winterjacke in Marineblau, Vorderansicht" width="1200" height="900" loading="lazy">
</picture>Ein Browser, der AVIF versteht, lädt produkt.avif und ignoriert die anderen Quellen. Ein Browser ohne AVIF-Unterstützung, aber mit WebP-Unterstützung, nimmt produkt.webp. Alle anderen fallen auf das JPEG zurück. Das alt-Attribut am <img>-Tag gilt für alle drei Varianten, Screenreader lesen es in jedem Fall.
Wichtig: width und height am <img>-Tag angeben. Ohne diese Angaben berechnet der Browser das Seitenverhältnis erst nach dem Laden, was zu Layoutverschiebungen führt und den Cumulative Layout Shift verschlechtert, einen weiteren Core Web Vital. Das loading="lazy"-Attribut gehört auf alle Bilder, die nicht im ersten sichtbaren Bereich liegen. Für das erste große Bild, das für den LCP relevant ist, verwendet man stattdessen fetchpriority="high". Mehr dazu im Ratgeber zu Lazy Loading richtig einsetzen.
Wer responsive Bilder für verschiedene Bildschirmbreiten anbieten möchte, kombiniert srcset mit sizes:
<picture>
<source srcset="produkt-480.avif 480w, produkt-960.avif 960w, produkt-1200.avif 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
type="image/avif">
<source srcset="produkt-480.webp 480w, produkt-960.webp 960w, produkt-1200.webp 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
type="image/webp">
<img src="produkt-960.jpg"
srcset="produkt-480.jpg 480w, produkt-960.jpg 960w, produkt-1200.jpg 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="Winterjacke in Marineblau, Vorderansicht"
width="960" height="720" loading="lazy">
</picture>Dieses Markup wirkt auf den ersten Blick aufwendig, ist aber exakt das, was WordPress ab Version 5.5 automatisch generiert, wenn die Bilder korrekt hochgeladen wurden. Wer ein Plugin für moderne Formate nutzt, bekommt die zusätzlichen <source>-Tags ebenfalls automatisch.
WebP und AVIF in WordPress nutzen
Seit WordPress 5.8 können WebP-Bilder direkt in die Mediathek hochgeladen werden. Die automatische WebP-Generierung aus JPEG-Uploads war für WordPress 6.1 entwickelt, wurde aber kurz vor dem Release zurückgezogen und nie in den Core aufgenommen. Sie ist nur über das offizielle Performance-Lab-Plugin (Modern Image Formats) verfügbar, nicht nativ im Core. Das gilt für neu hochgeladene Bilder, nicht rückwirkend für den Bestand.
AVIF-Generierung ist in WordPress selbst noch nicht eingebaut. Dafür sind Plugins nötig. Die gängigen Optionen:
- Imagify konvertiert beim Upload zu WebP und AVIF, speichert alle Versionen und liefert über einen integrierten CDN automatisch das kleinste unterstützte Format aus. Der kostenlose Plan umfasst 25 MB pro Monat, danach kostenpflichtig.
- ShortPixel funktioniert ähnlich, bietet aber ein anderes Preismodell mit Credits statt monatlichem Volumen. Gut geeignet für Projekte mit wenigen, aber großen Bildmengen.
- EWWW Image Optimizer kann auf lokale Konvertierungsbibliotheken zugreifen und kommt mit einem großzügigeren kostenlosen Bereich, erfordert aber mehr technisches Verständnis bei der Einrichtung.
Alle drei Plugins nutzen das bereits beschriebene <picture>-Element mit Fallback und benötigen keine manuellen Eingriffe ins Theme. Wer einen neuen WooCommerce-Shop aufbaut und von Anfang an moderne Formate einsetzen möchte, sollte das Plugin schon vor dem Hochladen der Produktbilder aktivieren, damit keine JPEG-Kopien ohne moderne Gegenstücke in der Mediathek landen.
Für statische Websites und andere CMS-Systeme wie Shopware oder Contao übernimmt in der Regel der Hosting-Stack oder ein CDN die Formatwahl. Cloudflare Polish beispielsweise konvertiert Bilder automatisch zu WebP, wenn der anfragende Browser das Format unterstützt. AVIF ist in Cloudflare Polish allerdings nicht enthalten; dafür ist Cloudflare Images erforderlich. Das ist ein separater Dienst mit eigenem Preismodell.
Wer prüfen möchte, ob seine bestehende Website davon profitieren würde, sieht das direkt in den PageSpeed Insights unter dem Punkt „Bilder in modernen Formaten bereitstellen“. Die häufigsten Ursachen für langsame Websites beschreibt ein eigener Ratgeber.
Praxisbeispiel aus einem Onlineshop-Projekt
In einem WooCommerce-Projekt für einen mittelständischen Modehändler hatten wir rund 1.400 Produktbilder im Bestand, alle als JPEG mit Qualität 80 gespeichert. Die durchschnittliche Produktseite lud drei bis vier Bilder, das größte davon war der LCP-Kandidat. Google Lighthouse meldete für mobile Geräte einen LCP von 3,8 Sekunden, was im gelb-orangefarbenen Bereich „verbesserungswürdig“ liegt (knapp unter dem roten Bereich, der erst ab 4,0 Sekunden beginnt).
Nach dem Einrichten von Imagify und der Bulk-Konvertierung des gesamten Bildbestands zu AVIF und WebP sank das Gesamt-Bildvolumen einer typischen Produktseite von 780 Kilobyte auf 320 Kilobyte. Der LCP verbesserte sich auf 2,1 Sekunden auf mobilen Verbindungen, was im grünen Bereich liegt. Das war die einzige Maßnahme in diesem Schritt, keine Code-Änderungen, kein CDN-Wechsel.
Ein Detail war dabei entscheidend: Das erste Produktbild, das für den LCP relevant ist, bekam fetchpriority="high" und kein loading="lazy". Lazy Loading am falschen Bild hätte die LCP-Verbesserung teilweise wieder aufgezehrt, weil der Browser das Bild zu spät angefordert hätte. Das war eine manuelle Anpassung im Theme, die das Plugin nicht automatisch übernimmt.
Formatvergleich auf einen Blick
| Format | Einsparung vs. JPEG | Browser-Unterstützung 2026 | Wann einsetzen |
|---|---|---|---|
| JPEG | Referenzformat | Universal | Nur noch als Fallback |
| PNG | Schlechter bei Fotos | Universal | Nur bei verlustfreier Grafik ohne Alternativen |
| WebP | 25 bis 34 % | Alle modernen Browser, ca. 97 % | Rückfallebene zwischen AVIF und JPEG; Primärformat wenn AVIF-Encoding zu langsam |
| AVIF | ca. 50 % | Chrome 85+, Firefox 93+, Safari 16.4+, Edge 121+, ca. 95 % | Primärformat für Fotos und transparente Bilder; erste Wahl für LCP-Bilder |
Sofort-Checkliste
- WebP- und AVIF-Plugin in WordPress aktiviert und konfiguriert (Imagify, ShortPixel oder EWWW)?
- Bestehende JPEG-Bilder in der Mediathek nachträglich konvertiert (Bulk-Konvertierung im Plugin)?
- Das picture-Element mit AVIF, WebP und JPEG als Fallback im Theme-Template vorhanden?
- width und height am img-Tag für alle Bilder gesetzt (verhindert Cumulative Layout Shift)?
- Das erste große Bild im Viewport mit fetchpriority=“high“ ausgezeichnet, kein loading=“lazy“?
- Alle anderen Bilder unterhalb des sichtbaren Bereichs mit loading=“lazy“?
- Google PageSpeed Insights zeigt keinen Hinweis mehr auf „Bilder in modernen Formaten bereitstellen“?
- Alt-Texte an allen Bildern vorhanden und beschreibend (nicht „bild.jpg“)?
- AVIF ist 2026 das empfohlene Primärformat für Fotos. Es spart rund 50 Prozent gegenüber JPEG bei vergleichbarer Qualität.
- WebP bleibt als Rückfallebene sinnvoll, da es eine noch breitere Browser-Abdeckung hat als AVIF.
- Das picture-Element im HTML erledigt die Format-Auswahl automatisch, ohne JavaScript und ohne Server-Logik.
- WordPress-Plugins konvertieren und liefern moderne Formate automatisch aus. Das Heldbild braucht fetchpriority=“high“, kein lazy loading.
Häufige Fragen
Muss ich alle JPEG-Bilder ersetzen oder können beide Formate parallel existieren?
Beides gleichzeitig ist der richtige Weg. Das picture-Element liefert AVIF und WebP an unterstützte Browser, das JPEG bleibt als Fallback für ältere Browser erhalten. Es müssen keine JPEG-Dateien gelöscht werden, das Plugin legt einfach zusätzliche Versionen an.
Erkennt Google AVIF beim Crawlen und Indexieren von Bildern?
Ja. Der Googlebot unterstützt WebP seit 2014 und AVIF seit mehreren Jahren. Das Bildformat hat keinen negativen Einfluss auf die Bildindexierung. Alt-Text, Dateiname und strukturierte Daten bleiben die entscheidenden Faktoren für die Bildsuche.
Lohnt sich der Umstieg auch bei einer kleinen Unternehmenswebsite mit wenigen Bildern?
Ja, gerade wenn eines der Bilder das erste große Element im sichtbaren Bereich ist. Dieses einzelne Bild bestimmt den LCP. Eine Verkleinerung von 300 auf 140 Kilobyte kann je nach Verbindung 0,3 bis 0,8 Sekunden Ladezeit bedeuten, und das zeigt sich direkt in PageSpeed Insights.
AVIF-Encoding dauert länger als JPEG. Ist das im laufenden Betrieb ein Problem?
Nein, solange die Konvertierung beim Upload stattfindet. Im Betrieb wird nur die fertige Datei ausgeliefert, was genauso schnell ist wie bei JPEG. Bei sehr hohem Upload-Volumen lohnt sich eine asynchrone Verarbeitung via Job-Queue, die die gängigen Plugins ohnehin anbieten.
Kann ich AVIF auch für Bilder mit transparentem Hintergrund verwenden, also als PNG-Ersatz?
Ja. AVIF unterstützt einen Alpha-Kanal und kodiert Transparenz effizienter als PNG. Bei Produktfotos mit freigestelltem Hintergrund ist AVIF daher sowohl gegenüber PNG als auch gegenüber WebP die bessere Wahl.
Was ist der Unterschied zwischen AVIF und HEIF?
HEIF ist ein Containerformat, das ursprünglich für HEVC-kodierte Bilder entwickelt wurde und von Apple in iOS und macOS verbreitet ist. AVIF verwendet denselben HEIF-Container, aber mit dem AV1-Codec statt HEVC. AV1 ist lizenzfrei, HEVC nicht. Für das Web ist AVIF die richtige Wahl, weil es von allen relevanten Browsern unterstützt wird, HEIF/HEVC dagegen nicht.