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

JPEG XL komt eindelijk terug naar Chrome

Na drie jaar controverse is JPEG XL teruggekeerd naar Chromium. Chrome 145, uitgebracht begin februari 2026, wordt geleverd met een JPEG XL decoder. Nog steeds achter een flag, maar voor het eerst sinds de omstreden verwijdering eind 2022 functioneel aanwezig in de codebase. Dit is belangrijk omdat JPEG XL op de meeste technische vlakken aantoonbaar superieur is aan elk bestaand web-beeldformaat: 50 tot 60% kleiner dan JPEG, 10 tot 15% betere compressie dan AVIF bij gelijkwaardige codeersnelheden, en het enige moderne formaat met echte progressieve decodering. Voor webperformance-professionals vertegenwoordigt het traject van het formaat — van ISO-standaard naar Chrome-verbanning naar wederopstanding — zowel een technische kans als een waarschuwend verhaal over de macht van browserleveranciers over het webplatform.

Laatst beoordeeld door Arjen Karel op februari 2026

Browserondersteuning in februari 2026 is slechts 12%

De effectieve wereldwijde browserondersteuning van JPEG XL ligt op ongeveer 12%, bijna volledig afkomstig van Safari-gebruikers. Dat aantal staat op het punt te veranderen. Maar de tijdlijn blijft onzeker.

Safari 17+ (uitgebracht in september 2023) biedt native JPEG XL decodering op macOS Sonoma, iOS 17, iPadOS 17, watchOS en visionOS. De implementatie van Apple delegeert de decodering naar het beeld-framework op OS-niveau, wat betekent dat het overal werkt waar Safari draait. De ondersteuning van Safari is echter expliciet gedeeltelijk: geen ondersteuning voor animaties en geen progressieve decodering. Twee van de meest onderscheidende kenmerken van JPEG XL. Dit is een aanzienlijke 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, die de eerdere C++ libjxl-implementatie vervangt. De decoder zit achter chrome://flags/#enable-jxl-image-format en is niet standaard ingeschakeld. Google heeft duidelijke voorwaarden gesteld om het standaard in te schakelen: een commitment aan langdurig onderhoud en het voldoen aan standaard lanceercriteria. De Rust-decoder presteert momenteel binnen 15 tot 25% van de snelheid van de C++ referentie-implementatie, met 26 optimalisatie-PR's die alleen al in december 2025 zijn samengevoegd. Bevestigde werkende mogelijkheden zijn onder meer ICC-kleurprofielen, animaties, alpha/transparantie, breed kleurbereik (Display P3) en HDR (PQ/HLG).

Om JPEG XL vandaag in Chrome te proberen, navigeert u naar chrome://flags/#enable-jxl-image-format en stelt u dit in op Enabled. Start Chrome opnieuw op. Elke site die al JXL-afbeeldingen serveert (bijvoorbeeld klanten van Cloudinary), begint deze aan uw browser te leveren.

Firefox blijft het verst achter. Het formaat is alleen beschikbaar in Firefox Nightly achter de image.jxl.enabled flag. Cruciaal is dat de decoder-code helemaal niet wordt gecompileerd in stabiele builds, dus de flag doet niets in de release-versie van Firefox. Het standpunt van Mozilla is verschoven van "negatief" naar "neutraal". De jxl-rs Rust-decoder is geland in Firefox Nightly (gericht op Firefox 149), maar er blijven zes blokkades over voordat het in de stabiele versie kan worden uitgebracht: ondersteuning voor kleurprofielen, progressieve decodering, HDR, profiler-integratie, compilatie in release-builds en het slagen voor Web Platform Tests. Er bestaat geen tijdlijn voor stabiele ondersteuning.

Edge bevat, als een Chromium-derivaat, waarschijnlijk de jxl-rs code uit Chrome 145, maar heeft de ondersteuning voor JPEG XL niet officieel aangekondigd of gedocumenteerd. De release-notities van Edge 145 maken er geen melding van.

Interop 2026 heeft JPEG XL opgenomen als een onderzoeksgebied (niet een volledig focusgebied), waarbij Apple, Google, Microsoft en Mozilla allemaal deelnemen. Dit duidt op de intentie van verschillende leveranciers om uitgebreide testsuites te bouwen, wat doorgaans voorafgaat aan een bredere uitrol.

Hoe JPEG XL elk alternatief overtreft. En waar niet

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

Tegenover JPEG

De winst is spectaculair. JPEG XL bereikt visueel verliesvrije kwaliteit bij ongeveer 1,2 bits per pixel, waar JPEG 2,4 bpp vereist. Een verbetering van 2:1. De DebugBear-benchmark van een foto van 990 KB toonde JPEG XL op 472 KB (52% besparing), vergeleken met WebP op 700 KB en AVIF op 507 KB. Tests van Cloudinary van meer dan 40.000 afbeeldingen wezen uit dat JPEG XL bij 'effort 6' bestanden produceerde die 20% kleiner waren dan AVIF, terwijl het coderen 2,5x sneller ging.

Tegenover AVIF

De vergelijking is afhankelijk van de bitrate. Bij lage bitrates onder 0,4 bpp (zware compressie) presteert AVIF beter dan JPEG XL. Het produceert gladdere beelden met minder artefacten. Bij gemiddelde tot hoge bitrates (0,4 bpp en hoger), waar de meeste webfotografie zich bevindt, wint JPEG XL consequent op het gebied van detailbehoud en getrouwheid. Google's eigen AVIF-vergelijkingsstudie toonde aan dat 9 van de 13 kwaliteitsmetrieken in het voordeel van JPEG XL uitvielen bij praktische instellingen voor de codeersnelheid. Het gat in de codeersnelheid is enorm: AVIF (via libaom) is een orde van grootte trager dan JPEG XL bij single-threaded codering. Bij de traagste instellingen van AVIF (~0,5 Mpx/s) komt het overeen met de compressiedichtheid van de op één na snelste instelling van JPEG XL bij 52 Mpx/s. Een snelheidsverschil van 100x.

Tegenover WebP

JPEG XL wint overtuigend. WebP is beperkt tot 8-bits 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-bits per kanaal (integer of floating point), resoluties van meer dan 1 miljard pixels per zijde en heeft geen beperkingen voor chroma subsampling.

Type inhoud is belangrijk

Voor specifieke soorten inhoud lieten de DebugBear-benchmarks een meer gemengd beeld zien. AVIF won bij logo's (2 KB vs JXL's 6 KB) en afbeeldingen met transparantie (18 KB vs 63 KB), terwijl JPEG XL won bij foto's (472 KB vs 507 KB) en geanimeerde inhoud, waar het een compressie van 99% bereikte (14 KB van een GIF van 1,3 MB, tegenover 56 KB voor AVIF). Deze resultaten gebruikten de standaardinstellingen van Cloudinary en vertegenwoordigen dus typische in plaats van geoptimaliseerde outputs.

Functievergelijking

Twee functies die geen enkel ander formaat kan evenaren

De strategisch belangrijkste kenmerken van JPEG XL zijn progressieve decodering en lossless JPEG transcodering. Geen enkele concurrent biedt beide aan.

Progressieve decodering

Progressieve decodering verandert fundamenteel hoe afbeeldingen laden. JPEG XL-bestanden zijn altijd minimaal 8x8 progressief; het DC (lage frequentie) frame wordt altijd als eerste gecodeerd. Met slechts ~1% van de bestandsgegevens gedownload verschijnt er een bruikbare preview van de volledige afbeelding. Vergelijk dat met progressieve JPEG, die 10 tot 15% nodig heeft voor de eerste scan. Belangrijker nog is dat JPEG XL saliency ordered progression ondersteunt: machine learning-modellen kunnen de visueel belangrijkste regio's identificeren (gezichten in portretten, productdetails in e-commerce) en die regio's zo coderen dat ze als eerste aankomen. De decoder verzacht de overgangen tussen voltooide en nog ladende regio's.

Dit creëert een andere rendering-tijdlijn. AVIF vereist de volledige gecomprimeerde afbeelding voordat de decodering kan beginnen: de totale tijd is de som van de downloadtijd en de decodeertijd, na elkaar. JPEG XL overlapt overdracht en decodering, zodat de gebruiker veel eerder betekenisvolle inhoud ziet. Cloudinary heeft opgemerkt dat de progressieve weergave van JPEG XL de noodzaak voor afzonderlijke Low Quality Image Placeholder (LQIP) bestanden elimineert, waardoor overbodige bytes volledig worden verwijderd. Het is echter de moeite waard om op te merken dat de huidige implementatie van Safari geen progressieve decodering ondersteunt, wat dit voordeel beperkt tot toekomstige Chrome- en Firefox-implementaties.

Lossless JPEG transcodering

Lossless JPEG transcodering is de 'sleeper feature' van JPEG XL. Het formaat kan de DCT-blokcoëfficiënten van JPEG rechtstreeks kopiëren naar zijn eigen VarDCT-blokken, waarbij alleen de entropiecodering wordt verbeterd. Het resultaat: een gemiddelde bestandsverkleining van ~20% (bereik: 13 tot 22%), waarbij het originele JPEG-bestand bit voor bit reconstrueerbaar is vanuit het JXL-bestand. Geen enkel ander formaat kan dit. Transcoderen naar WebP of AVIF vereist decodering naar pixels en opnieuw coderen, wat leidt tot generatieverlies. De DICOM API van Google Cloud Platform gebruikt deze mogelijkheid al om de bestandsgrootte van medische beelden met 20% te verkleinen.

Op web-schaal, als alle huidige JPEG's lossless zouden worden getranscodeerd naar JXL, zou de bandbreedtebesparing enorm zijn. De JPEG XL-gemeenschap schat de energiebesparing gelijk aan het stroomverbruik van ~487.000 Amerikaanse huishoudens gedurende één uur per dag.

Wat dit betekent voor Core Web Vitals

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

LCP (Largest Contentful Paint)

LCP profiteert van twee elkaar versterkende effecten. Ten eerste verminderen kleinere bestanden de Resource Load Duration. De downloadfase. Een vermindering van 52% ten opzichte van JPEG betekent dat de hero-afbeelding ongeveer twee keer zo snel binnenkomt op verbindingen met beperkte bandbreedte. Ten tweede decodeert JPEG XL sneller dan AVIF, wat de Element Render Delay vermindert. De complexe decodering van AVIF, afgeleid van videocodecs, kan aanzienlijke CPU-overhead veroorzaken op mobiele apparaten, waar een kleinere AVIF die sneller downloadt gedeeltelijk teniet kan worden gedaan door een langere decodeertijd. De decodeersnelheid van JPEG XL tot 132 Mpx/s en SIMD-optimalisatie minimaliseren deze bottleneck. Echter, LCP wordt gemeten wanneer de afbeelding volledig is gerenderd, dus progressieve decodering verbetert de LCP-timestamp niet direct. Het verbetert de waargenomen prestatie, wat belangrijk is voor de user experience, zelfs als het de metriek niet verplaatst. Als JPEG XL het formaat van uw LCP-afbeelding is, preload het dan zodat de browser het zo vroeg mogelijk ontdekt.

CLS (Cumulative Layout Shift)

CLS geeft niets om het formaat. Alle formaten profiteren in gelijke mate van expliciete width- en height-attributen. JPEG XL codeert wel informatie over de afmetingen in de vroege headers, wat browsers theoretisch zou kunnen helpen om sneller ruimte toe te wijzen, maar de praktische impact hiervan is verwaarloosbaar vergeleken met het simpelweg instellen van afmetingen in HTML.

INP (Interaction to Next Paint)

INP kan worden beïnvloed door zware beelddecodering op de main thread. De snellere decodering en SIMD-optimalisatie van JPEG XL betekenen minder blokkering van de main thread dan bij AVIF, hoewel beide formaten in moderne browsers doorgaans buiten de main thread worden gedecodeerd.

Impact in de praktijk

Volgens de 2025 Web Almanac is JPEG nog steeds verantwoordelijk voor 57% van de LCP-afbeeldingen op zowel mobiel als desktop. WebP is gegroeid naar 11%, een stijging van 4 procentpunten ten opzichte van 2024. AVIF blijft steken op slechts 0,7%. JPEG XL wordt nog niet eens gemeten. De gemiddelde webpagina laadt 19 afbeeldingen op mobiel met een totaal gewicht van 911 KB. Het converteren daarvan van JPEG naar JPEG XL zou ongeveer 450 tot 550 KB per pagina besparen. Bij een gemiddeld gewicht van afbeeldingen op desktop van 1.058 KB nadert de besparing 500 tot 630 KB.

Op sites die worden gemonitord door CoreDash tonen pagina's die afbeeldingen serveren in moderne formaten (AVIF of WebP) 81% goede LCP-scores, vergeleken met 64% voor pagina's die nog uitsluitend op JPEG vertrouwen. Naarmate JPEG XL bredere browserondersteuning krijgt, zou het gat verder moeten groeien. Het monitoren van uw Real User Monitoring-data na het inschakelen van JXL-levering zal u precies vertellen hoeveel voordeel echte gebruikers hiervan hebben.

JPEG XL vandaag serveren met de juiste fallbacks

Implementatie vereist een gelaagde strategie: het <picture> element voor HTML-afbeeldingen, content-negotiatie aan de serverzijde voor CSS en dynamisch gerefereerde afbeeldingen, en CDN-automatisering waar beschikbaar.

Het picture element

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

<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="Beschrijving" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Als deze afbeelding uw hero-afbeelding is en de waarschijnlijke LCP element, verwijder dan loading="lazy" en stel de fetchpriority in op high. U moet uw LCP-afbeelding nooit lazy loaden.

Voor responsive images heeft elke bron zijn eigen srcset met breedte-descriptors nodig. Dit creëert een explosieve toename van 12+ varianten per afbeelding (3 of 4 formaten x 3 of 4 groottes). Dit is waar CDN-automatisering essentieel wordt.

Server-side content-negotiatie

Server-side content-negotiatie inspecteert de Accept-header. Safari 17+ verzendt image/jxl in zijn Accept-header. Nginx-configuratie koppelt dit aan bestandsextensies:

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

Het cruciale detail: voeg altijd Vary: Accept toe in de respons-header, zodat CDN's en proxy-caches afzonderlijke varianten per formaat opslaan. Zonder dit wordt een gecachte JXL-respons geserveerd aan browsers die deze niet kunnen decoderen.

CDN-ondersteuning

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

Tooling

Tooling voor het genereren van JPEG XL-bestanden draait om cjxl uit de libjxl-referentie-implementatie. Belangrijke parameters: -d voor afstand (0 = lossless, 1.0 tot 2.0 voor webkwaliteit lossy), -e voor inspanning (1 tot 9, standaard 7), en -p voor progressieve codering. Voor JPEG-inputs voert cjxl input.jpg output.jxl standaard lossless transcodering uit. Het eenvoudigst mogelijke migratiepad. ImageMagick, libvips (sinds 8.11) en Photoshop v25 ondersteunen ook JXL. Echter, sharp (de Node.js-beeldlibrary die Next.js aandrijft) heeft experimentele JXL-ondersteuning sinds v0.31.3, maar de vooraf gebouwde binaries die via npm worden gedistribueerd, bevatten de JXL-codec niet. U zou libvips zelf moeten compileren met libjxl-ondersteuning, en de beheerder heeft het verzoek voor vooraf gebouwde JXL-binaries gesloten. Dit betekent dat Next.js 'out of the box' geen praktische ondersteuning voor JPEG XL heeft. WordPress core ondersteuning wordt gevolgd als ticket #52788, maar de echte blokkade is dat PHP's GD-extensie geen JPEG XL ondersteunt. PHP 8.5 (november 2025) ontbeert nog steeds GD-ondersteuning voor JXL.

Het Halloween-besluit en de ommekeer na drie jaar

De politieke geschiedenis van JPEG XL in Chrome is een schoolvoorbeeld van de macht van browserleveranciers over webstandaarden. Het is belangrijk dit te begrijpen, omdat het de krachten onthult die bepalen welke technologieën gebruikers bereiken.

Op 31 oktober 2022, in wat al snel het "Halloween-besluit" werd genoemd, kondigde Jim Bankoski van Google's Chrome-team de verwijdering aan van de experimentele ondersteuning voor JPEG XL. De opgegeven redenen waren viervoudig: experimentele flags moeten niet voor onbepaalde tijd blijven bestaan; onvoldoende interesse in het ecosysteem; onvoldoende incrementele voordelen ten opzichte van bestaande formaten; en onderhoudslast. Bankoski suggereerde WebAssembly als "een uitstekend pad voorwaarts" voor degenen die JPEG XL in Chrome wilden.

De reactie was onmiddellijk en aanhoudend. Het Chromium-issue werd het op één na meest van een ster voorziene issue in de hele geschiedenis van het project, met meer dan 1.000 upvotes en commentaren van vertegenwoordigers van Intel, Adobe, Meta, Shopify, The Guardian, Flickr en de Krita Foundation. Jon Sneyers, de mede-creator van JPEG XL bij Cloudinary, publiceerde een gedetailleerde technische weerlegging ("The Case for JPEG XL") waarin hij aantoonde dat de door Google gepubliceerde vergelijkingstests gebruikmaakten van gebrekkige JPEG XL-implementaties en metrieken die bevooroordeeld waren richting AVIF. De Free Software Foundation noemde het besluit van Google het bewijs dat Google Chrome de scheidsrechter van webstandaarden was geworden en beschuldigde het bedrijf ervan te handelen uit eigenbelang. AVIF is immers afgeleid van AV1, ontwikkeld door de Alliance for Open Media, waarvan Google mede-oprichter is.

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

Wat het besluit uiteindelijk deed omslaan, was het momentum in het ecosysteem dat de afwezigheid van Chrome onhoudbaar maakte. Het feit dat Apple Safari 17 in september 2023 met ondersteuning voor JPEG XL uitbracht, was de eerste grote doorbraak. Mozilla verschoof van "negatief" naar "neutraal" en vervolgens naar een actieve bereidheid om te implementeren (met een Rust-decoder), wat de druk verhoogde. De PDF Association die in oktober 2025 JPEG XL aankondigde als het geprefereerde HDR-formaat voor PDF was mogelijk het omslagpunt. Chrome's ingebouwde PDF-viewer zou JXL-ondersteuning nodig hebben om compliant te blijven. Op 21 november 2025 plaatste Rick Byers (Chrome Architecture Tech Lead) de ommekeer en verwelkomde hij bijdragen om een performante en geheugenveilige JPEG XL-decoder in Chromium te integreren. Tegen januari 2026 was de op Rust gebaseerde jxl-rs-decoder samengevoegd, en Chrome 145 leverde deze in februari 2026 achter een flag.

Conclusie: sla kwalitatieve bronnen op, converteer on-demand

JPEG XL is technisch het beste beeldformaat voor algemeen gebruik dat beschikbaar is. Betere compressie dan AVIF bij praktische codeersnelheden, progressieve decodering die geen enkele concurrent biedt, en lossless JPEG transcodering die een onmiddellijke besparing van 20% oplevert zonder enig kwaliteitsverlies. De politieke obstakels die de adoptie drie jaar lang blokkeerden, lossen op: Chrome heeft code in de tree, Firefox integreert actief dezelfde Rust-decoder en Safari biedt al sinds 2023 ondersteuning.

Het praktische pad voorwaarts is om bronmateriaal van de hoogste kwaliteit op te slaan en uw leveringspijplijn de formaatconversie te laten afhandelen. Bewaar lossless PNG's of master-JPEG's van hoge kwaliteit als uw originelen. Gebruik een CDN met automatische content-negotiatie: Cloudinary's f_auto, Fastly Image Optimizer of Cloudflare Polish zullen de Accept-header van de browser inspecteren en JXL, AVIF, WebP of JPEG serveren zonder dat u vooraf een enkele variant hoeft te genereren. Als u zelf host, stel dan on-demand conversie in met libvips of ImageMagick achter een server-side cache, waarbij u eenmaal per formaat converteert bij het eerste verzoek in plaats van vooraf batchgewijs vier varianten per afbeelding te genereren. De lossless transcodering van JPEG XL past perfect in dit model: uw bestaande JPEG's zijn de bron, en het converteren ervan naar JXL is in feite on-demand conversie zonder kwaliteitsverlies. De openstaande vraag is niet of JPEG XL brede browserondersteuning zal krijgen, maar wanneer Chrome de flag standaard zal inschakelen. En het enige eerlijke antwoord is dat er nog geen tijdlijn is aangekondigd. De driejarige verbanning van het formaat uit Chrome zou enthousiasme moeten temperen met pragmatisme: serveer het waar ondersteund, val elegant terug op andere formaten waar nodig, en laat het CDN of de conversiepijplijn de rest afhandelen.