JPEG XL en Core Web Vitals: wat je moet weten nu Chrome het ondersteunt

JPEG XL komt eindelijk terug naar Chrome

Na drie jaar controverse is JPEG XL terug in Chromium. Chrome 145, uitgebracht begin februari 2026, bevat een JPEG XL decoder. Nog steeds achter een flag, maar voor het eerst sinds de omstreden verwijdering eind 2022 weer functioneel aanwezig in de codebase. Dit is belangrijk. JPEG XL is op de meeste technische vlakken aantoonbaar superieur aan elk bestaand afbeeldingsformaat voor het web: 50 tot 60% kleiner dan JPEG, 10 tot 15% betere compressie dan AVIF bij gelijkwaardige snelheden voor encoding, en het enige moderne formaat met echte progressive decoding. Voor web performance professionals is het traject van het formaat van ISO-standaard naar Chrome-verbanning naar wederopstanding zowel een technische kans als een waarschuwing over de macht van browserleveranciers over het webplatform.

Laatst beoordeeld door Arjen Karel in februari 2026

Browserondersteuning in februari 2026 is slechts 12%

De effectieve wereldwijde browserondersteuning van JPEG XL ligt op ongeveer 12%. Dit komt bijna volledig door Safari-gebruikers. Dat getal gaat veranderen. Maar de tijdlijn blijft onzeker.

Safari 17+ (uitgebracht in september 2023) biedt native JPEG XL decoding in macOS Sonoma, iOS 17, iPadOS 17, watchOS en visionOS. De implementatie van Apple delegeert de decoding naar het image framework op OS-niveau. Hierdoor werkt het overal waar Safari draait. De ondersteuning in Safari is echter expliciet gedeeltelijk: geen ondersteuning voor animatie en geen progressive decoding. Twee van de meest kenmerkende features van JPEG XL. Dit is een significante beperking die de volledige waardepropositie van het formaat op Apple-apparaten ondermijnt.

Chrome 145 (februari 2026) herintroduceert JPEG XL via een pure Rust decoder genaamd jxl-rs. Deze vervangt de eerdere C++ libjxl implementatie. De decoder zit verborgen achter chrome://flags/#enable-jxl-image-format en staat niet standaard aan. Google heeft duidelijke voorwaarden gesteld voor standaard activering: een toezegging voor lange termijn onderhoud en het voldoen aan standaard lanceringscriteria. De Rust decoder presteert momenteel binnen 15 tot 25% van de snelheid van de C++ referentie-implementatie. Alleen al in december 2025 zijn er 26 optimalisatie-PR's samengevoegd. Bevestigde werkende features omvatten ICC-kleurprofielen, animaties, alpha/transparantie, wide gamut (Display P3) en HDR (PQ/HLG).

Om JPEG XL vandaag in Chrome te proberen, navigeer je naar chrome://flags/#enable-jxl-image-format en zet je dit op Enabled. Herstart Chrome. Elke site die al JXL-afbeeldingen serveert (Cloudinary-klanten bijvoorbeeld) zal deze direct aan je browser leveren.

Firefox loopt het verst achter. Het formaat is alleen beschikbaar in Firefox Nightly achter de image.jxl.enabled flag. Cruciaal is dat de code van de decoder helemaal niet wordt gecompileerd in stabiele builds. De flag doet dus niets in de Firefox release. Het standpunt van Mozilla is verschoven van "negatief" naar "neutraal". De jxl-rs Rust decoder is geland in Firefox Nightly (gericht op Firefox 149). Er resteren echter zes blockers voordat deze in de stabiele versie kan verschijnen: ondersteuning voor kleurprofielen, progressive decoding, HDR, profiler-integratie, compilatie in release builds en het behalen van de Web Platform Tests. Er is geen tijdlijn voor stabiele ondersteuning.

Edge bevat als Chromium-afgeleide waarschijnlijk de jxl-rs code van Chrome 145. Er is echter geen officiële aankondiging of documentatie over JPEG XL ondersteuning. De release notes van Edge 145 maken er geen melding van.

Interop 2026 heeft JPEG XL opgenomen als een investigation area (geen volledige focus area). Apple, Google, Microsoft en Mozilla doen hier allemaal aan mee. Dit wijst op de intentie van meerdere leveranciers om uitgebreide test suites te bouwen. Dit gaat meestal vooraf aan een bredere uitrol.

Hoe JPEG XL elk alternatief verslaat. En waar niet

Het verhaal rond compressie-efficiëntie is genuanceerd en hangt sterk af van content type en bitrate. Op het hoogste niveau wint JPEG XL de belangrijkste vergelijkingen in de praktijk.

Tegenover JPEG

De winst is enorm. JPEG XL behaalt een visueel verliesvrije kwaliteit bij ongeveer 1,2 bits per pixel. JPEG heeft daar 2,4 bpp voor nodig. Een 2:1 verbetering. De DebugBear benchmark van een foto van 990 KB toonde JPEG XL op 472 KB (52% besparing). WebP zat op 700 KB en AVIF op 507 KB. Tests van Cloudinary met 40.000+ afbeeldingen lieten zien dat JPEG XL bij effort 6 bestanden produceerde die 20% kleiner waren dan AVIF. Tegelijkertijd was het encoderen 2,5 keer sneller.

Tegenover AVIF

De vergelijking is afhankelijk van de bitrate. Bij lage bitrates onder 0,4 bpp (zware compressie) verslaat AVIF JPEG XL. Het produceert vloeiendere afbeeldingen met minder artefacten. Bij gemiddelde tot hoge bitrates (0,4 bpp en hoger), waar de meeste webfotografie zich bevindt, wint JPEG XL consequent op detailbehoud en getrouwheid. Een AVIF-vergelijkingsstudie van Google toonde aan dat 9 van de 13 kwaliteitsstatistieken in het voordeel van JPEG XL uitvielen bij praktische instellingen voor de encodersnelheid. Het snelheidsverschil bij encoding is enorm. AVIF (via libaom) is een orde van grootte trager dan JPEG XL bij single-threaded encoding. Op de traagste instellingen van AVIF (~0,5 Mpx/s) evenaart het de compressiedichtheid van de op één na snelste instelling van JPEG XL op 52 Mpx/s. Een snelheidsverschil van een factor 100.

Tegenover WebP

JPEG XL wint overtuigend. WebP is beperkt tot 8-bit kleurdiepte, 4:2:0 chroma subsampling in lossy modus en een maximale resolutie van 16.383 x 16.383 pixels. JPEG XL ondersteunt tot 32 bit per kanaal (integer of floating point), resoluties van meer dan 1 miljard pixels per zijde, en heeft geen beperking voor chroma subsampling.

Content type maakt uit

Voor specifieke content types lieten de DebugBear benchmarks een meer gemengd beeld zien. AVIF won bij logo's (2 KB versus JXL's 6 KB) en afbeeldingen met transparantie (18 KB versus 63 KB). JPEG XL won bij foto's (472 KB versus 507 KB) en geanimeerde content. Daar behaalde het 99% compressie (14 KB van een 1,3 MB GIF, versus de 56 KB van AVIF). Deze resultaten gebruikten de standaardinstellingen van Cloudinary. Ze representeren dus typische in plaats van geoptimaliseerde outputs.

Vergelijking van features

Twee features die geen enkel ander formaat kan evenaren

De strategisch belangrijkste features van JPEG XL zijn progressive decoding en lossless JPEG transcoding. Geen enkele concurrent biedt deze aan.

Progressive decoding

Progressive decoding verandert fundamenteel hoe afbeeldingen laden. JPEG XL-bestanden zijn altijd minimaal 8x8 progressief. Het DC (low frequency) frame wordt altijd als eerste gecodeerd. Met slechts ~1% van de bestandsdata gedownload verschijnt er een bruikbare preview van de volledige afbeelding. Vergelijk dat met progressive JPEG. Die heeft 10 tot 15% nodig voor zijn eerste scan. Belangrijker nog, JPEG XL ondersteunt saliency ordered progression. Machine learning modellen kunnen de visueel belangrijkste regio's identificeren (gezichten in portretten, productdetails in e-commerce) en deze regio's zo encoderen dat ze als eerste aankomen. De decoder vlakt de randen af tussen voltooide en nog ladende regio's.

Dit creëert een andere rendering tijdlijn. AVIF vereist de volledige gecomprimeerde afbeelding voordat decoding kan beginnen. De totale tijd is gelijk aan de downloadtijd plus de decodertijd, na elkaar. JPEG XL overlapt overdracht en decoding. De gebruiker ziet dus veel sneller betekenisvolle content. Cloudinary merkt op dat de progressieve rendering van JPEG XL de noodzaak voor aparte Low Quality Image Placeholder (LQIP) bestanden elimineert. Dit verwijdert overbodige bytes volledig. Het is echter vermeldenswaard dat de huidige implementatie van Safari geen progressive decoding ondersteunt. Dit beperkt dit voordeel tot toekomstige implementaties in Chrome en Firefox.

Lossless JPEG transcoding

Lossless JPEG transcoding is de sleeper feature van JPEG XL. Het formaat kan direct de DCT-blokcoëfficiënten van JPEG kopiëren naar zijn eigen VarDCT-blokken. Het verbetert alleen de entropy coding. Het resultaat: ~20% gemiddelde reductie in bestandsgrootte (bereik: 13 tot 22%). Hierbij is het originele JPEG-bestand bit voor bit reconstrueerbaar uit het JXL-bestand. Geen enkel ander formaat kan dit. Transcoderen naar WebP of AVIF vereist decoding naar pixels en her-encoding. Dit veroorzaakt generation loss. De DICOM API van Google Cloud Platform gebruikt deze mogelijkheid al om bestandsgroottes van medische afbeeldingen met 20% te verkleinen.

Op web-schaal zouden de bandbreedtebesparingen enorm zijn als alle huidige JPEG's lossless naar JXL getranscodeerd werden. De JPEG XL-community schat de energiebesparing in op het equivalent van het voorzien van stroom voor ~487.000 Amerikaanse huishoudens gedurende een uur per dag.

Wat dit betekent voor Core Web Vitals

JPEG XL beïnvloedt elke Core Web Vitals metriek via verschillende mechanismen. De relatie is genuanceerder dan "kleinere bestanden = betere scores".

LCP (Largest Contentful Paint)

LCP profiteert van twee elkaar versterkende effecten. Ten eerste reduceren kleinere bestandsgroottes de Resource Load Duration. De downloadfase. Een reductie van 52% ten opzichte van JPEG betekent dat de hero image ongeveer twee keer zo snel aankomt op verbindingen met beperkte bandbreedte. Ten tweede decodeert JPEG XL sneller dan AVIF. Dit reduceert de Element Render Delay. De complexe, van video codecs afgeleide decoding van AVIF kan zorgen voor significante CPU overhead op mobiele apparaten. Een kleinere AVIF die sneller downloadt, kan daar deels teniet worden gedaan door een langere decodertijd. De decoding snelheid van JPEG XL tot wel 132 Mpx/s en de SIMD-optimalisatie minimaliseren deze bottleneck. Echter, LCP wordt gemeten wanneer de afbeelding volledig is gerenderd. Progressive decoding verbetert de LCP timestamp dus niet direct. Het verbetert de waargenomen performance. Dat is belangrijk voor de UX, zelfs als het de metriek niet verandert. Als JPEG XL je LCP afbeeldingsformaat is, preload deze dan zodat de browser het zo vroeg mogelijk ontdekt.

CLS (Cumulative Layout Shift)

CLS maakt het formaat niet uit. Alle formaten profiteren evenveel van expliciete width en height attributen. JPEG XL codeert afmetingen wel in vroege headers. Dit zou browsers theoretisch kunnen helpen om sneller ruimte toe te wijzen. De praktische impact is echter verwaarloosbaar vergeleken met het simpelweg instellen van de dimensies in HTML.

INP (Interaction to Next Paint)

INP kan worden beïnvloed door zware decoding van de afbeelding op de main thread. De snellere decoding en SIMD-optimalisatie van JPEG XL zorgen voor minder main thread blocking dan bij AVIF. Toch worden beide formaten in moderne browsers doorgaans van de main thread af gedecodeerd.

Impact in de praktijk

Volgens de 2025 Web Almanac is JPEG nog steeds goed voor 57% van de LCP-afbeeldingen op zowel mobiel als desktop. WebP is gegroeid naar 11%. Een stijging van 4 procentpunt ten opzichte van 2024. AVIF staat op slechts 0,7%. JPEG XL wordt nog niet eens gemeten. De mediane webpagina laadt 19 afbeeldingen op mobiel met een totaal gewicht van 911 KB. Het converteren daarvan van JPEG naar JPEG XL zou grofweg 450 tot 550 KB per pagina besparen. Bij een mediaan gewicht van afbeeldingen op desktop van 1.058 KB naderen de besparingen 500 tot 630 KB.

Op sites die door CoreDash worden gemonitord, laten pagina's die afbeeldingen in moderne formaten (AVIF of WebP) serveren 81% goede LCP-scores zien. Dit vergeleken met 64% voor pagina's die nog uitsluitend op JPEG vertrouwen. Naarmate JPEG XL bredere browserondersteuning krijgt, zou de kloof verder moeten groeien. Het monitoren van je Real User Monitoring data na het inschakelen van JXL-levering vertelt je precies hoeveel echte gebruikers ervan profiteren.

JPEG XL vandaag serveren met de juiste fallbacks

De implementatie vereist een gelaagde strategie: het <picture> element voor HTML-afbeeldingen, server-side content negotiation voor CSS en dynamisch gerefereerde afbeeldingen, en CDN-automatisering waar beschikbaar.

Het picture element

Het <picture> element biedt de schoonste client-side aanpak. Browsers evalueren <source> elementen van boven naar beneden en gebruiken het eerste ondersteunde formaat:

<picture>
  
  <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>

Als deze afbeelding je hero en het waarschijnlijke LCP-element is, verwijder dan loading="lazy" en zet de fetchpriority op high. Gebruik nooit lazy loading voor je LCP-afbeelding.

Voor responsive afbeeldingen heeft elke source zijn eigen srcset met width descriptors nodig. Dit creëert een combinatorische explosie van 12+ varianten per afbeelding (3 of 4 formaten x 3 of 4 groottes). Hier wordt CDN-automatisering essentieel.

Server-side content negotiation

Server-side content negotiation inspecteert de Accept header. Safari 17+ verstuurt image/jxl in de Accept header. De Nginx-configuratie koppelt dit aan bestandsextensies:

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

Het cruciale detail: neem altijd Vary: Accept op in de response header. Zo slaan CDNs en proxy caches aparte varianten per formaat op. Zonder dit zal een gecachete JXL response geserveerd worden aan browsers die het niet kunnen decoderen.

CDN-ondersteuning

CDN-ondersteuning is ongelijkmatig. Cloudinary biedt volledige JPEG XL ondersteuning via zijn f_auto parameter. Niet verrassend, aangezien Cloudinary het formaat mede heeft gecreëerd en al ongeveer 1 miljard JPEG XL-afbeeldingen per dag levert. Fastly's Image Optimizer voegde in juli 2024 volledige JPEG XL ondersteuning toe. Ze gebruiken encoding effort 3 met 4 threads en claimen ~60% besparing ten opzichte van JPEG. Cloudflare ondersteunt, ondanks grote vraag vanuit de community, geen JPEG XL conversie in zijn Image Resizing product. Het kan wel JXL-varianten van je origin cachen via Vary: Accept, maar kan ze niet genereren. Als je Cloudflare gebruikt, bekijk dan onze gids over het configureren van Cloudflare voor Core Web Vitals voor de instellingen die wel helpen. AWS CloudFront, Akamai en Azure hebben geen native JPEG XL ondersteuning.

Tooling

Tooling voor het genereren van JPEG XL-bestanden centreert zich rond cjxl uit de libjxl referentie-implementatie. Belangrijke parameters: -d voor distance (0 = lossless, 1.0 tot 2.0 voor webkwaliteit lossy), -e voor effort (1 tot 9, standaard 7), en -p voor progressive encoding. Bij JPEG-inputs voert cjxl input.jpg output.jxl standaard lossless transcoding uit. Het eenvoudigst mogelijke migratiepad. ImageMagick, libvips (sinds 8.11) en Photoshop v25 ondersteunen JXL ook. Echter, sharp (de Node.js afbeeldingsbibliotheek achter Next.js) heeft sinds v0.31.3 experimentele JXL-ondersteuning, maar de prebuilt binaries die via npm gedistribueerd worden, bevatten de JXL-codec niet. Je zou libvips zelf moeten compileren met libjxl ondersteuning. De maintainer heeft het verzoek gesloten voor prebuilt JXL-binaries. Dit betekent dat Next.js out of the box geen praktische JPEG XL ondersteuning heeft. WordPress core ondersteuning wordt bijgehouden als ticket #52788. De echte blocker is echter dat de GD-extensie van PHP geen JPEG XL ondersteunt. PHP 8.5 (november 2025) mist nog steeds GD-ondersteuning voor JXL.

De Halloween-beslissing en de terugdraaiing na drie jaar

De politieke geschiedenis van JPEG XL in Chrome is een case study over de macht van browserleveranciers over webstandaarden. Het begrijpen hiervan is belangrijk omdat het onthult welke krachten bepalen welke technologieën gebruikers bereiken.

Op 31 oktober 2022 kondigde Jim Bankoski van het Chrome-team van Google de verwijdering aan van de experimentele JPEG XL ondersteuning. Dit werd al snel omgedoopt tot de "Halloween-beslissing". De opgegeven redenen waren vierledig: experimentele flags zouden niet voor onbepaalde tijd moeten blijven bestaan; onvoldoende interesse vanuit het ecosysteem; onvoldoende incrementele voordelen ten opzichte van bestaande formaten; en de last van het onderhoud. Bankoski suggereerde WebAssembly als "een geweldige weg vooruit" voor wie JPEG XL in Chrome wilde.

De tegenreactie was onmiddellijk en hield aan. De Chromium issue werd de op één na meest van een ster voorziene in de hele geschiedenis van het project, met ruim 1.000 upvotes en reacties van vertegenwoordigers van Intel, Adobe, Meta, Shopify, The Guardian, Flickr en de Krita Foundation. Jon Sneyers, de mede-bedenker van JPEG XL bij Cloudinary, publiceerde een gedetailleerde technische weerlegging ("The Case for JPEG XL"). Hij toonde aan dat de gepubliceerde vergelijkingstests van Google gebruik maakten van buggy JPEG XL implementaties en metrics met een bias naar AVIF. De Free Software Foundation noemde de beslissing van Google bewijs dat Google Chrome de scheidsrechter van webstandaarden was geworden. Ze beschuldigden het bedrijf ervan uit eigenbelang te handelen. AVIF stamt namelijk af van AV1, ontwikkeld door de Alliance for Open Media die door Google is mede-opgericht.

De ironie ontging waarnemers niet: Google had JPEG XL zelf mede-gecreëerd via hun PIK-project. Dit maakte de beslissing om het uit Chrome te verwijderen des te verwarrender. Toen JPEG XL werd voorgesteld voor Interop 2024, ontving het 646 reacties uit de community. 4,5 keer zoveel als het voorstel op de tweede plaats. En het werd afgewezen met als enige verklaring "gebrek aan consensus".

Wat de beslissing uiteindelijk terugdraaide, was het momentum in het ecosysteem dat de afwezigheid van Chrome onhoudbaar maakte. De release van Safari 17 door Apple met JPEG XL-ondersteuning in september 2023 was de eerste grote doorbraak. Mozilla verhoogde de druk door te verschuiven van "negatief" naar "neutraal" en vervolgens naar de actieve bereidheid om het te implementeren (met een Rust decoder). De aankondiging van de PDF Association in oktober 2025 dat JPEG XL het geprefereerde HDR-formaat voor PDF is, was mogelijk het omslagpunt. De ingebouwde PDF-viewer van Chrome zou JXL-ondersteuning nodig hebben om compliant te blijven. Op 21 november 2025 plaatste Rick Byers (Chrome Architecture Tech Lead) de ommezwaai online. Hij verwelkomde bijdragen om een performante en memory-safe JPEG XL decoder in Chromium te integreren. In januari 2026 werd de op Rust gebaseerde jxl-rs decoder samengevoegd. Chrome 145 leverde deze achter een flag mee in februari 2026.

Conclusie: sla kwaliteitsbronnen op, converteer on demand

JPEG XL is technisch gezien het beste algemene afbeeldingsformaat dat beschikbaar is. Betere compressie dan AVIF bij praktische encodeersnelheden, progressive decoding die geen enkele concurrent biedt, en lossless JPEG transcoding die direct 20% besparing oplevert zonder kwaliteitsverlies. De politieke obstakels die de adoptie drie jaar lang blokkeerden, lossen op: Chrome heeft de code in de tree, Firefox integreert actief dezelfde Rust decoder en Safari biedt al ondersteuning sinds 2023.

De praktische weg vooruit is: sla het bronmateriaal in de hoogst mogelijke kwaliteit op en laat je delivery pipeline de formaatconversie afhandelen. Bewaar lossless PNG's of master JPEG's van hoge kwaliteit als je originelen. Gebruik een CDN met automatische format negotiation: Cloudinary's f_auto, Fastly Image Optimizer of Cloudflare Polish inspecteert de Accept header van de browser en serveert JXL, AVIF, WebP of JPEG zonder dat je vooraf ook maar één variant hoeft te genereren. Als je zelf host, zet dan on-demand conversie op met libvips of ImageMagick achter een server-side cache. Je converteert eenmalig per formaat bij het eerste verzoek, in plaats van vooraf in batch vier varianten per afbeelding te genereren. De lossless transcoding van JPEG XL past perfect in dit model. Je bestaande JPEG's zijn de bron, en het converteren naar JXL is effectief on-demand conversie met nul kwaliteitsverlies. De open vraag is niet óf JPEG XL brede browserondersteuning gaat krijgen, maar wannéér Chrome de flag standaard van uit naar aan zet. Het enige eerlijke antwoord is dat er geen tijdlijn is aangekondigd. De driejarige verbanning van het formaat uit Chrome zou enthousiasme moeten temperen met pragmatisme: serveer het waar het ondersteund wordt, gebruik een graceful fallback voor de rest, en laat het CDN of de conversiepijplijn de rest afhandelen.