AVIF vs. WebP vs. JPEG: reale Zahlen bei gleicher Qualität

Die meisten Behauptungen à la „AVIF ist 50% kleiner als JPEG" vergleichen ein JPEG mit Qualität 75 mit einem AVIF bei einer anderen Einstellung. Das ist kein Vergleich – ein -q 75 in einem Encoder ist nicht dasselbe Bild wie ein -q 75 in einem anderen. Die einzige ehrliche Frage lautet: Wie viele Bytes braucht jedes Format bei fester wahrgenommener Qualität?

Wir haben es gemessen. Nicht an einer Handvoll Hero-Bilder, sondern an 1.900+ echten Fotografien, mit den tatsächlichen Encodern, bewertet mit einer wahrnehmungsbasierten Metrik statt einer geschätzten Qualitätszahl.

Wie wir gemessen haben

• Bilder: das Fotoset aus unserem öffentlichen Benchmark – 1.998 echte Fotografien, größtenteils Originale von Wikimedia Commons, mit Porträts, Landschaften, Texturen, Schwachlicht und feinen Details. Kein kuratierter Idealfall.
• Encoder, jeweils das Standardtool: JPEG über libjpeg-turbo, WebP über cwebp (libwebp), AVIF über avifenc (libaom) und als Bonus JPEG XL über cjxl (libjxl).
• Die Metrik: ssimulacra2, ein wahrnehmungsbasierter Qualitätswert, bei dem höher näher am Original bedeutet. Er korreliert weit besser mit dem, was das Auge sieht, als PSNR oder eine bloße Qualitätszahl. 90+ ist nicht vom Original zu unterscheiden; ~85 ist hohe Qualität; ~80 ist gut.
• Die Methode: Für jedes Bild kodieren wir jedes Format über ein vollständiges Qualitätsraster, bewerten jede Ausgabe mit ssimulacra2 und interpolieren dann die Byte-Zahl, die dieses Format braucht, um einen Zielwert zu erreichen. Das ist der faire Vergleich – jedes Format wird an derselben wahrgenommenen Qualität gemessen, und wir lesen den Preis in Bytes ab. Wir berichten den Median über die Bilder, bei denen alle Formate den Zielwert tatsächlich erreichen.

Der letzte Punkt zählt: cwebp -q 80 mit avifenc -q 80 zu vergleichen, ist bedeutungslos. Zu vergleichen, „welches WebP genauso gut aussieht wie das AVIF", ist die eigentliche Aufgabe.

Die Zahlen

Bei ssimulacra2 85 (hohe Qualität, kaum vom Original zu unterscheiden) – bei den 548 Fotos, bei denen alle vier Formate diesen Wert erreichen:

Bei gleicher Qualität ist AVIF 16% kleiner als WebP, und beide schlagen JPEG deutlich.

Bei ssimulacra2 80 (gute Qualität, ein gängiges Ziel im Web) – über 1.884 Fotos:

AVIFs Vorsprung wächst bei 80 (−29% vs JPEG, −21% vs WebP): Es hält Details bei niedrigeren Bitraten, wo JPEG und WebP anfangen zu zerfallen.

Diese Zahlen decken sich mit der unabhängigen Literatur – dass AVIF bei gleicher Qualität etwa 25–30% unter JPEG landet, ist ein gut reproduziertes Ergebnis. Was dieser Durchlauf hinzufügt: Er misst wahrnehmungsbasiert, bei gleicher Qualität, an einem großen und nicht handverlesenen Fotoset.

Die Einschränkungen, klar benannt

• Die JPEG-Baseline ist libjpeg-turbo, das JPEG, das heute fast überall ausgeliefert wird. Moderne JPEG-Encoder (mozjpeg, jpegli) schließen einen Teil der Lücke, bleiben dabei vollständig JPEG-kompatibel – wer nur JPEG ausliefern kann, sollte zuerst zu einem davon wechseln.
• WebP ist in der Praxis qualitätsbegrenzt. Sein verlustbehafteter Encoder stößt an eine Obergrenze: Bei detailreichen Fotos erreicht er ssimulacra2 90 kaum. Das ist eine echte Grenze, keine Einstellungsfrage.
• JPEG XL ist hier am kleinsten, lässt sich aber nicht an Browser ausliefern. Kein großer Browser aktiviert es 2026 standardmäßig. Es ist als technische Obergrenze enthalten, nicht als Empfehlung für den Einsatz.
• AVIF kostet Encodierzeit. avifenc ist deutlich langsamer als cwebp oder cjpeg. Für gespeicherte Assets hinter einem CDN ist das kein Problem, für spontanes Encodieren pro Anfrage schon – genau deshalb cached ein qualitätsgesteuerter Dienst.

Was das in der Praxis bedeutet

Liefere AVIF mit einem Fallback auf WebP und JPEG aus, und ziele auf einen wahrnehmungsbasierten Wert statt eine Qualitätszahl. Ein fester -q-Wert liefert inkonsistente Qualität über Bilder hinweg – manche überkomprimiert und sichtbar schlecht, manche unnötig groß. Erst die Suche nach der Encoder-Qualität pro Bild, um einen ssimulacra2-Zielwert zu treffen, liefert sowohl die kleinsten Bytes als auch eine Qualität, die man tatsächlich versprechen kann.

Genau das macht Patu: Es sucht die Encoder-Qualität pro Bild, um einen wahrnehmungsbasierten Zielwert zu treffen, und liefert AVIF und WebP mit einem JPEG-Fallback hinter einem CDN. Die Zahlen oben sind der Grund, warum der Standard AVIF-first ist.

curl -X POST "https://patu.dev/v1/compress?formats=avif,webp,fallback&target=85" \
  -H "X-Api-Key: $PATU_KEY" \
  --data-binary @photo.jpg -o photo.avif

Man gibt einen Zielwert vor; man bekommt die kleinste Datei bei dieser Qualität, in den Formaten, die ein Browser tatsächlich nutzen kann.

Methode und Daten: das Patu-Benchmark-Testsystem über die Foto-Kategorie; ssimulacra2 über die rust-av-Implementierung; Encoder libjpeg-turbo, libwebp, libaom, libjxl in ihren veröffentlichten Versionen. Die Größen sind der Median über die Fotos, bei denen jedes Format den Zielwert erreicht.