JPEG XL ja Core Web Vitals: mitä sinun tulee tietää nyt kun Chrome tukee sitä

JPEG XL palaa vihdoin Chromeen

Kolmen vuoden kiistelyn jälkeen JPEG XL on palannut Chromiumiin. Chrome 145, joka julkaistiin helmikuun alussa 2026, sisältää JPEG XL -dekooderin. Yhä lipun takana, mutta toiminnallisesti läsnä koodikannassa ensimmäistä kertaa sen kiistanalaisen poistamisen jälkeen loppuvuodesta 2022. Tämä on merkittävää, koska JPEG XL on todistettavasti ylivoimainen kaikkiin nykyisiin verkkokuvaformaatteihin nähden useimmilla teknisillä mittareilla: 50–60 % pienempi kuin JPEG, 10–15 % parempi pakkaus kuin AVIF vastaavilla koodausnopeuksilla, ja ainoa moderni formaatti, jossa on todellinen progressiivinen dekoodaus. Web-suorituskykyammattilaisille formaatin matka ISO-standardista Chromen maanpakoon ja siitä ylösnousuun edustaa sekä teknistä mahdollisuutta että varoittavaa tarinaa selainvalmistajien vallasta web-alustalla.

Selaintuki helmikuussa 2026 on vain 12 %

JPEG XL:n todellinen maailmanlaajuinen selaintuki on noin 12 %, lähes kokonaan Safarin käyttäjiltä. Tämä luku on muuttumassa. Mutta aikataulu on yhä epävarma.

Safari 17+ (julkaistu syyskuussa 2023) tarjoaa natiivin JPEG XL -dekoodauksen macOS Sonoman, iOS 17:n, iPadOS 17:n, watchOS:n ja visionOS:n kautta. Applen toteutus delegoi dekoodauksen käyttöjärjestelmätason kuvakehykselle, mikä tarkoittaa, että se toimii kaikkialla, missä Safari toimii. Safarin tuki on kuitenkin nimenomaisesti osittainen: ei animaatiotukea eikä progressiivista dekoodausta. Kaksi JPEG XL:n erottuvinta ominaisuutta. Tämä on merkittävä rajoitus, joka heikentää formaatin täyttä arvolupausta Apple-laitteilla.

Chrome 145 (helmikuu 2026) tuo JPEG XL:n takaisin puhtaalla Rust-dekooderilla nimeltä jxl-rs, joka korvaa aiemman C++ libjxl-toteutuksen. Dekooderi on portitettu lipun chrome://flags/#enable-jxl-image-format taakse eikä ole oletuksena käytössä. Google on asettanut selkeät ehdot oletuskäyttöönotolle: sitoutuminen pitkäaikaiseen ylläpitoon ja standardien julkaisukriteerien täyttäminen. Rust-dekooderi suoriutuu tällä hetkellä 15–25 % C++-referenssitoteutuksen nopeudesta, ja pelkästään joulukuussa 2025 yhdistettiin 26 optimointi-PR:ää. Vahvistettuihin toimiviin ominaisuuksiin kuuluvat ICC-väriprofiilit, animaatiot, alpha/läpinäkyvyys, laaja väriavaruus (Display P3) ja HDR (PQ/HLG).

Firefox on kauimpana jäljessä. Formaatti on saatavilla vain Firefox Nightlyssa lipun image.jxl.enabled takana. Ratkaisevasti dekooderikoodi ei ole lainkaan käännettynä vakaissa versioissa, joten lippu ei tee mitään julkaisuversiossa Firefoxissa. Mozillan kanta on muuttunut "kielteisestä" "neutraaliksi", ja aktiivista työtä (Bug 1986393) tehdään saman jxl-rs Rust-dekooderin integroimiseksi. Aikataulua vakaalle tuelle ei ole.

Edge, Chromium-johdannaisena, sisältää todennäköisesti jxl-rs-koodin Chrome 145:stä, mutta ei ole virallisesti ilmoittanut tai dokumentoinut JPEG XL -tukea. Edge 145:n julkaisutiedotteessa ei mainita sitä.

Interop 2026 on sisällyttänyt JPEG XL:n tutkimusalueeksi (ei täydeksi painopistealueeksi), ja Apple, Google, Microsoft ja Mozilla osallistuvat kaikki. Tämä viestii selainvalmistajien yhteisestä aikomuksesta rakentaa kattavat testisarjat, mikä tyypillisesti edeltää laajempaa käyttöönottoa.

Miten JPEG XL päihittää jokaisen vaihtoehdon. Ja missä se ei päihitä

Pakkaustehon tarina on vivahteinen ja riippuu voimakkaasti sisältötyypistä ja bittinopeudesta. Korkeimmalla tasolla JPEG XL voittaa tärkeimmissä todellisen maailman vertailuissa.

JPEG:tä vastaan

Edut ovat dramaattiset. JPEG XL saavuttaa visuaalisesti häviöttömän laadun noin 1,2 bittiä pikseliä kohden, kun JPEG vaatii 2,4 bpp. 2:1-parannus. DebugBear-vertailu 990 KB:n valokuvasta osoitti JPEG XL:n olevan 472 KB (52 % säästö) verrattuna WebP:n 700 KB:iin ja AVIF:n 507 KB:iin. Cloudinaryn testaus yli 40 000 kuvasta havaitsi, että JPEG XL effort 6 -asetuksella tuotti tiedostoja, jotka olivat 20 % pienempiä kuin AVIF ja koodautuivat 2,5 kertaa nopeammin.

AVIF:iä vastaan

Vertailu riippuu bittinopeudesta. Matalilla bittinopeuksilla alle 0,4 bpp (raskas pakkaus) AVIF päihittää JPEG XL:n. Se tuottaa tasaisempia kuvia vähemmillä artefakteilla. Keski- ja korkeilla bittinopeuksilla (0,4 bpp ja yli), joilla suurin osa verkkovalokuvista elää, JPEG XL voittaa johdonmukaisesti yksityiskohtien säilyttämisessä ja tarkkuudessa. Googlen oma AVIF-vertailututkimus osoitti 9/13 laatumittarin suosivan JPEG XL:ää käytännöllisissä koodausnopeusasetuksissa. Koodausnopeusero on valtava: AVIF (libaom:n kautta) on kertaluokkaa hitaampi kuin JPEG XL yksisäikeisessä koodauksessa. AVIF:n hitaimmilla asetuksilla (~0,5 Mpx/s) se vastaa JPEG XL:n toiseksi nopeimman asetuksen pakkaustiheyttä 52 Mpx/s:llä. 100-kertainen nopeusero.

WebP:tä vastaan

JPEG XL voittaa ratkaisevasti. WebP on rajoitettu 8-bittiseen värisyvyyteen, 4:2:0-kromaattiseen alinäytteistykseen häviöllisessä tilassa ja enimmäisresoluutioon 16 383 × 16 383 pikseliä. JPEG XL tukee jopa 32 bittiä kanavaa kohden (kokonaisluku tai liukuluku), yli miljardin pikselin resoluutioita sivua kohden, eikä sillä ole kromaattisen alinäytteistyksen rajoitusta.

Sisältötyypillä on merkitystä

Tiettyjen sisältötyyppien osalta DebugBear-vertailut paljastivat monipuolisemman kuvan. AVIF voitti logoissa (2 KB vs. JXL:n 6 KB) ja läpinäkyvyyskuvissa (18 KB vs. 63 KB), kun taas JPEG XL voitti valokuvissa (472 KB vs. 507 KB) ja animoidussa sisällössä, jossa se saavutti 99 % pakkauksen (14 KB 1,3 MB:n GIF:stä verrattuna AVIF:n 56 KB:iin). Nämä tulokset käyttivät Cloudinaryn oletusasetuksia, joten ne edustavat tyypillisiä eikä optimoituja tuloksia.

Ominaisuusvertailu

Ominaisuus	JPEG	WebP	AVIF	JPEG XL
Maksimibittisyvyys	8 bit	8 bit	10/12 bit	32 bit
Progressiivinen dekoodaus	Rajoitettu	Ei	Ei	Edistynyt
Häviötön JPEG-transkoodaus	N/A	Ei	Ei	Kyllä (~20 % säästö)
HDR-tuki	Ei	Ei	Kyllä	Kyllä (ylivoimainen)
Maksimiresoluutio	65K x 65K	16K x 16K	65K x 65K	~1B x 1B
Animaatio	Ei	Kyllä	Kyllä	Kyllä
Koodausnopeus	Nopein	Nopea	Erittäin hidas	Nopea
Dekoodausnopeus	Nopea	Kohtalainen	Hidas	Nopea

Kaksi ominaisuutta, joita mikään muu formaatti ei voi tarjota

JPEG XL:n strategisesti tärkeimmät ominaisuudet ovat progressiivinen dekoodaus ja häviötön JPEG-transkoodaus. Mikään kilpailija ei tarjoa kumpaakaan.

Progressiivinen dekoodaus

Progressiivinen dekoodaus muuttaa perustavanlaatuisesti tapaa, jolla kuvat latautuvat. JPEG XL -tiedostot ovat aina vähintään 8×8-progressiivisia; DC-kehys (matala taajuus) koodataan aina ensimmäisenä. Vain ~1 % tiedostodatasta ladattuna näkyviin tulee käyttökelpoinen koko kuvan esikatselu. Vertaa tätä progressiiviseen JPEG:iin, joka vaatii 10–15 % ensimmäiseen skannaukseen. Vielä tärkeämpää on, että JPEG XL tukee merkittävyysjärjestykseen perustuvaa progressiota: koneoppimismallit voivat tunnistaa visuaalisesti tärkeimmät alueet (kasvot muotokuvissa, tuotetiedot verkkokaupassa) ja koodata nämä alueet saapumaan ensin. Dekooderi tasoittaa rajat valmiiden ja vielä latautuvien alueiden välillä.

Tämä luo erilaisen renderöintiaikajannan. AVIF vaatii koko pakatun kuvan ennen kuin dekoodaus voi alkaa: kokonaisaika on latausaika plus dekoodausaika, peräkkäin. JPEG XL limittää siirron ja dekoodauksen, joten käyttäjä näkee merkityksellistä sisältöä paljon nopeammin. Cloudinary on todennut, että JPEG XL:n progressiivinen renderöinti eliminoi tarpeen erillisille Low Quality Image Placeholder (LQIP) -tiedostoille, poistaen ylimääräiset tavut kokonaan. On kuitenkin huomionarvoista, että Safarin nykyinen toteutus ei tue progressiivista dekoodausta, mikä rajoittaa tämän edun tuleviin Chrome- ja Firefox-toteutuksiin.

Häviötön JPEG-transkoodaus

Häviötön JPEG-transkoodaus on JPEG XL:n piilossa oleva valttikortti. Formaatti voi suoraan kopioida JPEG:n DCT-lohkokertoimet omiin VarDCT-lohkoihinsa parantaen ainoastaan entropiakoodausta. Tulos: ~20 % keskimääräinen tiedostokoon pieneneminen (vaihteluväli: 13–22 %) ja alkuperäinen JPEG-tiedosto on bitti bitiltä palautettavissa JXL-tiedostosta. Mikään muu formaatti ei kykene tähän. Transkoodaus WebP:hen tai AVIF:iin vaatii dekoodauksen pikseleiksi ja uudelleenkoodauksen, mikä aiheuttaa sukupolvihäviötä. Google Cloud Platformin DICOM API käyttää jo tätä ominaisuutta lääketieteellisten kuvantamistiedostojen koon pienentämiseen 20 %:lla.

Verkkomittakaavassa, jos kaikki nykyiset JPEG-kuvat transkoodattaisiin häviöttömästi JXL:ksi, kaistanleveyden säästöt olisivat valtavat. JPEG XL -yhteisö arvioi energiasäästöjen vastaavan noin 487 000 yhdysvaltalaisen kodin sähkönkulutusta tunti päivässä.

Mitä tämä tarkoittaa Core Web Vitals -mittareille

JPEG XL vaikuttaa kuhunkin Core Web Vitals -mittariin eri mekanismien kautta, ja suhde on vivahteikkaampi kuin "pienemmät tiedostot = paremmat pisteet."

LCP (Largest Contentful Paint)

LCP hyötyy kahdesta toisiaan vahvistavasta vaikutuksesta. Ensinnäkin pienemmät tiedostokoot vähentävät resurssin latausaikaa (Resource Load Duration). Lataamisvaihe. 52 %:n pienennys JPEG:stä tarkoittaa, että hero-kuva saapuu noin kaksi kertaa nopeammin kaistanleveysrajoitteisilla yhteyksillä. Toiseksi JPEG XL dekoodautuu nopeammin kuin AVIF, mikä vähentää elementin renderöintiviivettä (Element Render Delay). AVIF:n monimutkainen videokoodekkipohjainen dekoodaus voi aiheuttaa merkittävää CPU-kuormitusta mobiililaitteilla, jolloin pienempi AVIF, joka latautuu nopeammin, voi osittain kumoutua pidemmän dekoodausajan vuoksi. JPEG XL:n dekoodausnopeus jopa 132 Mpx/s ja SIMD-optimointi minimoivat tämän pullonkaulan. LCP mitataan kuitenkin, kun kuva on täysin renderöity, joten progressiivinen dekoodaus ei suoraan paranna LCP-aikaleimaa. Se parantaa koettua suorituskykyä, mikä merkitsee user experience -näkökulmasta, vaikka se ei liikuta mittaria.

CLS (Cumulative Layout Shift)

CLS ei välitä formaatista. Kaikki formaatit hyötyvät yhtä lailla eksplisiittisistä width- ja height-attribuuteista. JPEG XL koodaa ulottuvuustiedot varhaisiin otsakkeisiin, mikä voisi teoriassa auttaa selaimia varaamaan tilaa nopeammin, mutta käytännön vaikutus on merkityksetön verrattuna yksinkertaiseen mittojen asettamiseen HTML:ssä.

INP (Interaction to Next Paint)

INP:hen voi vaikuttaa raskas kuvien dekoodaus pääsäikeessä. JPEG XL:n nopeampi dekoodaus ja SIMD-optimointi tarkoittavat vähemmän pääsäikeen estämistä kuin AVIF, vaikka molemmat formaatit dekoodataan tyypillisesti pääsäikeen ulkopuolella moderneissa selaimissa.

Todellisen maailman vaikutus

Mediaanisivu vuonna 2025 lataa mobiililla 19 kuvaa, jotka painavat yhteensä 911 KB (HTTP Archive Web Almanac 2025). Näiden muuntaminen JPEG:stä JPEG XL:ksi säästäisi noin 450–550 KB sivua kohden. Merkittävä parannus rajoitetuilla verkoilla oleville käyttäjille. Työpöydän mediaani-kuvapainolla 1 058 KB säästöt lähestyvät 500–630 KB:ta.

JPEG XL:n tarjoilu tänään asianmukaisilla fallback-ratkaisuilla

Toteutus vaatii kerroksittaisen strategian: <picture>-elementti HTML-kuville, palvelinpuolen sisältöneuvottelu CSS:lle ja dynaamisesti viitattaville kuville sekä CDN-automaatio saatavilla ollessaan.

Picture-elementti

<picture>-elementti tarjoaa selkeimmän asiakaspuolen lähestymistavan. Selaimet arvioivat <source>-elementit ylhäältä alas ja käyttävät ensimmäistä tuettua formaattia:

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

Responsiivisille kuville jokainen lähde tarvitsee oman srcset-attribuutin leveyskuvaajilla. Tämä luo kombinatorisen räjähdyksen: yli 12 varianttia kuvaa kohden (3–4 formaattia × 3–4 kokoa). Tässä CDN-automaatio tulee välttämättömäksi.

Palvelinpuolen sisältöneuvottelu

Palvelinpuolen sisältöneuvottelu tarkistaa Accept-otsakkeen. Safari 17+ lähettää image/jxl-arvon Accept-otsakkeessaan. Nginx-konfiguraatio kartoittaa tämän tiedostopäätteisiin:

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

Ratkaiseva yksityiskohta: sisällytä aina Vary: Accept vastausotsakkoon, jotta CDN:t ja välimuistipalvelimet tallentavat erilliset variantit formaattia kohden. Ilman tätä välimuistiin tallennettu JXL-vastaus tarjoillaan selaimille, jotka eivät kykene dekoodaamaan sitä.

CDN-tuki

CDN-tuki on epätasaista. Cloudinary tarjoaa täyden JPEG XL -tuen f_auto-parametrillaan. Ei yllättävää, sillä Cloudinary oli mukana luomassa formaattia ja toimittaa jo noin miljardi JPEG XL -kuvaa päivässä. Fastlyn Image Optimizer lisäsi täyden JPEG XL -tuen heinäkuussa 2024 käyttäen koodaus-effort 3:a neljällä säikeellä ja ilmoittaen ~60 % säästöistä JPEG:hin verrattuna. Cloudflare ei vahvasta yhteisökysynnästä huolimatta tue JPEG XL -muunnosta Image Resizing -tuotteessaan. Se voi välimuistittaa JXL-variantteja alkuperäispalvelimeltasi Vary: Accept -otsakkeen avulla, mutta ei voi generoida niitä. AWS CloudFront, Akamai ja Azure eivät tarjoa natiivista JPEG XL -tukea.

Työkalut

JPEG XL -tiedostojen luomisen työkalut keskittyvät cjxl-komentoon libjxl-referenssitoteutuksesta. Keskeiset parametrit: -d etäisyydelle (0 = häviötön, 1,0–2,0 verkkokäyttöön sopivalle häviölliselle), -e effortille (1–9, oletus 7) ja -p progressiiviselle koodaukselle. JPEG-syötteille cjxl input.jpg output.jxl suorittaa oletuksena häviöttömän transkoodauksen. Yksinkertaisin mahdollinen siirtymäpolku. ImageMagick, libvips (versiosta 8.11) ja Photoshop v25 tukevat myös JXL:ää. sharp (Node.js-kuvakirjasto, joka toimii Next.js:n taustalla) ei kuitenkaan vielä tarjoa JXL-ulostuloa, mikä tarkoittaa, ettei Next.js:llä ole natiivista JPEG XL -tukea. WordPress-ytimen tuki on seurannassa tikettinä #52788, merkittynä "maybelater."

Halloween-päätös ja sen kolmen vuoden kumoutuminen

JPEG XL:n poliittinen historia Chromessa on tapaustutkimus selainvalmistajien vallasta web-standardien yli. Sen ymmärtäminen on tärkeää, koska se paljastaa voimat, jotka muokkaavat sitä, mitkä teknologiat pääsevät käyttäjien ulottuville.

31. lokakuuta 2022. Lempinimeltään "Halloween-päätös." Jim Bankoski Googlen Chrome-tiimistä ilmoitti JPEG XL:n kokeellisen tuen poistamisesta. Ilmoitetut syyt olivat neljä: kokeelliset liput eivät saisi jäädä pysyviksi; riittämätön ekosysteemin kiinnostus; riittämätön inkrementaalinen hyöty olemassa oleviin formaatteihin nähden; ja ylläpitotaakka. Bankoski ehdotti WebAssemblya "loistavaksi poluksi eteenpäin" niille, jotka halusivat JPEG XL:n Chromeen.

Vastareaktio oli välitön ja jatkuva. Chromium-tiketti muodostui projektin koko historian toiseksi tähditetyimmäksi, yli 1 000 ääntä ylös ja kommentteja Intelin, Adoben, Metan, Shopifyn, The Guardianin, Flickrin ja Krita Foundationin edustajilta. Jon Sneyers, JPEG XL:n toinen luoja Cloudinarysta, julkaisi yksityiskohtaisen teknisen vastineen ("The Case for JPEG XL"), jossa osoitettiin Googlen julkaistujen vertailutestien käyttäneen bugisia JPEG XL -toteutuksia ja AVIF:iä suosivia mittareita. Free Software Foundation kutsui Googlen päätöstä todisteeksi siitä, että Google Chrome oli noussut web-standardien ylituomariksi ja syytti yhtiötä omien etujensa ajamisesta. Koska AVIF perustuu AV1:een, jonka on kehittänyt Googlen yhteisperustama Alliance for Open Media.

Ironia ei jäänyt tarkkailijoilta huomaamatta: Google itse oli mukana luomassa JPEG XL:ää PIK-projektinsa kautta, mikä teki päätöksestä tappaa se Chromesta entistäkin hämmentävämmän. Kun JPEG XL:ää ehdotettiin Interop 2024:ään, se sai 646 yhteisöreaktiota. 4,5-kertaisesti toiseksi eniten saaneeseen ehdotukseen nähden. Ja hylättiin vain "konsensuksen puute" -selityksellä.

Mikä lopulta kumosi päätöksen, oli ekosysteemin liikehdintä, joka teki Chromen poissaolosta kestämätöntä. Applen Safari 17:n julkaisu JPEG XL -tuella syyskuussa 2023 oli ensimmäinen merkittävä murros. Mozillan siirtyminen "kielteisestä" "neutraaliksi" ja sitten aktiivisesti toteutushaluiseksi (Rust-dekooderilla) lisäsi painetta. PDF Associationin ilmoitus JPEG XL:stä ensisijaisena HDR-formaattina PDF:lle lokakuussa 2025 saattoi olla käännekohta. Chromen sisäänrakennettu PDF-katselin tarvitsisi JXL-tukea pysyäkseen yhteensopivana. 21. marraskuuta 2025 Rick Byers (Chromen arkkitehtuurin tekninen johtaja) julkaisi kumoamispäätöksen ja toivotti tervetulleeksi kontribuutiot suorituskykyisen ja muistiturvallisen JPEG XL -dekooderin integroimiseksi Chromiumiin. Tammikuuhun 2026 mennessä Rust-pohjainen jxl-rs-dekooderi oli yhdistetty, ja Chrome 145 toimitti sen lipun takana helmikuussa 2026.

Johtopäätös: valmistaudu nyt, ota käyttöön vaiheittain

JPEG XL on teknisesti paras saatavilla oleva yleiskäyttöinen kuvaformaatti. Parempi pakkaus kuin AVIF käytännöllisissä koodausnopeuksissa, progressiivinen dekoodaus, jota mikään kilpailija ei tarjoa, ja häviötön JPEG-transkoodaus, joka tuottaa välittömän 20 % säästön ilman laadun heikkenemistä. Poliittiset esteet, jotka estivät sen käyttöönottoa kolme vuotta, ovat hälvenemässä: Chromessa on koodi puussa, Firefox integroi aktiivisesti samaa Rust-dekooderia, ja Safari on tukenut formaattia vuodesta 2023.

Käytännön polku eteenpäin web-suorituskykytiimeille on selvä. Aloita JXL-varianttien generointi nyt. Häviötön JPEG-transkoodaus cjxl-komennolla on trivialisti automatisoitavissa ja tarjoaa välittömän 20 % säästön noin 12 %:lle käyttäjistä Safarissa. Käytä <picture>-elementtejä tai sisältöneuvottelua Vary: Accept -otsakkeilla tarjoillaksesi JXL:ää AVIF:n, WebP:n ja JPEG-vaihtoehtojen rinnalla. Jos CDN:si on Cloudinary tai Fastly, ota automaattinen JXL-toimitus käyttöön tänään. Avoin kysymys ei ole, saavuttaako JPEG XL laajan selaintuen, vaan milloin Chrome kääntää lipun pois-tilasta oletuksena päälle. Ja ainoa rehellinen vastaus on, ettei aikataulua ole ilmoitettu. Formaatin kolmen vuoden maanpako Chromesta tulisi hillitä innostusta pragmatismilla: tarjoile sitä siellä, missä sitä tuetaan, palaa sulavasti muualle, ja pidä putki valmiina sille hetkelle, kun universaali tuki saapuu.