blog/bildformate-avif-webp-dfm
BLOG · ARTIKEL
Engineering 20. August 2026KI-generiert~3 Min Lesezeit

Bildformate AVIF und WebP im Vergleich

AVIF halbiert die Dateigröße gegenüber JPEG, WebP spart rund ein Drittel. Die Wahl hängt von Kodierzeit, Browserbasis und der Fallback-Kette ab.

/images/engineering/bildformate-avif-webp.webp

AVIF ist das kleinere Format, WebP das breiter unterstützte. Gegenüber einem JPEG gleicher Qualität spart AVIF in eigenen Messungen 40 bis 60 Prozent Dateigröße, WebP rund 25 bis 35 Prozent. Für die meisten Projekte heißt das: AVIF ausliefern, WebP als Rückfall, das Original nur als letzte Linie.

AVIF oder WebP – wo liegt der Unterschied?

Beide komprimieren moderner als JPEG, aber mit unterschiedlichem Aufwand. WebP ist seit 2010 in Chrome präsent und seit 2020 in Safari; AVIF stützt sich auf den AV1-Codec und braucht beim Kodieren spürbar länger. Der Unterschied zeigt sich weniger in der Bildqualität als in der Frage, ob Ihre Build-Pipeline die zusätzlichen Sekunden pro Motiv verkraftet.

Wie viel kleiner werden die Dateien wirklich?

Bei einem Produktfoto mit 1.600 Pixeln Breite blieben von 148 Kilobyte JPEG noch 61 Kilobyte AVIF und 94 Kilobyte WebP – bei gleicher wahrgenommener Qualität. Der Gewinn wächst mit dem Motiv: Bei Fotos mit feinen Texturen liegt AVIF deutlicher vorn, bei flächigen Grafiken mit harten Kanten schrumpft der Vorsprung auf wenige Prozent.

Wann lohnt sich AVIF trotz längerer Kodierzeit?

Immer dann, wenn ein Bild oft ausgeliefert und selten neu gebaut wird. Einmal kodiert, zahlt sich die kleinere Datei bei jedem einzelnen Aufruf aus. Bei einem Katalog mit 4.000 Produktbildern und 300.000 Aufrufen im Monat sind 80 Kilobyte Ersparnis pro Bild schnell mehrere hundert Gigabyte Übertragung im Jahr. Täglich neu erzeugte Motive kosten die Kodierzeit dagegen jeden Tag erneut.

Wie liefert man beide Formate sauber aus?

Mit dem picture-Element und einer festen Reihenfolge: AVIF zuerst, WebP als zweite Quelle, JPEG als Rückfall im img-Tag. Wichtig ist, dass jede Quelle dieselben Maße und dasselbe Seitenverhältnis deklariert – sonst springt das Layout, wenn der Browser die erste Wahl verwirft. Ein falsch gesetztes type-Attribut führt dazu, dass ein Browser ein Format lädt, das er nicht dekodieren kann.

Warum reicht das Format allein nicht?

Weil die größte Datei die ist, die zu groß ausgeliefert wird. Ein 2.400 Pixel breites AVIF auf einem 390 Pixel breiten Telefon bleibt Verschwendung, auch wenn es kleiner ist als das entsprechende JPEG. Erst srcset mit mehreren Breiten und sizes mit der echten Layoutbreite machen aus dem Formatvorteil einen messbaren Ladezeitgewinn.

Was kostet die Umstellung?

Meist einen Nachmittag. Die Pipeline muss ein zweites und drittes Ausgabeformat erzeugen, die Templates brauchen das picture-Element, und der Cache darf alte Varianten nicht ewig behalten. Der Aufwand lohnt sich dort, wo Bilder den Großteil der übertragenen Bytes ausmachen; bei textlastigen Seiten ist der Effekt kleiner als der Aufwand.

Welche Qualitätsstufe ist richtig?

Die Stufe entscheidet mehr über die Dateigröße als das Format selbst. Bei AVIF liegt der brauchbare Bereich zwischen 50 und 63, bei WebP zwischen 75 und 82, jeweils auf einer Skala bis 100. Höhere Werte bringen kaum sichtbaren Gewinn, kosten aber zweistellige Prozentpunkte an Größe. Prüfen Sie die Stufe an einem kontrastreichen Motiv, nicht an einem gleichmäßig grauen Hintergrund.

Das Format ist die halbe Miete

Das richtige Format halbiert die Bildlast, ersetzt aber keine Disziplin bei den Maßen. Wer AVIF einführt und weiterhin ein 2.400 Pixel breites Bild an jedes Gerät schickt, verschenkt den halben Effekt. Prüfen Sie nach der Umstellung die tatsächlich übertragene Bildmenge pro Seitenaufruf, nicht nur die Dateigröße auf der Platte. Ein Blick in den Netzmitschnitt zeigt in wenigen Minuten, ob die kleineren Dateien auch kleiner ankommen.

/blog/bildformate-avif-webp-dfm
$ echo "Gefallen?" | share --to=you

Wir bauen das für Sie

Vom Artikel zur Implementierung — sprechen Sie mit uns.