JPEG XL og Core Web Vitals: det du trenger å vite nå som Chrome leverer det

JPEG XL kommer endelig tilbake til Chrome

Etter tre år med kontrovers har JPEG XL returnert til Chromium. Chrome 145, utgitt tidlig i februar 2026, leveres med en JPEG XL-dekoder. Fortsatt bak et flagg, men funksjonelt til stede i kodebasen for første gang siden den kontroversielle fjerningen sent i 2022. Dette er viktig fordi JPEG XL er beviselig overlegen alle eksisterende bildeformater for nett på de fleste tekniske dimensjoner: 50 til 60 % mindre enn JPEG, 10 til 15 % bedre komprimering enn AVIF ved tilsvarende kodingshastigheter, og det eneste moderne formatet med ekte progressiv dekoding. For fagfolk innen web performance representerer formatets bane fra ISO-standard til Chrome-eksil til gjenoppstandelse både en teknisk mulighet og en advarende historie om nettleserleverandørers makt over nettplattformen.

Nettleserstøtte i februar 2026 er bare 12 %

JPEG XLs effektive globale nettleserstøtte ligger på omtrent 12 %, nesten utelukkende fra Safari-brukere. Det tallet er i ferd med å endre seg. Men tidslinjen forblir usikker.

Safari 17+ (utgitt september 2023) gir native JPEG XL-dekoding på tvers av macOS Sonoma, iOS 17, iPadOS 17, watchOS og visionOS. Apples implementering delegerer dekoding til operativsystemets bilderammeverk, noe som betyr at det fungerer overalt der Safari kjører. Safaris støtte er imidlertid eksplisitt delvis: ingen animasjonsstøtte og ingen progressiv dekoding. To av JPEG XLs mest fremtredende funksjoner. Dette er en vesentlig begrensning som undergraver formatets fulle verdiforslag på Apple-enheter.

Chrome 145 (februar 2026) gjeninnfører JPEG XL via en ren Rust-dekoder kalt jxl-rs, som erstatter den tidligere C++ libjxl-implementeringen. Dekoderen er kontrollert bak chrome://flags/#enable-jxl-image-format og er ikke aktivert som standard. Google har satt klare betingelser for standard aktivering: en forpliktelse til langsiktig vedlikehold og oppfylling av standard lanseringskriterier. Rust-dekoderen yter for tiden innenfor 15 til 25 % av referanseimplementeringens hastighet i C++, med 26 optimaliserings-PRer sammenslått i desember 2025 alene. Bekreftede fungerende funksjoner inkluderer ICC-fargeprofiler, animasjoner, alfa/transparens, bredt fargegamut (Display P3) og HDR (PQ/HLG).

Firefox ligger lengst bak. Formatet er kun tilgjengelig i Firefox Nightly bak flagget image.jxl.enabled. Kritisk nok er dekoderkoden ikke kompilert inn i stabile bygg i det hele tatt, så flagget gjør ingenting i utgivelsesversjonen av Firefox. Mozillas posisjon har endret seg fra «negativ» til «nøytral», med aktivt arbeid (Bug 1986393) for å integrere den samme jxl-rs Rust-dekoderen. Ingen tidslinje finnes for stabil støtte.

Edge, som en Chromium-avledning, inneholder sannsynligvis jxl-rs-koden fra Chrome 145, men har ikke offisielt kunngjort eller dokumentert JPEG XL-støtte. Utgivelsesnotatene for Edge 145 nevner det ikke.

Interop 2026 har inkludert JPEG XL som et undersøkelsesområde (ikke et fullt fokusområde), med Apple, Google, Microsoft og Mozilla som deltakere. Dette signaliserer intensjon på tvers av leverandører om å bygge omfattende testsuiter, noe som typisk går forut for bredere utrulling.

Hvordan JPEG XL utkonkurrerer alle alternativer. Og hvor det ikke gjør det

Historien om komprimeringseffektivitet er nyansert og avhenger sterkt av innholdstype og bitrate. På det høyeste nivået vinner JPEG XL de viktigste sammenligningene i den virkelige verden.

Mot JPEG

Gevinstene er dramatiske. JPEG XL oppnår visuelt tapsfri kvalitet ved omtrent 1,2 bits per piksel der JPEG krever 2,4 bpp. En 2:1 forbedring. DebugBear-referansetesten av et fotografi på 990 KB viste JPEG XL på 472 KB (52 % besparelse), sammenlignet med WebP på 700 KB og AVIF på 507 KB. Cloudinarys testing av over 40 000 bilder fant at JPEG XL med innsats 6 produserte filer som var 20 % mindre enn AVIF mens kodingen var 2,5 ganger raskere.

Mot AVIF

Sammenligningen er bitrateavhengig. Ved lave bitrater under 0,4 bpp (sterk komprimering) utkonkurrerer AVIF JPEG XL. Det produserer jevnere bilder med færre artefakter. Ved middels til høye bitrater (0,4 bpp og over), der det meste av nettfotografi befinner seg, vinner JPEG XL konsekvent på detaljbevaring og nøyaktighet. Googles egen AVIF-sammenligningsstudie viste at 9 av 13 kvalitetsmålinger favoriserte JPEG XL ved praktiske kodingshastighetsinnstillinger. Forskjellen i kodingshastighet er enorm: AVIF (via libaom) er en størrelsesorden langsommere enn JPEG XL i entrådet koding. Ved AVIFs tregeste innstillinger (~0,5 Mpx/s) matcher den komprimeringstettheten til JPEG XLs nest raskeste innstilling ved 52 Mpx/s. En 100 ganger hastighetsforskjell.

Mot WebP

JPEG XL vinner overlegent. WebP er begrenset til 8-bits fargedybde, 4:2:0 kromaundersampling i tapsmodus, og en maksimal oppløsning på 16 383 x 16 383 piksler. JPEG XL støtter opptil 32 bit per kanal (heltall eller flyttall), oppløsninger som overstiger 1 milliard piksler per side, og har ingen begrensning på kromaundersampling.

Innholdstype betyr noe

For spesifikke innholdstyper avslørte DebugBear-referansetestene et mer blandet bilde. AVIF vant på logoer (2 KB mot JXLs 6 KB) og transparensbilder (18 KB mot 63 KB), mens JPEG XL vant på fotografier (472 KB mot 507 KB) og animert innhold der det oppnådde 99 % komprimering (14 KB fra en 1,3 MB GIF, mot AVIFs 56 KB). Disse resultatene brukte Cloudinarys standardinnstillinger, så de representerer typiske i stedet for optimaliserte resultater.

Funksjonssammenligning

Funksjon	JPEG	WebP	AVIF	JPEG XL
Maks bitdybde	8 bit	8 bit	10/12 bit	32 bit
Progressiv dekoding	Begrenset	Nei	Nei	Avansert
Tapsfri JPEG-transkoding	N/A	Nei	Nei	Ja (~20 % besparelse)
HDR-støtte	Nei	Nei	Ja	Ja (overlegen)
Maks dimensjoner	65K x 65K	16K x 16K	65K x 65K	~1B x 1B
Animasjon	Nei	Ja	Ja	Ja
Kodingshastighet	Raskest	Rask	Svært treg	Rask
Dekodingshastighet	Rask	Moderat	Treg	Rask

To funksjoner ingen andre formater kan matche

JPEG XLs mest strategisk viktige funksjoner er progressiv dekoding og tapsfri JPEG-transkoding. Ingen konkurrent tilbyr noen av delene.

Progressiv dekoding

Progressiv dekoding endrer fundamentalt hvordan bilder lastes. JPEG XL-filer er alltid minst 8x8 progressive; DC-rammen (lavfrekvent) kodes alltid først. Med bare ~1 % av fildataene lastet ned vises en brukbar forhåndsvisning av hele bildet. Sammenlign det med progressiv JPEG, som krever 10 til 15 % for sin første skanning. Enda viktigere støtter JPEG XL saliensorientert progresjon: maskinlæringsmodeller kan identifisere de mest visuelt viktige områdene (ansikter i portretter, produktdetaljer i e-handel) og kode disse områdene til å ankomme først. Dekoderen jevner ut grensene mellom fullførte og fortsatt lastende regioner.

Dette skaper en annen gjengivelsestidslinje. AVIF krever det fullstendige komprimerte bildet før dekoding kan begynne: total tid tilsvarer nedlastingstid pluss dekodingstid, sekvensielt. JPEG XL overlapper overføring og dekoding, slik at brukeren ser meningsfylt innhold mye raskere. Cloudinary har bemerket at JPEG XLs progressive gjengivelse eliminerer behovet for separate Low Quality Image Placeholder (LQIP)-filer, og fjerner overflødige bytes fullstendig. Det er imidlertid verdt å merke seg at Safaris nåværende implementering ikke støtter progressiv dekoding, noe som begrenser denne fordelen til fremtidige Chrome- og Firefox-implementeringer.

Tapsfri JPEG-transkoding

Tapsfri JPEG-transkoding er JPEG XLs skjulte trumfkort. Formatet kan direkte kopiere JPEGs DCT-blokkkoeffisienter inn i sine egne VarDCT-blokker, og forbedrer kun entropikodingen. Resultatet: ~20 % gjennomsnittlig filstørrelsesreduksjon (område: 13 til 22 %) der den originale JPEG-filen er bit for bit rekonstruerbar fra JXL-filen. Ingen andre formater kan gjøre dette. Transkoding til WebP eller AVIF krever dekoding til piksler og ny koding, noe som forårsaker generasjonstap. Google Cloud Platforms DICOM API bruker allerede denne funksjonen til å redusere filstørrelser for medisinsk bildebehandling med 20 %.

I nettskala, hvis alle nåværende JPEG-er ble tapsfritt transkodet til JXL, ville båndbreddebesparelsene være enorme. JPEG XL-miljøet estimerer at energibesparelsene tilsvarer strømforsyning til ~487 000 amerikanske hjem i én time per dag.

Hva dette betyr for Core Web Vitals

JPEG XL påvirker hver Core Web Vitals-metrikk gjennom ulike mekanismer, og forholdet er mer nyansert enn «mindre filer = bedre resultater».

LCP (Largest Contentful Paint)

LCP drar nytte av to sammensatte effekter. For det første reduserer mindre filstørrelser Resource Load Duration. Nedlastingsfasen. En 52 % reduksjon fra JPEG betyr at heltebildet ankommer omtrent dobbelt så raskt på båndbreddebegrensede forbindelser. For det andre dekoder JPEG XL raskere enn AVIF, noe som reduserer Element Render Delay. AVIFs komplekse videokodek-avledede dekoding kan skape merkbar CPU-belastning på mobile enheter, der en mindre AVIF som lastes raskere kan bli delvis motvirket av lengre dekodingstid. JPEG XLs dekodingshastighet på opptil 132 Mpx/s og SIMD-optimalisering minimerer denne flaskehalsen. Imidlertid måles LCP når bildet er fullstendig gjengitt, så progressiv dekoding forbedrer ikke LCP-tidsstempelet direkte. Det forbedrer opplevd ytelse, noe som betyr noe for user experience selv om det ikke flytter metrikken.

CLS (Cumulative Layout Shift)

CLS bryr seg ikke om format. Alle formater drar like mye nytte av eksplisitte bredde- og høydeattributter. JPEG XL koder dimensjonsinformasjon i tidlige headere, noe som teoretisk sett kunne hjelpe nettlesere med å tildele plass raskere, men den praktiske effekten er neglisjerbar sammenlignet med å enkelt sette dimensjoner i HTML.

INP (Interaction to Next Paint)

INP kan bli påvirket av tung bildedekoding på hovedtråden. JPEG XLs raskere dekoding og SIMD-optimalisering betyr mindre blokkering av hovedtråden enn AVIF, selv om begge formater typisk dekodes utenfor hovedtråden i moderne nettlesere.

Virkelig påvirkning

Median-nettsiden i 2025 laster 19 bilder på mobil med en totalvekt på 911 KB (HTTP Archive Web Almanac 2025). Konvertering av disse fra JPEG til JPEG XL ville spare omtrent 450 til 550 KB per side. En vesentlig forbedring for brukere på begrensede nettverk. Ved median bildestørrelse på stasjonær på 1 058 KB nærmer besparelsene seg 500 til 630 KB.

Servering av JPEG XL i dag med riktige fallbacks

Implementering krever en lagdelt strategi: <picture>-elementet for HTML-bilder, tjenerside innholdsforhandling for CSS og dynamisk refererte bilder, og CDN-automatisering der det er tilgjengelig.

Picture-elementet

<picture>-elementet gir den reneste klientsideløsningen. Nettlesere evaluerer <source>-elementer ovenfra og ned og bruker det første støttede formatet:

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

For responsive bilder trenger hver kilde sin egen srcset med breddedeskriptorer. Dette skaper en kombinatorisk eksplosjon av 12+ varianter per bilde (3 eller 4 formater x 3 eller 4 størrelser). Det er her CDN-automatisering blir essensielt.

Tjenerside innholdsforhandling

Tjenerside innholdsforhandling inspiserer Accept-headeren. Safari 17+ sender image/jxl i sin Accept-header. Nginx-konfigurasjon mapper dette til filendelser:

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

Den kritiske detaljen: inkluder alltid Vary: Accept i responsheaderen slik at CDN-er og proxy-cacher lagrer separate varianter per format. Uten dette vil et cachet JXL-svar bli servert til nettlesere som ikke kan dekode det.

CDN-støtte

CDN-støtte er ujevn. Cloudinary tilbyr full JPEG XL-støtte gjennom sin f_auto-parameter. Ikke overraskende med tanke på at Cloudinary var med på å skape formatet og allerede leverer omtrent 1 milliard JPEG XL-bilder per dag. Fastlys Image Optimizer la til full JPEG XL-støtte i juli 2024, med kodingsinnsats 3 med 4 tråder og påstått ~60 % besparelse over JPEG. Cloudflare, til tross for sterk etterspørsel fra fellesskapet, støtter ikke JPEG XL-konvertering i sitt Image Resizing-produkt. Det kan cache JXL-varianter fra din opprinnelsesserver via Vary: Accept, men kan ikke generere dem. AWS CloudFront, Akamai og Azure har ingen native JPEG XL-støtte.

Verktøy

Verktøy for å generere JPEG XL-filer sentrerer seg rundt cjxl fra libjxl-referanseimplementeringen. Nøkkelparametere: -d for avstand (0 = tapsfri, 1,0 til 2,0 for nettkvalitet med tap), -e for innsats (1 til 9, standard 7), og -p for progressiv koding. For JPEG-inndata utfører cjxl input.jpg output.jxl tapsfri transkoding som standard. Den enklest mulige migrasjonsveien. ImageMagick, libvips (siden 8.11) og Photoshop v25 støtter også JXL. Imidlertid eksponerer sharp (Node.js-bildebiblioteket som driver Next.js) ikke ennå JXL-utdata, noe som betyr at Next.js ikke har native JPEG XL-støtte. WordPress kjernestøtte spores som ticket #52788, merket «maybelater».

Halloween-avgjørelsen og dens tre år lange reversering

Den politiske historien til JPEG XL i Chrome er en casestudie i nettleserleverandørers makt over nettstandarder. Å forstå den er viktig fordi den avslører kreftene som former hvilke teknologier som når brukerne.

Den 31. oktober 2022. Kallenavnet «Halloween-avgjørelsen». Jim Bankoski fra Googles Chrome-team kunngjorde fjerningen av eksperimentell JPEG XL-støtte. De oppgitte grunnene var firefoldige: eksperimentelle flagg bør ikke forbli på ubestemt tid; utilstrekkelig økosysteminteresse; utilstrekkelige inkrementelle fordeler over eksisterende formater; og vedlikeholdsbyrde. Bankoski foreslo WebAssembly som «en flott vei videre» for de som ønsket JPEG XL i Chrome.

Motreaksjonen var umiddelbar og vedvarende. Chromium-saken ble den nest mest stjernemerkede i prosjektets hele historie, med over 1 000 oppstemmer og kommentarer fra representanter for Intel, Adobe, Meta, Shopify, The Guardian, Flickr og Krita Foundation. Jon Sneyers, JPEG XL-medskaperen hos Cloudinary, publiserte et detaljert teknisk tilsvar («The Case for JPEG XL») som viste at Googles publiserte sammenligningstester brukte feilaktige JPEG XL-implementeringer og metrikker som favoriserte AVIF. Free Software Foundation kalte Googles avgjørelse bevis på at Google Chrome hadde blitt dommeren for nettstandarder og anklaget selskapet for å handle i egne interesser. Siden AVIF stammer fra AV1, utviklet av Alliance for Open Media som Google var medgrunnlegger av.

Ironien gikk ikke upåaktet hen hos observatører: Google selv var med på å skape JPEG XL gjennom sitt PIK-prosjekt, noe som gjorde avgjørelsen om å fjerne det fra Chrome enda mer forvirrende. Da JPEG XL ble foreslått for Interop 2024, mottok det 646 reaksjoner fra fellesskapet. 4,5 ganger mer enn andreplassforslaget. Og ble avvist med kun «manglende konsensus» som forklaring.

Det som til slutt snudde avgjørelsen var økosystemmomentum som gjorde Chromes fravær uholdbart. At Apple leverte Safari 17 med JPEG XL-støtte i september 2023 var det første store gjennombruddet. At Mozilla endret seg fra «negativ» til «nøytral» og deretter til aktivt villig til å implementere (med en Rust-dekoder) økte presset. At PDF Association kunngjorde JPEG XL som det foretrukne HDR-formatet for PDF i oktober 2025 kan ha vært vendepunktet. Chromes innebygde PDF-viser ville trenge JXL-støtte for å forbli kompatibel. Den 21. november 2025 publiserte Rick Byers (Chrome Architecture Tech Lead) reverseringen og ønsket bidrag velkommen for å integrere en ytelseseffektiv og minnesikker JPEG XL-dekoder i Chromium. Innen januar 2026 var den Rust-baserte jxl-rs-dekoderen sammenslått, og Chrome 145 leverte den bak et flagg i februar 2026.

Konklusjon: forbered nå, distribuer trinnvis

JPEG XL er teknisk sett det beste generelle bildeformatet tilgjengelig. Bedre komprimering enn AVIF ved praktiske kodingshastigheter, progressiv dekoding som ingen konkurrent tilbyr, og tapsfri JPEG-transkoding som gir en umiddelbar 20 % besparelse uten kvalitetstap. De politiske hindringene som blokkerte adopsjonen i tre år er i ferd med å løse seg: Chrome har kode i treet, Firefox integrerer aktivt den samme Rust-dekoderen, og Safari har levert støtte siden 2023.

Den praktiske veien videre for web performance-team er klar. Begynn å generere JXL-varianter nå. Tapsfri JPEG-transkoding via cjxl er trivielt automatiserbar og gir umiddelbare 20 % besparelser for de ~12 % av brukerne på Safari. Bruk <picture>-elementer eller innholdsforhandling med Vary: Accept-headere for å servere JXL sammen med AVIF, WebP og JPEG fallbacks. Hvis CDN-en din er Cloudinary eller Fastly, aktiver automatisk JXL-levering i dag. Det åpne spørsmålet er ikke om JPEG XL vil oppnå bred nettleserstøtte, men når Chrome vil slå flagget fra av til på som standard. Og det eneste ærlige svaret er at ingen tidslinje er kunngjort. Formatets tre år lange eksil fra Chrome bør dempe entusiasme med pragmatisme: server det der det støttes, fall tilbake elegant ellers, og hold rørledningen klar for øyeblikket universell støtte ankommer.