AVIF vs. WebP vs. JPG: Der Showdown der modernen Bildformate
Warum dieser Vergleich wirklich zählt
Halte Bildformate nicht für eine rein kosmetische Wahl. Das sind sie nicht. Ein einziges schlecht gewähltes Format auf einer viel besuchten Produktseite kann pro Bild 200–400 KB zusätzlich bedeuten. Das summiert sich zu Sekunden zusätzlicher Ladezeit und messbaren Einbrüchen bei der Conversion-Rate. Googles Core Web Vitals strafen langsame LCP-Werte (Largest Contentful Paint) direkt ab, und Bilder sind dabei die üblichen Verdächtigen. Die Wahl zwischen AVIF, WebP und JPG hat echte Konsequenzen für SEO, deine Serverkosten und die Frage, ob Nutzer auf deiner Seite bleiben. JPG dominiert die Fotografie seit Mitte der 90er. Es funktioniert überall, lässt sich schnell kodieren und jeder Entwickler weiß, wie man damit umgeht. Googles WebP kam 2010 als Nachfolger auf den Markt und versprach bessere Kompression bei gleicher Qualität. Der Neuling ist AVIF, standardisiert 2019 von der Alliance for Open Media. Es treibt die Kompression noch weiter, indem es sich Technologie vom AV1-Video-Codec leiht. Das Ziel hier ist nicht, ein Format zum Sieger zu erklären. Das wäre sinnlos. Das Ziel ist, die spezifischen Kompromisse zu verstehen, damit du die richtige Entscheidung für *dein* Projekt treffen kannst, anstatt einfach nur veralteten Ratschlägen aus dem Jahr 2021 zu folgen. Wir werden die Kompression in der Praxis, die Browser-Unterstützung und die versteckten Kosten wie die Kodiergeschwindigkeit analysieren. So bekommst du den nötigen Kontext, um jedes Format effektiv zu nutzen – und zu wissen, wann es Zeit ist zu konvertieren.
Kompression im Vergleich: Die Zahlen hinter dem Hype
Ja, moderne Formate sind dramatisch kleiner als JPG. Dieser Teil des Hypes stimmt. Aber wie viel kleiner, hängt vom Bild, vom Encoder und von der Qualität ab, die du anstrebst. Bei einem typischen Foto ist WebP in der Regel 25–35 % kleiner als ein JPG von vergleichbarer visueller Qualität. AVIF geht sogar noch weiter und ist oft 40–55 % kleiner als das JPG, was etwa 15–25 % kleiner als das WebP ist. Das bedeutet, ein 180 KB großes Produktfoto (JPG, Qualität 85) wird so vielleicht zu einem 120 KB großen WebP oder einem 90 KB großen AVIF. Die Einsparungen sind real. Aber du kannst die Qualitätsstufen nicht einfach zwischen den Formaten vergleichen. Sie sind nicht äquivalent. Ein JPG mit „Qualität 85“ ist nicht dasselbe wie ein WebP mit „Qualität 85“. Wenn du ein JPG in ImageMagick von 85 auf 75 reduzierst, wird zwar die Dateigröße drastisch verringert, aber es entstehen auch blockartige Artefakte in Verläufen und Himmelsdarstellungen. WebP verwendet eine Skala von 0–100, bei der 80 ein guter Ausgangspunkt ist, was ungefähr einem JPG 85 entspricht. AVIF verwendet eine CRF-Skala (Constant Rate Factor), normalerweise von 0–63, bei der niedriger besser ist. Für Web-Fotos ist ein CRF von 30–40 oft der ideale Wert. Die Sache ändert sich bei Grafiken wie UI-Screenshots, Logos oder Infografiken. PNG war hier bisher wegen seiner verlustfreien Qualität der Standard, aber der verlustfreie Modus von WebP erzeugt durchweg 20–30 % kleinere Dateien. Der verlustfreie Modus von AVIF ist weniger ausgereift und kann für diese Art von Inhalten manchmal sogar *größere* Dateien als verlustfreies WebP erzeugen. Geh also nicht davon aus, dass AVIF immer gewinnt. Das Squoosh-Team von Google hat Tests durchgeführt, die die generelle Überlegenheit von AVIF bei der Kompression bestätigen. Sie fanden aber auch heraus, dass der Vorteil schrumpft, wenn man mit bereits stark komprimierten Quellbildern arbeitet. Wenn du einen Haufen alter JPGs neu konvertierst, anstatt von hochwertigen Originalen auszugehen, wirst du abnehmende Erträge sehen. Müll rein, etwas kleinerer Müll raus.
Browser- und Plattform-Unterstützung: Wo es kompliziert wird
Um es klar zu sagen: Die Unterstützung für JPG ist universell. Jeder Browser, jedes Betriebssystem, jeder Bildbetrachter, jedes CMS, jedes CDN und jeder E-Mail-Client kann einfach damit umgehen. Unterschätze diesen Vorteil nicht; das ist ein Grad an Allgegenwart, den neuere Formate einfach noch nicht erreichen können. Für die Web-Nutzung ist die WebP-Unterstützung mittlerweile hervorragend. Seit 2024 ist jeder große Browser – Chrome, Firefox, Safari (seit Version 14), Edge, Opera – an Bord. Die weltweite Unterstützung liegt laut caniuse.com bei über 97 %. Die einzigen wirklichen Ausnahmen sind uralte Safari-Versionen auf iOS 13 und älter, was für deine Zielgruppe möglicherweise kein Problem darstellt. Die AVIF-Unterstützung ist gut, aber du musst vorsichtiger sein. Chrome ist seit Version 85 (2020) dabei, Firefox seit 93 (2021) und Safari kam schließlich mit Version 16 (2022) dazu. Das deckt die meisten Nutzer ab, aber du kannst immer noch auf Probleme mit Edge auf älteren Windows-10-Builds oder bestimmten Android-WebViews stoßen. Die weltweite Unterstützung bewegt sich um 93-95 %. Das klingt großartig, aber für eine stark frequentierte Website sind die 5-7 % der Nutzer, die ein kaputtes Bild sehen, ein sehr reales Problem. Außerhalb des Browsers wird es kompliziert. Bei Desktop-Apps, mobilen Apps oder E-Mails ist die Unterstützung ein Flickenteppich. macOS unterstützt AVIF seit Ventura (13.0). Windows 11 unterstützt es, aber Windows 10 benötigt einen Codec aus dem Microsoft Store. Android bietet Unterstützung seit Version 12 und iOS seit Version 16. Das ist alles irrelevant, wenn du das HTML-`<picture>`-Element mit den richtigen Fallbacks verwendest. Es wird aber zu einem großen Problem, wenn du erwartest, dass Nutzer diese Dateien selbst herunterladen und öffnen. Die einzig vernünftige Strategie für eine produktive Website ist es, Bilder in einer Kaskade auszuliefern: zuerst AVIF, dann WebP als Fallback und schließlich JPG für alles andere. Du kannst dies mit den `source`-Tags des `<picture>`-Elements und `type`-Attributen umsetzen oder indem du den `Accept`-Header auf deinem Server prüfst. Liefere nicht einfach nur AVIF aus und hoffe das Beste.
Kodiergeschwindigkeit und Tools: Die versteckten Kosten
Die unglaubliche Kompression von AVIF hat einen versteckten Preis: Zeit. Die AVIF-Kodierung ist brutal langsam im Vergleich zu JPG oder WebP, und das hat reale Konsequenzen für deinen Workflow. Schauen wir uns die Zahlen an. Die Kodierung eines 2000×1500-Fotos in JPG (Qualität 85, libjpeg-turbo) kann auf einem modernen Rechner 50-80 Millisekunden dauern. Dasselbe Bild in WebP (Qualität 80, libwebp) dauert 200-400 Millisekunden. Aber die Kodierung in AVIF (CRF 32, Geschwindigkeit 6) kann zwischen 2 und 8 *Sekunden* dauern. Und wenn du den Encoder auf die langsamste, qualitativ hochwertigste Einstellung stellst, könntest du 30 Sekunden oder mehr auf ein einziges Bild warten. Bei einem Stapel von 500 Produktbildern ist das der Unterschied zwischen einer 5-minütigen Kaffeepause und 4 Stunden Wartezeit. Wenn du Bilder on-the-fly generierst, wie es einige CDNs tun, kann dieser Kodierungs-Overhead eine inakzeptable Latenz verursachen, es sei denn, dein Caching ist perfekt. Der libavif-Encoder hat eine Geschwindigkeitseinstellung von 0 (am langsamsten, beste Kompression) bis 10 (am schnellsten, schlechteste). Geschwindigkeit 6 ist die Standardempfehlung, ein guter Kompromiss zwischen Dateigröße und deiner eigenen Geduld. Geschwindigkeit 10 ist fast so schnell wie WebP, aber du opferst einen Großteil des Kompressionsvorteils von AVIF. CocoConvert nimmt dir diese Komplexität auf dem Server ab, aber die physikalischen Gesetze gelten weiterhin: Große Stapel von AVIF-Konvertierungen werden deutlich länger dauern als WebP- oder JPG-Aufträge. Wenn du es eilig hast, ist WebP oft die praktischere Wahl, auch wenn AVIF noch ein paar Kilobytes mehr einsparen könnte. Die Tools für WebP sind ausgereift und stabil; cwebp, Squoosh, ImageMagick und die Node.js-Bibliothek Sharp haben alle eine robuste Unterstützung. Die AVIF-Tools holen auf – Sharp fügte die Unterstützung in v0.27.0 hinzu und ImageMagick verwendet libheif –, aber jeder, der schon einmal mit Abhängigkeitsproblemen bei Bibliotheken gekämpft hat, weiß, dass „aufholen“ bedeuten kann, auf seltsame Bugs und Versionskonflikte zu stoßen, die in der Welt von JPG und WebP einfach nicht existieren.
Bildqualität bei niedrigen Bitraten: Wo die Formate am meisten auseinandergehen
Bei hohen Qualitätseinstellungen sehen die meisten komprimierten Bilder gut aus. Der wahre Test kommt bei niedrigen Bitraten, wenn du aggressiv jedes letzte Byte aus einer Datei herausquetschst. Hier zeigen die Formate ihr wahres Gesicht, und die Unterschiede sind offensichtlich. Starke JPG-Kompression ist berüchtigt für ihre blockartigen Artefakte. Bei einer Qualität von 40-50 zerbrechen sanfte Verläufe in einem blauen Himmel in einen Flickenteppich aus Quadraten. Text bekommt einen unscharfen, klingelnden Heiligenschein. Wir haben sie alle schon gesehen, und sie sind hässlich. WebP neigt bei derselben niedrigen Dateigröße dazu, eher zu verwischen als Blöcke zu bilden. Es glättet feine Details weg. Das kann bei Porträts ein angenehmeres Artefakt sein, wo die Unschärfe natürlicher aussieht als die harten Blöcke von JPG. Bei Bildern mit scharfen Linien oder Text kann dieselbe Unschärfe jedoch ein großer Nachteil sein. Hier glänzt AVIF wirklich. Bei niedrigen Bitraten deklassiert es die beiden anderen. Seine AV1-basierte Kodierung ist einfach besser darin, Details zu erhalten und Verläufe elegant zu behandeln. Ein AVIF-Bild mit 50 KB sieht einfach sauberer aus als ein WebP oder JPG derselben Größe. Der wahre Vorteil von AVIF liegt nicht bei Qualität 90, wo alles in Ordnung ist, sondern bei Qualität 50-60, wo du an die Grenzen gehst. Die wahrnehmungsbasierten Metriken bestätigen dies. Eine auf 50 KB komprimierte Landschaft von 1200×800 könnte einen DSSIM-Wert von 0.008 für JPG, 0.005 für WebP und 0.003 für AVIF erreichen (niedriger ist besser). Das sind nicht nur Zahlen; sie repräsentieren sichtbare Verbesserungen. Wenn du ein striktes Budget für die Dateigröße hast, wird AVIF dir durchweg das bestaussehende Bild liefern. Es gibt eine Ausnahme: feines Filmkorn oder natürliche Texturen. Der Encoder von AVIF kann beim Glätten dieser Details übereifrig sein, was bei einigen Fotos mit hohem ISO-Wert zu einem leicht künstlichen, plastikartigen Look führt. Teste immer mit deinen eigenen Bildern; geh nicht davon aus, dass AVIF eine Wunderwaffe für jede Art von Inhalt ist.
Praktische Anwendungsfälle: Das richtige Format für den richtigen Zweck
Theorie ist schön, aber wo solltest du jedes Format tatsächlich einsetzen? Hier ist ein pragmatischer Leitfaden für gängige Szenarien. **Hero- und Produktfotos für Websites:** Setze auf AVIF, mit Fallback auf WebP, dann JPG. Du kontrollierst die Umgebung, also kannst du das `<picture>`-Element nutzen, um das beste Format auszuliefern. Die Einsparungen bei der Bandbreite sind enorm. Ein Tool wie CocoConvert kann deine JPG-Originale einfach in AVIF und WebP umwandeln, um dies zu erleichtern. **Bilder in E-Mails:** JPG. Punkt. E-Mail-Clients sind eine Wüste inkonsistenter Darstellung. Weder AVIF noch WebP werden in Outlook, Apple Mail oder Gmail zuverlässig unterstützt. Ein WebP zu senden, zeigt einem großen Teil deiner Zielgruppe nur ein kaputtes Bild. **Uploads für Social Media:** Bleib bei hochwertigem JPG. Jede Plattform (Instagram, Twitter/X, Facebook) wird dein Bild sowieso neu kodieren, egal was du hochlädst. Gib ihren Encodern das bestmögliche Ausgangsmaterial; ein vorkomprimiertes AVIF hochzuladen, bringt dir nichts. **Druck oder Archivierung:** Keines von beiden. Nutze ein verlustfreies Format wie TIFF oder PNG für deine Originale. Wenn du eine komprimierte Vorschau senden musst, ist ein hochwertiges JPG (90–95) der universelle Standard, den jede Druckerei oder jeder Redakteur öffnen kann. **Assets für mobile Apps:** Das hängt von deiner Ziel-Betriebssystemversion ab. Wenn du für Android 12+ und iOS 16+ entwickelst, ist AVIF eine gute Wahl. Für eine breitere Unterstützung ist WebP die sicherere Wette, da es bis Android 4.0 und iOS 14 zurückreicht. **Inhalte für CMS:** Sei vorsichtig mit AVIF. Wenn nicht-technische Nutzer Bilder hochladen, willst du den zuverlässigsten Workflow. Viele Mediatheken und Thumbnail-Generatoren in CMS können noch nicht richtig mit AVIF umgehen. JPG und WebP sind weitaus praktischer und verursachen seltener Support-Tickets wegen kaputter Bildvorschauen.
Wie man zwischen diesen Formaten konvertiert (und worauf man achten sollte)
Die Konvertierung zwischen diesen Formaten ist mit den richtigen Tools einfach, aber ein paar Tretminen können deine Stapelverarbeitung ruinieren, wenn du nicht aufpasst. Die goldene Regel der Konvertierung: Beginne immer mit der höchstmöglichen Quellqualität. Ein JPG in ein AVIF zu konvertieren, stellt nicht auf magische Weise die Details wieder her, die die JPG-Kompression bereits zerstört hat. Es verpackt nur die gleichen degradierten Daten in ein neues Format. Wenn du RAW- oder TIFF-Originale hast, nutze sie. Wenn du nur ein JPG hast, wird die Konvertierung in AVIF die Datei zwar kleiner machen, aber das Bild wird dadurch nicht besser aussehen. Ein Tool wie CocoConvert vereinfacht den Prozess: hochladen, Format auswählen und herunterladen. Die Standard-Qualitätseinstellungen für JPG-zu-WebP sind darauf abgestimmt, die visuelle Qualität zu erhalten. Bei JPG-zu-AVIF schaffen die Standardeinstellungen eine Balance zwischen Dateigröße und Qualität, aber du solltest eine höhere Qualität anfordern für Bilder, die groß dargestellt und von Nutzern genau betrachtet werden. Um eine Einschränkung gleich vorwegzunehmen: CocoConvert verarbeitet keine animierten Formate. Ein animiertes WebP in ein animiertes AVIF zu konvertieren, ist eine ganz andere Hausnummer, die Framerate-Timing und Farbpaletten involviert. Dafür musst du ein Kommandozeilen-Tool wie FFmpeg auspacken. Achte auf Transparenz. JPG unterstützt sie nicht, Punkt. Wenn du ein transparentes PNG oder WebP in ein JPG konvertierst, wird der Hintergrund mit einer Volltonfarbe gefüllt, normalerweise weiß oder schwarz. Sowohl AVIF als auch WebP können mit Transparenz (dem Alpha-Kanal) problemlos umgehen, sodass sie bei der Konvertierung zwischen ihnen erhalten bleibt. Stell nur sicher, dass du nicht versehentlich ein transparentes Bild durch einen JPG-Konvertierungsschritt in deiner Pipeline schickst. Zum Schluss eine Dosis Pragmatismus. Bevor du für jedes Bild AVIF- und WebP-Versionen erstellst, frag dich, ob du wirklich beide brauchst. Zwei Formate zu erzeugen, verdoppelt deine Verarbeitungszeit und deinen Speicherbedarf. Für viele Websites ist eine einfache Standardisierung auf WebP bereits eine massive Verbesserung gegenüber JPG und deckt über 97 % der Nutzer mit weitaus weniger Komplexität ab. AVIF ist leistungsstark, aber füge es nur hinzu, wenn deine Serverkosten den zusätzlichen Aufwand wirklich rechtfertigen.