Die Unterstützung neuer Bildformate im Web war nie ein rein technisches Thema – sondern stets auch ein Spiegel wirtschaftlicher Interessen, strategischer Allianzen und mächtiger Entscheidungen im Hintergrund. Besonders der Fall JPEG XL zeigt: Was vielversprechend beginnt, kann abrupt enden, wenn ein großer Browser-Hersteller das Format fallen lässt.
Eine kurze Geschichte der Bildformate im Web
Seit den frühen Tagen des Internets sind Bildformate für die Nutzererfahrung entscheidend. Das GIF-Format war in den 90er-Jahren erste Wahl für Grafiken mit wenigen Farben und Animationen. Mit JPEG etablierte sich parallel ein effizienter Standard für Fotos, während PNG als verlustfreies Format für Transparenz-Anforderungen hinzugefügt wurde. Die Rollenverteilung war lange klar – bis die Anforderungen durch höhere Bildschirmauflösungen, Bandbreitenoptimierung und mobile Nutzung massiv anstiegen.
Ab der Mitte der 2010er-Jahre begann ein Wettlauf um moderne Bildformate, die etwa geringere Dateigrößen bei gleicher visueller Qualität bieten. WebP – entwickelt von Google – setzte erste wichtige Impulse. Es bot im Vergleich zu JPEG durchschnittlich 25–35 % kleinere Dateien. Zahlreiche Benchmark-Analysen, etwa von Cloudinary oder Mozilla, bestätigten diese Einsparungen eindeutig.
In den folgenden Jahren kamen weitere Formate wie AVIF (von der Alliance for Open Media, teils mit Beteiligung von Google, Amazon, Netflix) und JPEG XL hinzu. Besonders letzteres wurde von vielen als „Nachfolger“ des JPEG angesehen.
Warum JPEG XL als Hoffnungsträger galt
JPEG XL wurde 2019 erstmals als vielversprechender neuer Bildstandard vorgestellt. Unterstützt von der Joint Photographic Experts Group (also den ursprünglichen Erfindern von JPEG), kombinierte JPEG XL zahlreiche Vorteile:
- Effizientere Kompression bei gleichbleibender Bildqualität, teils 20–50 % besser als JPEG
- Lossless- und lossy-Kompression in einem Format
- Rückwärtskompatibilität: Alte JPEG-Dateien konnten automatisch in JPEG XL überführt werden
- Unterstützung für HDR, Animationen und breite Farbräume
- Open-Source-Lizensierung und frei von Patenten
In frühen Tests schlug JPEG XL sowohl WebP als auch AVIF in einigen Szenarien – etwa beim Beibehalten von Detailreichtum bei geringster Größe (Quelle: https://cloudinary.com/blog/jpeg-xl-compression). Die Entwicklergemeinde signalisierte Interesse; Werkzeuge wie ImageMagick und CLI-Converter unterstützten das Format frühzeitig.
Google steigt ein – und dann aus
2021 begann Google, JPEG XL nativ in Canary-Versionen von Chrome zu testen. In der Webentwickler-Community wuchs die Hoffnung, dass eine breite Unterstützung folgen würde. Doch im Oktober 2022 überraschte Google mit der Entscheidung, JPEG XL aus Blink (der Chromium-Rendering-Engine) zu entfernen (Chromium Issue 1178058).
Die Begründung: „Kein ausreichendes Interesse aus dem Ökosystem“ und „kein Bedarf, neue Bildformate einzuführen“ – eine Einschätzung, die viel Widerspruch auslöste. Mozilla hielt daraufhin an AVIF und WebP fest – und weder Safari noch Microsoft Edge implementierten JPEG XL. Damit fiel ein zentraler Pfeiler für die potenzielle Adoption weg.
Was steckt hinter solch widersprüchlichem Verhalten?
Warum wird ein Format wie JPEG XL erst integriert – und dann doch nicht unterstützt? Laut Analysen im Chromium-Bugtracker sowie Entwicklerreaktionen auf GitHub, Reddit und Hacker News scheint es mehrere Gründe zu geben:
- Strategische Investitionen: Google hat mit WebP und AVIF bereits „eigene“ Formate platziert und möchte offenbar Redundanz vermeiden.
- Rendering-Kosten: Die Integration neuer Codecs ist komplex. JPEG XL erfordert neue Parser und könnte Performance-Probleme verursachen.
- Fragmentierung: Ohne ausreichend Tooling im Hard- und Softwarebereich verliert ein neues Format an praktischer Relevanz.
Diese Argumente stehen jedoch teils im Gegensatz zur Community-Resonanz. Laut einer Umfrage unter über 800 Webentwicklern im Web Almanac 2023 (https://almanac.httparchive.org/en/2023/media) wünschten sich 42 % eine native JPEG XL-Unterstützung. Viele nannten Performance-Vorteile und Transparenz der Lizenzierung als Hauptgründe.
Die Folgen für Webentwickler: Unsicherheit und Mehraufwand
Wenn ein aussichtsreiches Format fällt, hat das direkte Auswirkungen auf die tägliche Arbeit in der Frontend-Entwicklung und im Asset-Management. Entwickler und Designer müssen zusätzliche Checks einbauen: Welcher Browser unterstützt welches Format? Welche Fallbacks sind erforderlich? Wie können Build-Pipelines automatisiert darauf reagieren?
Hinzu kommen Probleme im Bild-CDN-Bereich: Anbieter wie Imgix oder Cloudinary unterstützen zwar moderne Formate, müssen aber ständig Workarounds realisieren, um unterschiedliche Browserpräferenzen zu bedienen. Das bedeutet: mehr Kosten, mehr Komplexität, weniger Standardisierung.
Ein Beispiel: Wer AVIF als primäres Format nutzt, muss zwingend auf Safari-Rückfälle achten (bis macOS 12 kein Support). JPEG XL wäre dagegen für Apple vergleichsweise einfach zu implementieren gewesen, da es nativ auf JPEG aufbaut.
Aktuelle Statistik: Bildformate in der Praxis
Laut aktueller Analyse von HTTP Archive (2024):
- WebP wird auf über 70 % der Desktop-Websites verwendet (Quelle: https://httparchive.org/reports/state-of-images)
- AVIF ist mit 8-12 % noch deutlich seltener im Einsatz, wächst aber mit etwa 3–5 % pro Jahr
JPEG XL liegt im einstelligen Bereich – vor allem wegen der fehlenden Browserunterstützung. Besonders hoch ist der Anteil bei Plattformen wie GitHub oder Wikipedia, die experimentell mit Opt-in arbeiten.
Empfehlungen für Webentwickler im Format-Dschungel
Was können Developer angesichts der unsteten Browserentscheidungen tun? Einige bewährte Strategien helfen, langfristig flexibel zu bleiben:
- Auf Grundlage von Nutzerdaten entscheiden: Analysiere deine Zielgruppe – je nach Browser- und Gerätetyp kann sich der Einsatz moderner Formate mehr oder weniger lohnen.
- Responsive Bildausspielung priorisieren: Nutze srcset, picture-Element und Server-Side Rendering, um dynamisch das optimale Format bereitzustellen.
- Bilder vorausschauend optimieren: Wähle Formate so, dass du in der Zukunft flexibel auf neue Standards wechseln kannst – etwa mit einem vorbereiteten Build-System (z. B. mit AVIF-Fallback zu WebP).
Ein Blick in die Zukunft: Gibt es Hoffnung für JPEG XL?
Ob JPEG XL ein Comeback schafft, ist derzeit ungewiss. Fortschritte in der Hardware-Unterstützung (z. B. durch OpenCL-Backends), verbesserte Toolings und wachsende Nachfrage aus der Open-Source-Community könnten zu einem Umdenken führen. Mitte 2024 erklärte ein Google-Entwickler im Chromium-Issueboard, dass eine „Reevaluierung bei entsprechender Marktdynamik nicht ausgeschlossen“ sei.
Gleichzeitig gewinnen „universelle“ Formate wie AVIF an Bedeutung – auch, da Apple diese nun nativ in Safari (seit macOS 13) unterstützt. Für Webentwickler heißt das: Wer auf Standardkonformität und Robustheit achtet, fährt weiterhin mit Multi-Format-Strategien am besten.
Am Ende bleibt festzuhalten: Entscheidungen großer Player über unterstützte Formate sind selten rein technisch motiviert – sie zeigen die Machtverteilung im modernen Web und deren direkte Auswirkung auf Entwicklerteams weltweit.
Abschließender Appell: Teilt eure Erfahrungen mit Bildformaten
Welche Formate nutzt ihr in euren Projekten? Habt ihr Erfahrungen mit JPEG XL sammeln können – oder verzichtet ihr aus Kompatibilitätsgründen? Wir laden euch ein, eure Strategien, Tools und Lessons Learned in den Kommentaren mit der Community zu teilen. Der Austausch hilft uns allen, eine bessere, schnellere und nachhaltigere Weblandschaft zu gestalten.
