WebP vs. AVIF vs. JPEG: alle drei an 12 Webbildern gemessen

Jeder Artikel zu WebP vs. AVIF sagt, AVIF sei kleiner. Unserer auch, meistens. Wir haben 12 typische Webbilder, von fotorealistischen Szenen über 3D-Renderings bis zu Seiten-Screenshots, als JPEG, WebP und AVIF kodiert, auf dieselbe sichtbare Qualität gebracht und Bytes, Kodierzeit und Dekodierzeit in Chrome gemessen. AVIF war im Median 20 % kleiner als WebP, und JPEG brauchte im Median 37 % mehr Bytes als WebP. Bei den drei körnigsten Bildern brauchte AVIF aber mehr Bytes als WebP, mit den Einstellungen der meisten Tools dauerte das Kodieren 7,6-mal so lange, und auf unserem eigenen Server ist genau dieser Aufwand der Grund, warum diese Website weiter WebP ausliefert.

Dateigröße jedes Bildes bei der Qualität von WebP q85

Jedes Bild 1.600 px breit, kodiert mit sharp 0.35.5 (mozjpeg, libwebp 1.6.0, libaom 3.15.1) am 10. Oktober 2026. JPEG und AVIF wurden auf den SSIM-Wert interpoliert, den WebP bei Qualität 85 erreichte, jede Zeile vergleicht also Dateien, die nach diesem Maß gleich gut aussehen; das q in Klammern ist die Einstellung, die dorthin führt. „Nicht erreicht“: JPEG blieb selbst bei q95 unter dieser Qualität.

Drei Formate in einem Absatz

JPEG ist das Format, das seit Jahrzehnten jeder Browser und jedes Tool liest. WebP ist das Format von Google und basiert auf dem Videocodec VP8. AVIF ist das Bildformat von AV1, dem Videocodec der Alliance for Open Media. Alle drei komprimieren Fotos verlustbehaftet; WebP und AVIF können außerdem verlustfreie Bilder, Transparenz und Animation. Die Frage für eine Website ist, welches Format bei der Qualität, die du veröffentlichen würdest, die kleinste Datei liefert, was es kostet, sie zu erzeugen, und ob jeder Besucher sie sehen kann.

Wie wir gemessen haben

Wir haben 12 Bilder von der Art gewählt, die auf Firmenwebsites landen: zwei fotorealistische Szenen, eine Klinik-Website mit Porträtfoto, sechs 3D-Renderings aus den Illustrationen unserer eigenen Artikel und drei Screenshots von Seiten dieser Website. Jede Quelle war ein verlustfreies PNG, verkleinert auf 1.600 px Breite. Kodiert haben wir mit sharp, der Bildbibliothek hinter Next.js und vielen anderen Tools: JPEG (mozjpeg) mit acht Qualitätsstufen von 50 bis 95, WebP mit denselben acht und AVIF mit elf Stufen von 30 bis 80, sonst mit den Standardeinstellungen von sharp.

Um bei gleicher Qualität zu vergleichen, haben wir SSIM gemessen, einen gängigen Ähnlichkeitswert, zwischen jeder Datei und ihrer Quelle, und für jedes Bild den Wert genommen, den WebP bei Qualität 85 erreicht, der Einstellung dieser Website. Dann haben wir abgelesen, wie viele Bytes JPEG und AVIF für denselben Wert brauchen. Die Kodierzeiten sind echte Laufzeiten auf einem Intel Core i7-6700K. Die Dekodierzeiten haben wir in Chrome 142 mit createImageBitmap gemessen, 12 Runden pro Datei in wechselnder Reihenfolge nach einer Aufwärmrunde. Keine unserer Quellen ist ein Foto direkt aus der Kamera; die fotorealistischen Szenen sind Renderings, deshalb weisen wir die Bildarten getrennt aus.

Dateigröße bei gleicher Qualität

Bei der Qualität, die wir ausliefern, war AVIF im Median 20 % kleiner als WebP, und JPEG war im Median 37 % größer als WebP. Am größten war der Vorsprung von AVIF bei den Screenshots (im Median 30 %) und beim einfachen, sauberen Rendering einer Figur im Krankenhausbett, das auf die Hälfte schrumpfte. Bei den fotorealistischen Szenen waren es 19 bis 33 %. JPEG war überall dort die größte Datei, wo es die Qualität von WebP überhaupt erreichte; bei den Screenshots und den körnigen Renderings gelang das nicht, nicht einmal bei Qualität 95.

Bei niedrigerer Qualität wird der Abstand größer. Gemessen an WebP mit Qualität 75, dem Standardwert von Next.js, war AVIF im Median 27 % kleiner und JPEG 56 % größer. Im Vergleich zu den verlustfreien PNG-Quellen hatten die WebP-Dateien etwa ein Zwölftel der Größe: 2,2 MB gegenüber 26 MB für alle 12 Bilder zusammen.

Wo AVIF verliert: Körnung und feines Rauschen

Bei drei Bildern brauchte AVIF mehr Bytes als WebP, nicht weniger: 17 % mehr bei zweien und 22 % mehr beim dritten. Alle drei sind Renderings mit sichtbarer Filmkörnung, und es sind die drei rauschigsten Bilder im Set, gemessen an einem einfachen Maß für Detail von Pixel zu Pixel: zwischen 24 und 28, gegenüber 2 bis 16 bei den anderen neun. AVIF glättet solches feines Rauschen gern weg, und es zu erhalten kostet Bits. Weil diese drei auch zu den größten Dateien gehören, waren die 12 AVIF-Dateien zusammen 1 % größer als die 12 WebP-Dateien; ohne sie sparte AVIF insgesamt 24 %.

Wenn deine Bilder also körnige Fotos oder Renderings mit gewollter Textur sind, teste sie, bevor du umstellst. Sind es saubere Produktfotos, Illustrationen oder Screenshots, wird AVIF mit ziemlicher Sicherheit kleiner sein.

Kodieren: wo AVIF seinen Preis hat

Mit den Standardeinstellungen von sharp brauchte AVIF im Median 7,6-mal so lange zum Kodieren wie WebP: hier etwa eine Sekunde pro Bild, gegenüber 0,15 Sekunden für WebP und 0,13 für JPEG. Der Faktor lag zwischen 3 und 15, am langsamsten waren die großen, detailreichen Bilder. Next.js kodiert AVIF mit niedrigerem Aufwand, effort 3 statt der 4, die sharp standardmäßig nutzt; bei effort 3 dauerte AVIF 1,8-mal so lange wie WebP, und die Dateien waren bei derselben Qualitätseinstellung im Median 4 % größer.

AVIF kostet beim Kodieren, also hängt es davon ab, wo das passiert. In einem Build-Schritt oder einem CDN, das jedes Bild einmal kodiert und zwischenspeichert, ist eine Sekunde pro Bild nichts. Auf einem Server, der beim ersten Aufruf kodiert, wartet der erste Besucher darauf. Das haben wir auf unserem eigenen Hosting gemessen, bevor wir entschieden haben: Ein Portfolio-Bild mit 24 Megapixeln brauchte als AVIF 40,07 Sekunden, als WebP 2,57 Sekunden, durch denselben Next.js-Optimierer, um 17 % der Bytes zu sparen, und hielt die ganze Zeit einen Prozessorkern beschäftigt. Deshalb liefert diese Website WebP aus.

Dekodieren im Browser: praktisch ein Unentschieden

Das Dekodieren dauerte bei AVIF und WebP etwa gleich lang: AVIF war im Median 3 % langsamer, rund 14 Millisekunden für ein Bild mit 1.600 Pixeln Breite auf einem Desktop, und JPEG war 20 % schneller als WebP. Den Prozessor in Chrome viermal langsamer zu machen, änderte fast nichts, weil Chrome Bilder außerhalb des Hauptthreads dekodiert. Entscheidend ist der Download: Bei den 1,6 Mbit/s, mit denen Lighthouse eine mobile Verbindung simuliert, kam die mediane AVIF-Datei 69 Millisekunden früher an als ihre WebP-Version, die kleinere fotorealistische Szene 128 Millisekunden früher. Das ist der Unterschied, der im Largest Contentful Paint sichtbar wird, wenn das Bild das größte Element der Seite ist.

Browser-Unterstützung 2026

Beide Formate sind für fast jeden Besucher sicher. Can I Use beziffert die weltweite Unterstützung auf 96,74 % für WebP und 95,35 % für AVIF. AVIF funktioniert in Chrome seit Version 85, in Firefox seit 93, in Safari auf dem iPhone seit iOS 16 und in Edge seit 121; Safari auf dem Mac gilt als teilweise, weil es macOS Ventura oder neuer braucht und die Rauschsynthese von AVIF nicht unterstützt. Die wenigen Browser ohne eines der beiden Formate sind der Grund, warum ein Fallback weiterhin sinnvoll ist: ein picture-Element, das zuerst AVIF, dann WebP, dann JPEG anbietet, oder ein Bilddienst, der das Format danach wählt, was der Browser akzeptiert.

Welches Format du einsetzen solltest

Nimm AVIF, wo Bilder einmal und im Voraus kodiert werden, und WebP, wo ein Server sie auf Anfrage kodiert. Eine statische Website, eine Build-Pipeline oder ein Bild-CDN kann sich die Kodierzeit von AVIF leisten und bekommt dafür ein Fünftel kleinere Dateien, mit WebP als Fallback. Ein selbst gehosteter Optimierer auf bescheidener Hardware, wie unserer, ist mit WebP besser bedient, das schon rund ein Viertel kleiner ist als JPEG. JPEG behältst du nur als letzten Fallback. Was immer du wählst: Es zählt weniger, als Bilder in der richtigen Größe auszuliefern. Ein Bild mit 1.600 Pixeln, wo 800 reichen würden, kostet mehr, als jeder Formatwechsel spart.

Bei den Qualitätseinstellungen entsprachen sich in unserem Test WebP 85 ≈ AVIF 67 ≈ JPEG 87 und WebP 75 ≈ AVIF 50 ≈ JPEG 77. Next.js rechnet seine Qualitätseinstellung für AVIF mit dem Faktor 0,625 um, aus 85 wird also 53; nach unserer Messung liegt das deutlich unter seinem WebP bei 85, ein Teil der Ersparnis ist also geringere Qualität. Bilder und Webfonts sind die beiden Teile des Seitengewichts, über die beim Design am direktesten entschieden wird. Wenn jemand mit dir deine Bilder und das restliche Seitengewicht durchgehen soll: Genau das macht unser Paket Ladezeit-Optimierung.

Quellen und Methode

Dateigrößen, Qualitätswerte sowie Kodier- und Dekodierzeiten sind unsere eigenen Messungen vom 10. Oktober 2026, beschrieben im Abschnitt zur Methode oben. Browser-Unterstützung und Encoder-Einstellungen stammen von den Seiten unten.

• Can I use — AVIF image format ↗

  Weltweite Unterstützung 95,35 % (gelesen am 10. Oktober 2026); Chrome 85, Firefox 93, iOS Safari 16, Edge 121; Safari unter macOS teilweise (Ventura oder neuer, keine Rauschsynthese).

• Can I use — WebP image format ↗

  Weltweite Unterstützung 96,74 % (gelesen am 10. Oktober 2026).

• Next.js — Image component: formats ↗

  Standardformate: nur WebP; AVIF muss eingeschaltet werden. Next.js kodiert AVIF mit effort 3 und dem 0,625-Fachen der angeforderten Qualität (Quellcode von Next.js 16.3).

• sharp — Output options ↗

  Hier verwendete Standardeinstellungen: WebP Qualität 80, effort 4; AVIF Qualität 50, effort 4, Chroma 4:4:4.

• Alliance for Open Media — AV1 Image File Format (AVIF) ↗

  Die AVIF-Spezifikation.

• Google for Developers — WebP ↗

  WebP basiert auf dem Videocodec VP8.

• Lighthouse — Network throttling ↗

  Mobile Simulation: 150 ms Latenz, 1,6 Mbit/s Download.

• Wang, Bovik, Sheikh und Simoncelli — Image quality assessment: from error visibility to structural similarity ↗

  Das SSIM-Maß. Wir haben es auf der Helligkeit berechnet, in 8×8-Fenstern alle 4 Pixel.