JPEG XL und Core Web Vitals: Was Sie jetzt wissen müssen, da Chrome es ausliefert

JPEG XL kehrt endlich zu Chrome zurück

Nach drei Jahren der Kontroverse ist JPEG XL zu Chromium zurückgekehrt. Chrome 145, veröffentlicht Anfang Februar 2026, wird mit einem JPEG XL-Decoder ausgeliefert. Noch hinter einem Flag, aber funktional erstmals seit seiner umstrittenen Entfernung Ende 2022 wieder in der Codebasis vorhanden. Das ist wichtig, weil JPEG XL jedem etablierten Web-Bildformat in den meisten technischen Dimensionen nachweislich überlegen ist: 50 bis 60 % kleiner als JPEG, 10 bis 15 % bessere Komprimierung als AVIF bei vergleichbaren Encoding-Geschwindigkeiten und das einzige moderne Format mit echtem progressiven Decoding. Für Web-Performance-Experten stellt die Entwicklung des Formats – vom ISO-Standard über die Chrome-Verbannung bis zur Wiederauferstehung – sowohl eine technische Chance als auch eine warnende Geschichte über die Macht der Browser-Hersteller über die Webplattform dar.

Zuletzt überprüft von Arjen Karel im Februar 2026

Browser-Unterstützung im Februar 2026 liegt bei nur 12 %

Die effektive globale Browser-Unterstützung von JPEG XL liegt bei ungefähr 12 %, fast ausschließlich durch Safari-Nutzer. Diese Zahl wird sich bald ändern. Aber der Zeitplan bleibt ungewiss.

Safari 17+ (ausgeliefert September 2023) bietet native JPEG XL-Dekodierung auf macOS Sonoma, iOS 17, iPadOS 17, watchOS und visionOS. Apples Implementierung delegiert die Dekodierung an das Image-Framework auf Betriebssystemebene, was bedeutet, dass es überall funktioniert, wo Safari läuft. Allerdings ist Safaris Unterstützung ausdrücklich unvollständig: keine Animationsunterstützung und kein progressives Decoding. Zwei der markantesten Funktionen von JPEG XL. Dies ist eine bedeutsame Einschränkung, die das vollständige Wertversprechen des Formats auf Apple-Geräten untergräbt.

Chrome 145 (Februar 2026) führt JPEG XL über einen reinen Rust-Decoder namens jxl-rs wieder ein und ersetzt die frühere C++-libjxl-Implementierung. Der Decoder ist hinter chrome://flags/#enable-jxl-image-format gesperrt und standardmäßig nicht aktiviert. Google hat klare Bedingungen für die Standardaktivierung festgelegt: eine Verpflichtung zur langfristigen Wartung und die Erfüllung standardmäßiger Launch-Kriterien. Der Rust-Decoder erreicht derzeit 15 bis 25 % der Geschwindigkeit der C++-Referenzimplementierung, wobei allein im Dezember 2025 26 Optimierungs-PRs zusammengeführt wurden. Bestätigte funktionierende Fähigkeiten umfassen ICC-Farbprofile, Animationen, Alpha/Transparenz, Wide Gamut (Display P3) und HDR (PQ/HLG).

Um JPEG XL heute in Chrome auszuprobieren, navigieren Sie zu chrome://flags/#enable-jxl-image-format und setzen Sie es auf Aktiviert. Starten Sie Chrome neu. Jede Website, die bereits JXL-Bilder ausliefert (z. B. Cloudinary-Kunden), wird diese dann an Ihren Browser liefern.

Firefox hinkt am weitesten hinterher. Das Format ist nur in Firefox Nightly hinter dem Flag image.jxl.enabled verfügbar. Entscheidend ist, dass der Decoder-Code in stabilen Builds überhaupt nicht kompiliert wird, sodass das Flag im Release-Firefox nichts bewirkt. Mozillas Position hat sich von „negativ“ zu „neutral“ verschoben. Der jxl-rs Rust-Decoder ist in Firefox Nightly gelandet (Ziel: Firefox 149), aber sechs Blocker bleiben vor der Auslieferung in der stabilen Version: Farbprofil-Unterstützung, progressives Decoding, HDR, Profiler-Integration, Kompilierung in Release-Builds und das Bestehen der Web Platform Tests. Für die stabile Unterstützung existiert kein Zeitplan.

Edge enthält als Chromium-Derivat wahrscheinlich den jxl-rs-Code aus Chrome 145, hat aber JPEG XL-Unterstützung nicht offiziell angekündigt oder dokumentiert. Die Release Notes von Edge 145 erwähnen es nicht.

Interop 2026 hat JPEG XL als Untersuchungsbereich aufgenommen (nicht als vollständigen Fokusbereich), wobei Apple, Google, Microsoft und Mozilla alle beteiligt sind. Dies signalisiert die herstellerübergreifende Absicht, umfassende Testsuiten zu erstellen, was typischerweise einer breiteren Auslieferung vorausgeht.

Wie JPEG XL jede Alternative übertrifft. Und wo nicht

Die Geschichte der Komprimierungseffizienz ist nuanciert und hängt stark vom Inhaltstyp und der Bitrate ab. Auf höchster Ebene gewinnt JPEG XL die wichtigsten praxisrelevanten Vergleiche.

Gegen JPEG

Die Gewinne sind dramatisch. JPEG XL erreicht visuell verlustfreie Qualität bei ungefähr 1,2 Bits pro Pixel, wo JPEG 2,4 bpp benötigt. Eine 2:1-Verbesserung. Der DebugBear-Benchmark eines 990 KB großen Fotos zeigte JPEG XL bei 472 KB (52 % Einsparung), verglichen mit WebP bei 700 KB und AVIF bei 507 KB. Cloudinarys Tests mit über 40.000 Bildern ergaben, dass JPEG XL bei Effort 6 Dateien erzeugte, die 20 % kleiner als AVIF waren und dabei 2,5-mal schneller kodierten.

Gegen AVIF

Der Vergleich ist bitratenabhängig. Bei niedrigen Bitraten unter 0,4 bpp (starke Komprimierung) übertrifft AVIF JPEG XL. Es erzeugt glattere Bilder mit weniger Artefakten. Bei mittleren bis hohen Bitraten (0,4 bpp und höher), wo die meiste Web-Fotografie angesiedelt ist, gewinnt JPEG XL durchgehend bei der Detailerhaltung und Wiedergabetreue. Googles eigene AVIF-Vergleichsstudie zeigte, dass 9 von 13 Qualitätsmetriken JPEG XL bevorzugten bei praxisnahen Encoder-Geschwindigkeitseinstellungen. Der Unterschied bei der Encoding-Geschwindigkeit ist enorm: AVIF (über libaom) ist eine Größenordnung langsamer als JPEG XL beim Single-Thread-Encoding. Bei AVIFs langsamsten Einstellungen (~0,5 Mpx/s) erreicht es die Komprimierungsdichte von JPEG XLs zweitschnellster Einstellung bei 52 Mpx/s. Ein 100-facher Geschwindigkeitsunterschied.

Gegen WebP

JPEG XL gewinnt eindeutig. WebP ist auf 8-Bit-Farbtiefe, 4:2:0-Chroma-Subsampling im verlustbehafteten Modus und eine maximale Auflösung von 16.383 x 16.383 Pixeln beschränkt. JPEG XL unterstützt bis zu 32 Bit pro Kanal (Ganzzahl oder Gleitkomma), Auflösungen von über 1 Milliarde Pixel pro Seite und hat keine Chroma-Subsampling-Einschränkung.

Der Inhaltstyp zählt

Für spezifische Inhaltstypen zeigten die DebugBear-Benchmarks ein gemischteres Bild. AVIF gewann bei Logos (2 KB vs. 6 KB bei JXL) und Transparenzbildern (18 KB vs. 63 KB), während JPEG XL bei Fotos (472 KB vs. 507 KB) und animierten Inhalten gewann, wo es eine 99%ige Komprimierung erzielte (14 KB aus einem 1,3 MB großen GIF, gegenüber 56 KB bei AVIF). Diese Ergebnisse verwendeten Cloudinarys Standardeinstellungen und repräsentieren daher typische statt optimierte Ausgaben.

Funktionsvergleich

Zwei Funktionen, die kein anderes Format bieten kann

JPEG XLs strategisch wichtigste Funktionen sind progressives Decoding und verlustfreie JPEG-Transkodierung. Kein Konkurrent bietet beides.

Progressives Decoding

Progressives Decoding verändert grundlegend, wie Bilder geladen werden. JPEG XL-Dateien sind immer mindestens 8x8 progressiv; der DC-Frame (Niederfrequenz) wird immer zuerst kodiert. Mit nur ~1 % der heruntergeladenen Dateidaten erscheint eine nutzbare Vollbildvorschau. Verglichen mit progressivem JPEG, das 10 bis 15 % für seinen ersten Scan benötigt. Noch wichtiger: JPEG XL unterstützt salienzbasierte Progression: Machine-Learning-Modelle können die visuell wichtigsten Bereiche identifizieren (Gesichter in Porträts, Produktdetails im E-Commerce) und diese Bereiche so kodieren, dass sie zuerst ankommen. Der Decoder glättet die Grenzen zwischen abgeschlossenen und noch ladenden Bereichen.

Dies erzeugt eine andere Rendering-Zeitachse. AVIF benötigt das vollständig komprimierte Bild, bevor die Dekodierung beginnen kann: Die Gesamtzeit entspricht der Downloadzeit plus der Dekodierungszeit, sequentiell. JPEG XL überlappt Transfer und Dekodierung, sodass der Nutzer deutlich früher bedeutungsvolle Inhalte sieht. Cloudinary hat festgestellt, dass JPEG XLs progressives Rendering die Notwendigkeit separater Low Quality Image Placeholder (LQIP)-Dateien eliminiert und so redundante Bytes vollständig entfernt. Allerdings ist zu beachten, dass Safaris aktuelle Implementierung kein progressives Decoding unterstützt, was diesen Vorteil auf zukünftige Chrome- und Firefox-Implementierungen beschränkt.

Verlustfreie JPEG-Transkodierung

Verlustfreie JPEG-Transkodierung ist JPEG XLs Geheimwaffe. Das Format kann JPEGs DCT-Blockkoeffizienten direkt in seine eigenen VarDCT-Blöcke kopieren und dabei nur die Entropiekodierung verbessern. Das Ergebnis: ~20 % durchschnittliche Dateigrößenreduktion (Bereich: 13 bis 22 %) bei bitgenauer Rekonstruierbarkeit der Original-JPEG-Datei aus der JXL-Datei. Kein anderes Format kann das. Die Transkodierung zu WebP oder AVIF erfordert die Dekodierung in Pixel und erneute Kodierung, was zu Generationsverlust führt. Google Cloud Platforms DICOM-API nutzt diese Fähigkeit bereits, um die Dateigrößen medizinischer Bilder um 20 % zu reduzieren.

Im Web-Maßstab wären die Bandbreiteneinsparungen enorm, wenn alle aktuellen JPEGs verlustfrei zu JXL transkodiert würden. Die JPEG XL-Community schätzt die Energieeinsparung auf das Äquivalent der Stromversorgung von ~487.000 US-Haushalten für eine Stunde pro Tag.

Was das für die Core Web Vitals bedeutet

JPEG XL beeinflusst jede Core Web Vitals-Metrik über verschiedene Mechanismen, und der Zusammenhang ist nuancierter als „kleiner Dateien = bessere Werte“.

LCP (Largest Contentful Paint)

LCP profitiert von zwei sich verstärkenden Effekten. Erstens reduzieren kleinere Dateigrößen die Resource Load Duration. Die Download-Phase. Eine 52%ige Reduktion gegenüber JPEG bedeutet, dass das Hero-Bild auf bandbreitenbeschränkten Verbindungen ungefähr doppelt so schnell ankommt. Zweitens dekodiert JPEG XL schneller als AVIF, was die Element Render Delay reduziert. AVIFs komplexe, vom Video-Codec abgeleitete Dekodierung kann auf mobilen Geräten bedeutenden CPU-Overhead erzeugen, wo ein kleineres AVIF, das schneller heruntergeladen wird, teilweise durch längere Dekodierungszeit zunichte gemacht werden kann. JPEG XLs Dekodierungsgeschwindigkeit von bis zu 132 Mpx/s und SIMD-Optimierung minimieren diesen Engpass. Allerdings wird LCP gemessen, wenn das Bild vollständig gerendert ist, sodass progressives Decoding den LCP-Zeitstempel nicht direkt verbessert. Es verbessert die wahrgenommene Performance, was für die User Experience wichtig ist, auch wenn es die Metrik nicht bewegt. Wenn JPEG XL Ihr LCP-Bildformat ist, laden Sie es vor, damit der Browser es so früh wie möglich entdeckt.

CLS (Cumulative Layout Shift)

CLS ist formatunabhängig. Alle Formate profitieren gleichermaßen von expliziten Width- und Height-Attributen. JPEG XL kodiert Dimensionsinformationen in frühen Headern, was theoretisch Browsern helfen könnte, schneller Platz zu reservieren, aber der praktische Einfluss ist vernachlässigbar im Vergleich zum einfachen Setzen der Dimensionen in HTML.

INP (Interaction to Next Paint)

INP kann durch schwere Bilddekodierung auf dem Main Thread beeinträchtigt werden. JPEG XLs schnellere Dekodierung und SIMD-Optimierung bedeuten weniger Main-Thread-Blockierung als AVIF, obwohl beide Formate in modernen Browsern typischerweise außerhalb des Main Threads dekodiert werden.

Auswirkungen in der Praxis

Laut dem 2025 Web Almanac macht JPEG immer noch 57 % der LCP-Bilder auf Mobil und Desktop aus. WebP ist auf 11 % gewachsen, 4 Prozentpunkte mehr als 2024. AVIF liegt bei nur 0,7 %. JPEG XL wird noch nicht einmal gemessen. Die mediane Webseite lädt auf Mobilgeräten 19 Bilder mit insgesamt 911 KB. Die Konvertierung von JPEG zu JPEG XL würde ungefähr 450 bis 550 KB pro Seite einsparen. Bei einem medianen Desktop-Bildgewicht von 1.058 KB nähern sich die Einsparungen 500 bis 630 KB.

Auf den von CoreDash überwachten Websites zeigen Seiten, die Bilder in modernen Formaten (AVIF oder WebP) ausliefern, 81 % gute LCP-Raten, verglichen mit 64 % für Seiten, die sich noch ausschließlich auf JPEG verlassen. Wenn JPEG XL breitere Browser-Unterstützung erreicht, sollte sich die Lücke weiter vergrößern. Die Überwachung Ihrer Real User Monitoring-Daten nach der Aktivierung der JXL-Auslieferung wird Ihnen genau zeigen, wie viel echte Nutzer davon profitieren.

JPEG XL heute mit korrekten Fallbacks ausliefern

Die Implementierung erfordert eine mehrschichtige Strategie: das <picture>-Element für HTML-Bilder, serverseitige Content-Negotiation für CSS und dynamisch referenzierte Bilder sowie CDN-Automatisierung, wo verfügbar.

Das Picture-Element

Das <picture>-Element bietet den saubersten clientseitigen Ansatz. Browser werten <source>-Elemente von oben nach unten aus und verwenden das erste unterstützte Format:

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Description" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Wenn dieses Bild Ihr Hero ist und wahrscheinlich das LCP-Element, entfernen Sie loading="lazy" und setzen Sie seine fetchpriority auf high. Laden Sie Ihr LCP-Bild niemals lazy.

Für responsive Bilder benötigt jede Source ihr eigenes srcset mit Breitendeskriptoren. Das erzeugt eine kombinatorische Explosion von 12+ Varianten pro Bild (3 oder 4 Formate x 3 oder 4 Größen). Hier wird CDN-Automatisierung unverzichtbar.

Serverseitige Content-Negotiation

Serverseitige Content-Negotiation untersucht den Accept-Header. Safari 17+ sendet image/jxl in seinem Accept-Header. Die Nginx-Konfiguration ordnet dies Dateierweiterungen zu:

map $http_accept $img_ext {
    ~image/jxl   '.jxl';
    ~image/avif  '.avif';
    ~image/webp  '.webp';
    default      '';
}

Das entscheidende Detail: Fügen Sie immer Vary: Accept in den Antwort-Header ein, damit CDNs und Proxy-Caches separate Varianten pro Format speichern. Ohne dies wird eine gecachte JXL-Antwort an Browser ausgeliefert, die sie nicht dekodieren können.

CDN-Unterstützung

Die CDN-Unterstützung ist uneinheitlich. Cloudinary bietet volle JPEG XL-Unterstützung über seinen f_auto-Parameter. Wenig überraschend, da Cloudinary das Format mitentwickelt hat und bereits ungefähr 1 Milliarde JPEG XL-Bilder pro Tag ausliefert. Fastlys Image Optimizer hat im Juli 2024 volle JPEG XL-Unterstützung hinzugefügt, mit Encoding Effort 3 bei 4 Threads und einer behaupteten Einsparung von ~60 % gegenüber JPEG. Cloudflare unterstützt trotz starker Community-Nachfrage keine JPEG XL-Konvertierung in seinem Image Resizing-Produkt. Es kann JXL-Varianten von Ihrem Origin über Vary: Accept cachen, aber nicht generieren. Wenn Sie Cloudflare nutzen, lesen Sie unseren Leitfaden zur Konfiguration von Cloudflare für die Core Web Vitals für die Einstellungen, die helfen. AWS CloudFront, Akamai und Azure haben keine native JPEG XL-Unterstützung.

Tooling

Die Werkzeuge zur Erzeugung von JPEG XL-Dateien konzentrieren sich auf cjxl aus der libjxl-Referenzimplementierung. Wichtige Parameter: -d für Distanz (0 = verlustfrei, 1,0 bis 2,0 für verlustbehaftete Webqualität), -e für Effort (1 bis 9, Standard 7) und -p für progressives Encoding. Für JPEG-Eingaben führt cjxl input.jpg output.jxl standardmäßig eine verlustfreie Transkodierung durch. Der einfachste mögliche Migrationspfad. ImageMagick, libvips (seit 8.11) und Photoshop v25 unterstützen ebenfalls JXL. Allerdings hat sharp (die Node.js-Bildbibliothek, die Next.js antreibt) seit v0.31.3 experimentelle JXL-Unterstützung, aber die über npm verteilten vorgefertigten Binärdateien enthalten den JXL-Codec nicht. Sie müssten libvips selbst mit libjxl-Unterstützung kompilieren, und der Maintainer hat die Anfrage geschlossen für vorgefertigte JXL-Binärdateien. Das bedeutet, dass Next.js keine praktische JPEG XL-Unterstützung von Haus aus hat. WordPress-Core-Unterstützung wird als Ticket #52788 verfolgt, aber der eigentliche Blocker ist, dass PHPs GD-Extension JPEG XL nicht unterstützt. PHP 8.5 (November 2025) hat immer noch keine GD-Unterstützung für JXL.

Die Halloween-Entscheidung und ihre dreijährige Umkehrung

Die politische Geschichte von JPEG XL in Chrome ist eine Fallstudie über die Macht der Browser-Hersteller über Webstandards. Sie zu verstehen ist wichtig, weil sie die Kräfte offenbart, die bestimmen, welche Technologien die Nutzer erreichen.

Am 31. Oktober 2022 kündigte Jim Bankoski vom Chrome-Team bei Google in dem, was schnell als „Halloween-Entscheidung“ bekannt wurde, die Entfernung der experimentellen JPEG XL-Unterstützung an. Die genannten Gründe waren vierfach: experimentelle Flags sollten nicht unbegrenzt bestehen bleiben; unzureichendes Ökosystem-Interesse; unzureichende inkrementelle Vorteile gegenüber bestehenden Formaten; und Wartungsaufwand. Bankoski schlug WebAssembly als „einen großartigen Weg nach vorn“ für diejenigen vor, die JPEG XL in Chrome wollten.

Die Gegenreaktion war sofort und anhaltend. Das Chromium-Issue wurde zum zweitmeist markierten in der gesamten Projektgeschichte, mit über 1.000 Upvotes und Kommentaren von Vertretern von Intel, Adobe, Meta, Shopify, The Guardian, Flickr und der Krita Foundation. Jon Sneyers, der JPEG XL-Miterfinder bei Cloudinary, veröffentlichte eine detaillierte technische Widerlegung („The Case for JPEG XL“), die zeigte, dass Googles veröffentlichte Vergleichstests fehlerhafte JPEG XL-Implementierungen und Metriken verwendeten, die AVIF bevorzugten. Die Free Software Foundation bezeichnete Googles Entscheidung als Beweis dafür, dass Google Chrome zum Schiedsrichter über Webstandards geworden war, und beschuldigte das Unternehmen, im eigenen Interesse zu handeln. Da AVIF von AV1 abstammt, das von der Alliance for Open Media entwickelt wurde, die Google mitgegründet hat.

Die Ironie entging den Beobachtern nicht: Google selbst hatte JPEG XL durch sein PIK-Projekt mitentwickelt, was die Entscheidung, es aus Chrome zu entfernen, umso verwirrender machte. Als JPEG XL für Interop 2024 vorgeschlagen wurde, erhielt es 646 Community-Reaktionen. 4,5-mal so viele wie der zweitplatzierte Vorschlag. Und wurde mit nur „fehlendem Konsens“ als Begründung abgelehnt.

Was die Entscheidung letztendlich umkehrte, war die Ökosystem-Dynamik, die Chromes Abwesenheit unhaltbar machte. Apples Auslieferung von Safari 17 mit JPEG XL-Unterstützung im September 2023 war der erste große Durchbruch. Mozillas Verschiebung von „negativ“ zu „neutral“ und dann zur aktiven Bereitschaft zur Implementierung (mit einem Rust-Decoder) erhöhte den Druck. Die Ankündigung der PDF Association, JPEG XL als bevorzugtes HDR-Format für PDF im Oktober 2025 könnte der entscheidende Wendepunkt gewesen sein. Chromes integrierter PDF-Viewer würde JXL-Unterstützung benötigen, um konform zu bleiben. Am 21. November 2025 veröffentlichte Rick Byers (Chrome Architecture Tech Lead) die Umkehrung und begrüßte Beiträge zur Integration eines performanten und speichersicheren JPEG XL-Decoders in Chromium. Bis Januar 2026 war der Rust-basierte jxl-rs-Decoder zusammengeführt, und Chrome 145 lieferte ihn im Februar 2026 hinter einem Flag aus.

Fazit: Qualitätsquellen speichern, bei Bedarf konvertieren

JPEG XL ist technisch das beste universelle Bildformat, das verfügbar ist. Bessere Komprimierung als AVIF bei praxistauglichen Encoding-Geschwindigkeiten, progressives Decoding, das kein Konkurrent bietet, und verlustfreie JPEG-Transkodierung, die sofort 20 % Einsparung bei null Qualitätsverlust bietet. Die politischen Hindernisse, die seine Einführung drei Jahre lang blockierten, lösen sich auf: Chrome hat Code im Repository, Firefox integriert aktiv denselben Rust-Decoder, und Safari liefert seit 2023 Unterstützung.

Der praktische Weg nach vorn ist, das qualitativ hochwertigste Quellmaterial zu speichern, das Sie können, und Ihre Delivery-Pipeline die Formatkonvertierung übernehmen zu lassen. Bewahren Sie verlustfreie PNGs oder hochwertige Master-JPEGs als Originale auf. Verwenden Sie ein CDN mit automatischer Format-Negotiation: Cloudinarys f_auto, Fastly Image Optimizer oder Cloudflare Polish untersuchen den Accept-Header des Browsers und liefern JXL, AVIF, WebP oder JPEG, ohne dass Sie eine einzige Variante vorab generieren müssen. Wenn Sie selbst hosten, richten Sie eine On-Demand-Konvertierung mit libvips oder ImageMagick hinter einem serverseitigen Cache ein, der einmal pro Format beim ersten Request konvertiert, anstatt vier Varianten pro Bild im Voraus zu generieren. JPEG XLs verlustfreie Transkodierung passt perfekt zu diesem Modell: Ihre bestehenden JPEGs sind die Quelle, und ihre Konvertierung zu JXL ist effektiv eine On-Demand-Konvertierung ohne Qualitätsverlust. Die offene Frage ist nicht, ob JPEG XL breite Browser-Unterstützung erreichen wird, sondern wann Chrome das Flag standardmäßig von aus auf an umschalten wird. Und die einzig ehrliche Antwort ist, dass kein Zeitplan angekündigt wurde. Die dreijährige Verbannung des Formats aus Chrome sollte Begeisterung mit Pragmatismus mäßigen: Liefern Sie es dort aus, wo es unterstützt wird, mit elegantem Fallback anderswo, und lassen Sie das CDN oder die Konvertierungs-Pipeline den Rest erledigen.