Chrome 155、JPEG XLを既定で有効化

Chrome 155はJPEG XL画像を既定でデコードする。GoogleのChromeチームが発表したのは2026年10月6日だ。デコーダーはjxl-rsで、メモリ安全性のためにRustで書かれている。Firefox 158が10月13日に続く予定なので、JPEG XLは主要なブラウザーエンジンすべてで動くことになる。ウェブ開発者が求め続けてきたフォーマットにとって、4年に及ぶ回り道がこれで終わる。

Chromeが出荷したもの

JPEG XLは拡張子が.jxlの画像フォーマットで、JPEGの置き換えを目指して設計された。写真をより小さなサイズで保存できるほか、既存のJPEGを画質を損なわずに包み直すこともできる。

Chromeチームは、対応する機能を次のように挙げている。

• 非可逆圧縮と可逆圧縮
• HDR、つまりハイダイナミックレンジ。より明るいハイライトと、より深い影を表現できる
• 可逆JPEGトランスコード。古いJPEGを縮小し、元のファイルにそのまま戻すこともできる
• プログレッシブデコード。まず大まかな画像を表示し、データが届くにつれて鮮明にしていく
• アニメーション

CoreWebVitals.ioによると、このフォーマットは2026年2月のChrome 145で初めて登場し、chrome://flags/#enable-jxl-image-formatのフラグの裏に置かれていた。Chrome 155でそのフラグは不要になった。

デコーダーがRustで書かれている理由

画像デコーダーは、攻撃者が狙う典型的な標的である。画像を展開するコードにバグがあると、細工された画像でブラウザーを乗っ取られかねない。Chromeチームはデコーダーを「現代のウェブブラウザーで最も重要かつ最も狙われる攻撃対象領域の1つ」と呼んでいる。

そこでChromeチームが選んだのが、Rustでゼロから書かれたデコーダーのjxl-rsだ。RustのコンパイラーはCやC++なら許してしまう、メモリバグの類型をまるごと防ぐ。チームはjxl_simdも作った。GoogleのHighwayライブラリに着想を得たSIMD層である。SIMD命令を使うとプロセッサーが多数のピクセルを一度に処理できるので、安全なコードでも高速に動く。

Chromeチームによると、この作業の間、ファジングとAIによるコードレビューではメモリ安全性のバグは見つからなかった。ファジングとは、コードに何百万ものランダムな入力を浴びせるテスト手法である。

速度については、報告が食い違っている。CoreWebVitals.ioは、jxl-rsはC++のリファレンスデコーダーの15〜25%以内の速度で動くとしている。Filezaは、その差を5〜10%としている。

Chromeが方針を変えた理由

Chromeは以前にもJPEG XLを外したことがある。Filezaはそれを「物議を醸した2022年の削除」と呼ぶ。Chromeチームは今回、「ウェブ開発者から寄せられ続けた意見と要望」に応じたのだと説明している。その根拠として挙げるのが、Interop Projectの提案でこのフォーマットが人気を集めていることだ。Interop Projectでは、ブラウザーメーカーが毎年、共同で解消すべき差異を取り決める。

この復活は、長い流れの先にある。Mozillaは8月、独自のRust製デコーダーによるJPEG XL対応を発表した。jpegxl.infoは現在、Firefox 158が既定で有効にするとし、時期を2026年10月13日としている。

ブラウザー	JPEG XLの状況	出典
Chrome 155以降	既定で有効	Chromeチーム、jpegxl.info
Chrome 145〜154	フラグの裏	CoreWebVitals.io
Firefox 158	既定で有効、2026年10月13日の予定	jpegxl.info
Safari 17以降	2023年9月から対応。アニメーションとプログレッシブデコードは非対応	CoreWebVitals.io
Brave Beta 1.98以降	対応。Chromium 155がベース	jpegxl.info

ファイルはどれだけ小さくなるのか

サイズに関する主張は、情報源によってばらつきがある。CoreWebVitals.ioは、JPEG XLのファイルはJPEGより50〜60%小さく、AVIFより10〜15%小さいとしている。可逆のJPEG再圧縮については、同サイトもFilezaも約20%小さいとしている。

こうした比較に誰もが賛成しているわけではない。9月に出た詳細な批評は、AVIFは今や圧縮でJPEG XLを上回ると論じた。勝者を決める前に、自分の画像で測ってみてほしい。

開発者にとっての意味

• フォールバックを付けてJPEG XLを配信する。 HTMLのpicture要素でimage/jxlタイプのsourceを使うか、サーバー側でAcceptヘッダーを確認する。バージョン155より前のChromeや、対応していないブラウザーには、引き続きJPEG、WebP、AVIFが必要だ。
• まず可逆JPEG再圧縮から始める。 最も安全な成果が得られる。既存のJPEGは約20%小さくなり、元のファイルにそのまま戻せる。だから考えを変えても何も失われない。
• アニメーションとプログレッシブ画像はSafariで試す。 CoreWebVitals.ioによると、Safariはどちらにも対応していない。Chromeで問題なく見えるプログレッシブなJXLが、Safariでは一度に読み込まれるかもしれない。
• 画像パイプラインを更新する。 未知のMIMEタイプを拒否するCDN、リサイズ処理、アップロード検証は、.jxlファイルをブロックしてしまう。ユーザーがアップロードを始める前に確認しておこう。
• Largest Contentful Paintに注目する。 ヒーロー画像が小さくなれば、このCore Web Vitalsのスコアが改善することがある。このスコアは、主要なコンテンツが表示されるまでの時間を測る。比較するときは、ラボテストだけでなく実際のトラフィックで、変更の前後を見ること。

10月13日のFirefox 158のリリースに注目しておきたい。予定どおり出荷されれば、JPEG XLは実験的なものではなく、計画の前提にできるフォーマットになる。