WebP vs. AVIF vs. JPEG: Das richtige Format für Produktbilder wählen

Die Wahl eines Bildformats für Produktfotografie wirkt wie eine kleine technische Entscheidung, bis sie in Seitengeschwindigkeits-Metriken und, weiter unten, in der Conversion-Rate auftaucht. WebP, AVIF, und JPEG treffen jeweils einen anderen Kompromiss zwischen Kompressionseffizienz, Browser-Unterstützung, und Kodierkomplexität, und die richtige Wahl ist nicht für jeden Verkäufer oder jeden Bildtyp dieselbe. Dieser Leitfaden vergleicht die drei Formate speziell für E-Commerce-Produktbilder, mit praktischer Anleitung dazu, wo sich jedes tatsächlich in einer Auslieferungspipeline lohnt.

Die drei Formate im Überblick

• JPEG — das etablierte Format, universell unterstützt, verlustbehaftete Kompression, keine Transparenzunterstützung. Immer noch die sicherste Standardwahl, wenn Kompatibilität wichtiger ist als das letzte Prozent Dateigröße herauszuholen.
• WebP — von Google entwickeltes Format, das bei vergleichbarer visueller Qualität deutlich kleinere Dateien als JPEG bietet, plus Transparenz- und Animationsunterstützung. Inzwischen breite Browser-Unterstützung, was es zu einer praktischen Standardwahl für die meisten E-Commerce-Kataloge macht.
• AVIF — das neueste der drei, basierend auf dem AV1-Videocodec, liefert die kleinsten Dateigrößen der Gruppe bei gegebenem Qualitätslevel, aber mit höheren Kodierkosten und weniger universeller Dekodierunterstützung als WebP.

Kompressionseffizienz: Die tatsächlichen Zahlen

Bei einem visuell vergleichbaren Qualitätslevel für typische Produktfotografie (saubere Hintergründe, moderates Detail) hält sich das allgemeine Muster über die meisten realen Tests hinweg:

• WebP produziert typischerweise Dateien, die 25-35% kleiner sind als ein qualitätsgleiches JPEG.
• AVIF produziert typischerweise Dateien, die weitere 20-30% kleiner sind als WebP bei abgestimmter visueller Qualität — was bedeutet, dass AVIF-Dateien oft bei etwa der Hälfte der Größe eines vergleichbaren JPEGs landen.
• Diese Zahlen variieren erheblich je nach Bildinhalt: Bilder mit großen flachen Farbflächen (eine einfache Weißhintergrund-Produktaufnahme) komprimieren über alle drei Formate hinweg effizienter als Bilder mit feinem, komplexem Detail (Stofftextur, unruhige Muster) — was bedeutet, dass der relative Vorteil von AVIF gegenüber WebP bei einfachen Produktaufnahmen oft kleiner ist, als es die Schlagzeilenzahlen suggerieren.

Die praktische Erkenntnis: Die Dateigrößenlücke zwischen JPEG und WebP ist groß genug, um für nahezu jeden Katalog relevant zu sein. Die Lücke zwischen WebP und AVIF ist real, aber kleiner, und zählt am meisten im großen Maßstab — ein Katalog mit tausenden SKUs sieht ein bedeutend anderes Gesamt-Seitengewicht durch die AVIF-über-WebP-Lücke als ein Katalog mit wenigen Dutzend Produkten.

Browser- und Plattform-Unterstützung

• JPEG — universelle Unterstützung über jeden Browser, jedes Gerät, und jede Plattform hinweg, einschließlich älterer Systeme und E-Mail-Clients, in die Bilder manchmal eingebettet werden.
• WebP — seit mehreren Jahren von allen großen modernen Browsern (Chrome, Firefox, Safari, Edge) unterstützt, was es sicher macht, es als Primärformat für die überwiegende Mehrheit des E-Commerce-Traffics zu verwenden.
• AVIF — Stand 2026 von den meisten großen Browsern unterstützt, aber die Unterstützung hinkte historisch der Adoptionskurve von WebP hinterher, und manche älteren Browser-Versionen, eingebettete WebViews, und spezifische Plattformkontexte (bestimmte Marktplatz-Apps, manche In-App-Browser sozialer Medien) rendern es immer noch nicht zuverlässig.

Diese Unterstützungslücke ist genau der Grund, warum die Standardpraxis eine Fallback-Kette statt der Festlegung auf ein einziges Format ist: AVIF ausliefern, wo unterstützt, zurückfallen auf WebP, zurückfallen auf JPEG für alles, was keines der modernen Formate unterstützt. Das <picture>-Element mit mehreren <source>-Tags handhabt dies nativ im Browser, ohne serverseitige Geräteerkennung zu erfordern.

Kodiergeschwindigkeit und Produktionspipeline-Kosten

Kompressionseffizienz ist nicht kostenlos — sie kostet Kodierzeit, was für Verkäufer zählt, die große Kataloge verarbeiten oder Bilder programmatisch generieren:

• JPEG kodiert am schnellsten der drei, was sein Alter und den vergleichsweise einfachen Kompressionsalgorithmus widerspiegelt.
• WebP-Kodierung ist mäßig langsamer als JPEG, aber schnell genug, dass es selbst im Katalogmaßstab selten zum Produktionsengpass wird.
• AVIF-Kodierung ist deutlich langsamer als beide — für sehr große Kataloge (Zehntausende von SKUs), die regelmäßig verarbeitet werden, kann AVIFs Kodierzeit zu einer echten Pipeline-Überlegung werden, nicht nur einer theoretischen.

Für die meisten Verkäufer ist dieser Unterschied in der Praxis unsichtbar, da Bildverarbeitung einmal pro SKU stattfindet, nicht bei jedem Seitenaufruf. Er wird hauptsächlich für Verkäufer mit sehr hohen SKU-Zahlen oder häufigem Massen-Neuverarbeitungsbedarf relevant.

Wo jedes Format tatsächlich Sinn ergibt

• JPEG — als universellen Fallback in einer Formatkette verwenden, und als alleiniges Format nur für Kontexte, in denen moderne Formatunterstützung wirklich nicht angenommen werden kann (bestimmte E-Mail-Marketing-Kontexte, manche Drittanbieter-Syndizierungsfeeds mit starren Formatanforderungen).
• WebP — heute eine solide Standard-Primärformatwahl für die meisten E-Commerce-Kataloge: breite Unterstützung, bedeutende Dateigrößeneinsparungen gegenüber JPEG, und überschaubare Kodierkosten selbst im großen Maßstab.
• AVIF — lohnt sich zu priorisieren für vielbesuchte Hero-Bilder und Above-the-Fold-Produktfotografie, wo sich die zusätzlichen Dateigrößeneinsparungen direkt in messbare Seitengeschwindigkeits- und Core-Web-Vitals-Verbesserung übersetzen, und wo die Browser-Unterstützungslücke über eine ordentliche Fallback-Kette handhabbar ist.

Viele gut optimierte Kataloge fahren heute alle drei in einer geschichteten Fallback-Kette, statt sich auf nur eines festzulegen — AVIF zuerst, WebP als Fallback, JPEG als letztes Sicherheitsnetz. Das holt den Kompressionsvorteil dort, wo er unterstützt wird, ohne Kompatibilität für Käufer auf älteren Browsern oder restriktiven In-App-WebViews zu opfern.

Qualitätsüberlegungen jenseits der Dateigröße

• Erhalt feiner Details: Sowohl AVIF als auch WebP handhaben Verläufe und sanfte Farbübergänge bei vergleichbaren Dateigrößen eleganter als JPEG, was das sichtbare Banding reduziert, das in JPEG-komprimierten Produktaufnahmen mit subtilen Farbverläufen auftritt (ein häufiges Problem speziell in der Schmuck- und Glasproduktfotografie).
• Transparenz: Sowohl WebP als auch AVIF unterstützen Alpha-Transparenz, nützlich für Produktbilder, die auf variablen Hintergründen sitzen sollen (manche Marktplatz-Vorlagen, bestimmte E-Mail-Kontexte) — JPEG hat überhaupt keine Transparenzunterstützung.
• Wiederholte Neu-Kompression: Bilder, die mehrfach durch eine Content-Pipeline neu gespeichert oder neu verarbeitet werden, verlieren mit sich akkumulierenden JPEG-Kompressionsartefakten mehr sichtbare Qualität als mit WebP oder AVIF, was für Kataloge mit mehrstufigen Bearbeitungs-Workflows eine echte Überlegung ist.

Häufige Implementierungsfehler

• Nur AVIF ohne Fallback ausliefern, was Bilder für Käufer auf Browsern oder in In-App-WebViews, die es nicht unterstützen, stillschweigend zerstört — ein Fehler, der beim Testen in einem modernen Desktop-Browser unsichtbar ist, aber in der Produktions-Analytik als defekte Bilder auftaucht.
• Übermäßige Kompression zur Jagd nach Dateigröße auf Kosten sichtbarer Qualität, insbesondere bei Hero- und Hauptproduktbildern, wo Detail die Kaufsicherheit direkt beeinflusst.
• Tatsächliche Dateigrößeneinsparungen nicht an echten Katalogbildern testen, bevor man sich auf eine Formatstrategie festlegt — die Schlagzeilen-Kompressionszahlen für jedes Format variieren je nach Bildinhalt genug, dass das Testen an repräsentativen Katalogbildern wichtiger ist als das Vertrauen auf generische Benchmarks.
• Kodierpipeline-Kosten ignorieren bei der Verarbeitung sehr großer Kataloge, was zu unerwartet langen Batch-Verarbeitungszeiten führt, wenn man zu AVIF wechselt, ohne dessen höhere Kodierkosten zu berücksichtigen.

Die CDN oder das Framework die Formataushandlung übernehmen lassen

Manuell für jedes Bild in einem großen Katalog eine Picture-Element-Fallback-Kette zu pflegen, ist echter, laufender Mehraufwand, und die meiste moderne Auslieferungsinfrastruktur handhabt das inzwischen automatisch. Frameworks wie Next.js und Bild-CDNs (Cloudinary, imgix, und ähnliche Dienste) können den Accept-Header des anfragenden Browsers untersuchen und AVIF, WebP, oder JPEG aus einem einzigen Quellbild ausliefern, ohne dass der Verkäufer separate kodierte Dateien oder handgeschriebenes Fallback-Markup für jedes einzelne pflegen muss. Das verlagert die Formatentscheidung von einer einmaligen Produktionswahl zu einer Laufzeitentscheidung pro Anfrage, was generell die bessere Architektur für Kataloge ist, die groß genug sind, dass die manuelle Verwaltung von drei kodierten Versionen jedes Bildes zu einer eigenen Wartungslast wird. Der Kompromiss ist eine Abhängigkeit davon, dass die Aushandlungslogik der CDN oder des Frameworks korrekt funktioniert — es lohnt sich, das direkt zu verifizieren statt anzunehmen, da eine falsch konfigurierte Cache-Schicht ein veraltetes oder falsches Format an eine Teilmenge von Browsern ausliefern kann, ohne einen offensichtlichen Fehler.

Qualitätseinstellungen zählen genauso wie die Formatwahl

Die Formatauswahl bekommt die meiste Aufmerksamkeit, aber die Qualitätseinstellung innerhalb eines gegebenen Formats hat oft einen größeren Effekt auf die endgültige Dateigröße als ein Formatwechsel. Ein JPEG, gespeichert mit Qualität 60, kann kleiner sein als ein WebP, gespeichert mit Qualität 95, obwohl WebP prinzipiell das effizientere Format ist — der Qualitätsparameter leistet in diesem Vergleich mehr Arbeit als die Formatwahl. Die praktische Implikation: Behandeln Sie „Wechsel zu WebP oder AVIF" nicht als Ersatz für das tatsächliche Testen und Feinabstimmen von Qualitätseinstellungen innerhalb des gewählten Formats. Ein ordentlich qualitätsabgestimmtes JPEG-Fallback kann eine unbedacht hochqualitative WebP- oder AVIF-Datei übertreffen, was für die Fallback-Stufe einer Formatkette zählt, die ältere Browser tatsächlich erhalten.

Eine kurze Checkliste für die Formatstrategie

1. Eine geschichtete Fallback-Kette implementieren (AVIF → WebP → JPEG) mit dem <picture>-Element, statt sich auf ein einzelnes Format festzulegen.
2. Tatsächliche Kompressionsergebnisse an repräsentativen Katalogbildern testen, nicht an generischen Benchmark-Zahlen.
3. AVIF/WebP-Konvertierung zunächst für vielbesuchte und Above-the-Fold-Bilder priorisieren, wenn die Verarbeitung des gesamten Katalogs auf einmal nicht praktikabel ist.
4. Rendering über die Browser und In-App-WebViews verifizieren, die Ihr tatsächlicher Traffic nutzt, nicht nur moderne Desktop-Browser.

Unser Web-Bildoptimierungsservice übernimmt Formatkonvertierung, Kompression, und Fallback-Kettenaufbau über WebP, AVIF, und JPEG für E-Commerce-Kataloge, wobei Dateigröße gegen das sichtbare Detail abgewogen wird, das Ihre Produktfotografie halten muss. Reichen Sie 5 Bilder für einen kostenlosen Test ein, um die Kompressions- und Qualitätskompromisse an Ihren eigenen Produktfotos zu sehen, bevor Sie Ihren Katalog beauftragen.