JPEG XLとCore Web Vitals: Chromeでのサポート開始にあたり知っておくべきこと

JPEG XLがついにChromeに復活

3年間の議論を経て、JPEG XLがChromiumに復活しました。 2026年2月上旬にリリースされたChrome 145には、JPEG XLデコーダーが搭載されています。まだフラグの後ろに隠されていますが、2022年後半の物議を醸した削除以来、初めてコードベースに機能的に存在しています。これが重要なのは、JPEG XLがほとんどの技術的側面において、既存のすべてのWeb画像フォーマットよりも明らかに優れているためです。JPEGより50〜60%小さく、同等のエンコード速度でAVIFより10〜15%優れた圧縮率を誇り、真のプログレッシブデコードを備えた唯一の最新フォーマットです。 Webパフォーマンスの専門家にとって、このフォーマットがISO標準からChromeでの追放、そして復活に至った軌跡は、技術的な機会であると同時に、Webプラットフォームに対するブラウザベンダーの権力についての教訓でもあります。

最終査読: Arjen Karel (2026年2月)

2026年2月時点のブラウザサポートはわずか12%

JPEG XLの実質的なグローバルでのブラウザサポートは現在約12%で、そのほとんどがSafariユーザーによるものです。この数字は変わろうとしていますが、その時期は依然として不透明です。

Safari 17以降（2023年9月リリース）は、macOS Sonoma、iOS 17、iPadOS 17、watchOS、visionOS全体でネイティブなJPEG XLデコードを提供します。Appleの実装はデコードをOSレベルの画像フレームワークに委譲するため、Safariが動作するすべての場所で機能します。ただし、Safariのサポートは明らかに部分的です。アニメーションのサポートもプログレッシブデコードもありません。 これらはJPEG XLの最も特徴的な2つの機能です。これは、Appleデバイス上でのこのフォーマットの完全な価値提案を損なう、意味のある制限です。

Chrome 145（2026年2月）では、以前のC++ libjxl実装に代わり、jxl-rsと呼ばれる純粋なRustデコーダーを通じてJPEG XLが再導入されました。このデコーダーはchrome://flags/#enable-jxl-image-formatの後ろに制限されており、デフォルトでは有効になっていません。Googleは、デフォルトで有効にするための明確な条件を設定しています。それは、長期的なメンテナンスへのコミットメントと、標準的なローンチ基準を満たすことです。Rustデコーダーの現在のパフォーマンスは、C++リファレンス実装の速度の15〜25%の範囲内にあり、2025年12月だけで26の最適化PRがマージされました。動作が確認されている機能には、ICCカラープロファイル、アニメーション、アルファ/透明度、広色域（Display P3）、HDR（PQ/HLG）が含まれます。

今すぐChromeでJPEG XLを試すには、chrome://flags/#enable-jxl-image-formatに移動し、Enabled（有効）に設定します。Chromeを再起動してください。すでにJXL画像を配信しているサイト（Cloudinaryの顧客など）は、ブラウザへの配信を開始します。

Firefoxは依然として最も遅れをとっています。このフォーマットは、Firefox Nightlyでのみimage.jxl.enabledフラグの後ろで利用可能です。決定的なのは、デコーダーのコードが安定版ビルドにまったくコンパイルされていないため、リリース版のFirefoxではこのフラグが何も機能しないことです。Mozillaの立場は「否定的」から「中立的」へと変化しました。jxl-rs RustデコーダーはFirefox Nightly（Firefox 149をターゲット）に導入されましたが、安定版でリリースされる前に、カラープロファイルのサポート、プログレッシブデコード、HDR、プロファイラ統合、リリースビルドでのコンパイル、Web Platform Testsの合格という6つのブロッカーが残っています。安定版サポートのスケジュールは存在しません。

EdgeはChromiumの派生であるため、Chrome 145のjxl-rsコードが含まれている可能性がありますが、公式にはJPEG XLサポートを発表または文書化していません。Edge 145のリリースノートにはそれについての言及はありません。

Interop 2026では、JPEG XLが調査領域（完全なフォーカス領域ではない）として含まれており、Apple、Google、Microsoft、Mozillaのすべてが参加しています。これは、通常、より広範なリリースの前に行われる、包括的なテストスイートを構築するというベンダー間の意図を示しています。

JPEG XLがいかにして他のすべての選択肢を凌駕するか。そして、そうでない部分はどこか

圧縮効率の話は複雑であり、コンテンツタイプとビットレートに大きく依存します。最高レベルで見れば、JPEG XLは最も重要な現実世界の比較で勝利を収めています。

JPEGとの比較

その効果は劇的です。JPEG XLは、JPEGが2.4 bppを必要とするのに対し、約1.2 bits per pixelで視覚的にロスレスな品質を実現します。2対1の改善です。990 KBの写真を用いたDebugBearのベンチマークでは、WebPが700 KB、AVIFが507 KBであったのに対し、JPEG XLは472 KB (52%の削減)を示しました。40,000枚以上の画像を対象としたCloudinaryのテストでは、effort 6でのJPEG XLは、AVIFより20%小さいファイルを生成しながら、エンコード速度は2.5倍高速であることがわかりました。

AVIFとの比較

この比較はビットレートに依存します。0.4 bpp未満の低いビットレート（高圧縮）では、AVIFがJPEG XLを上回ります。アーティファクトの少ない、より滑らかな画像を生成します。ほとんどのWeb写真が該当する中〜高ビットレート（0.4 bpp以上）では、ディテールの保存と忠実度においてJPEG XLが一貫して優れています。Google自身のAVIF比較研究では、実用的なエンコーダ速度設定において、13の品質指標のうち9つでJPEG XLが有利であることが示されました。エンコード速度の差は巨大です。AVIF（libaom経由）は、シングルスレッドエンコードにおいてJPEG XLよりも一桁遅いです。AVIFの最も遅い設定（約0.5 Mpx/s）では、JPEG XLの2番目に速い設定である52 Mpx/sの圧縮密度に匹敵します。これは100倍の速度差です。

WebPとの比較

JPEG XLの決定的な勝利です。WebPは、8 bitの色深度、非可逆モードでの4:2:0クロマサブサンプリング、および最大解像度16,383 x 16,383ピクセルに制限されています。JPEG XLは、最大チャンネルあたり32 bit（整数または浮動小数点）、一辺あたり10億ピクセルを超える解像度をサポートし、クロマサブサンプリングの制約がありません。

コンテンツタイプによる違い

特定のコンテンツタイプについては、DebugBearのベンチマークはより複雑な結果を明らかにしました。ロゴ（2 KB 対 JXLの6 KB）と透過画像（18 KB 対 63 KB）ではAVIFが勝利しましたが、写真（472 KB 対 507 KB）と、99%の圧縮を達成したアニメーションコンテンツ（1.3 MBのGIFから14 KB、対してAVIFは56 KB）ではJPEG XLが勝利しました。これらの結果はCloudinaryのデフォルト設定を使用しているため、最適化された出力ではなく典型的な出力を表しています。

機能比較

他のどのフォーマットも太刀打ちできない2つの機能

JPEG XLの戦略的に最も重要な機能は、プログレッシブデコードとロスレスJPEGトランスコードです。競合フォーマットはどちらも提供していません。

プログレッシブデコード

プログレッシブデコードは、画像の読み込み方法を根本的に変えます。JPEG XLファイルは常に少なくとも8x8のプログレッシブであり、DC（低周波）フレームが常に最初にエンコードされます。ファイルデータのわずか約1%をダウンロードしただけで、使用可能な完全な画像のプレビューが表示されます。最初のスキャンに10〜15%を必要とするプログレッシブJPEGと比較してみてください。さらに重要なことに、JPEG XLはsaliency ordered progression（顕著性順序プログレッション）をサポートしています。機械学習モデルが視覚的に最も重要な領域（ポートレートの顔、eコマースの製品詳細など）を特定し、それらの領域が最初に到着するようにエンコードできます。デコーダーは、完了した領域とまだ読み込み中の領域の境界を滑らかにします。

これにより、異なるレンダリングタイムラインが作成されます。AVIFは、デコードを開始する前に完全な圧縮画像を必要とします。合計時間はダウンロード時間プラスデコード時間というように、順次進行します。JPEG XLは転送とデコードをオーバーラップさせるため、ユーザーは意味のあるコンテンツをはるかに早く目にすることができます。Cloudinaryは、JPEG XLのプログレッシブレンダリングにより個別の低解像度画像プレースホルダー（LQIP）ファイルが不要になり、冗長なバイトが完全に排除されると述べています。ただし、Safariの現在の実装はプログレッシブデコードをサポートしていないため、この利点は将来のChromeおよびFirefoxの実装に限定されることに注意する価値があります。

ロスレスJPEGトランスコード

ロスレスJPEGトランスコードは、JPEG XLの隠れた目玉機能です。このフォーマットは、JPEGのDCTブロック係数を独自のVarDCTブロックに直接コピーし、エントロピーコーディングのみを改善できます。結果として、元のJPEGファイルがJXLファイルからビット単位で正確に再構築可能な状態で、平均約20%のファイルサイズ削減（範囲：13〜22%）を実現します。これを実行できるフォーマットは他にありません。WebPやAVIFへのトランスコードでは、ピクセルへのデコードと再エンコードが必要となり、ジェネレーションロス（画質劣化）が発生します。Google Cloud PlatformのDICOM APIは、医療画像のファイルサイズを20%削減するためにすでにこの機能を使用しています。

Webスケールで考えると、もし現在のすべてのJPEGがJXLにロスレスでトランスコードされた場合、帯域幅の節約は莫大なものになります。JPEG XLコミュニティは、1日あたり米国の約487,000世帯に電力を供給するのに相当するエネルギー節約になると推定しています。

これがCore Web Vitalsにとって意味すること

LCP (Largest Contentful Paint)

LCPは、2つの複合的な効果から恩恵を受けます。第一に、ファイルサイズが小さくなることで、Resource Load Duration（ダウンロードフェーズ）が短縮されます。JPEGからの52%削減は、帯域幅が制限された接続において、ヒーロー画像が約2倍の速さで到着することを意味します。第二に、JPEG XLはAVIFよりもデコードが高速であり、Element Render Delayを短縮します。AVIFの複雑なビデオコーデック由来のデコードは、モバイルデバイスで意味のあるCPUオーバーヘッドを生み出す可能性があり、ダウンロードが速い小さなAVIFであっても、デコード時間が長くなることで部分的に相殺される可能性があります。最大132 Mpx/sのJPEG XLのデコード速度とSIMD最適化により、このボトルネックは最小限に抑えられます。ただし、LCPは画像が完全にレンダリングされたときに測定されるため、プログレッシブデコードはLCPのタイムスタンプを直接改善するわけではありません。これは体感パフォーマンスを向上させるものであり、指標を動かさなくてもuser experienceにとっては重要です。JPEG XLがLCP画像フォーマットである場合は、ブラウザができるだけ早くそれを発見できるようにプリロードしてください。

CLS (Cumulative Layout Shift)

CLSはフォーマットを気にしません。すべてのフォーマットは、明示的なwidth属性とheight属性から等しく恩恵を受けます。JPEG XLは初期のヘッダーに寸法情報をエンコードするため、理論的にはブラウザがスペースをより早く割り当てるのに役立つ可能性がありますが、HTMLで単純に寸法を設定するのと比べると、実用的な影響は無視できるレベルです。

INP (Interaction to Next Paint)

INPは、メインスレッドでの重い画像デコードの影響を受ける可能性があります。JPEG XLのより高速なデコードとSIMD最適化は、AVIFよりもメインスレッドのブロックが少ないことを意味しますが、どちらのフォーマットも通常、最新のブラウザではメインスレッド外でデコードされます。

現実世界での影響

2025 Web Almanacによると、モバイルとデスクトップの両方で、LCP画像の57%を依然としてJPEGが占めています。WebPは11%に成長し、2024年から4パーセントポイント上昇しました。AVIFはわずか0.7%にとどまっています。JPEG XLはまだ測定すらされていません。中央値のWebページは、モバイルで合計911 KBの画像を19枚読み込みます。これらをJPEGからJPEG XLに変換すると、1ページあたり約450〜550 KB節約できます。デスクトップの画像重量の中央値である1,058 KBでは、節約量は500〜630 KBに近づきます。

CoreDashによって監視されているサイト全体で、モダンなフォーマット（AVIFまたはWebP）で画像を配信しているページは、良好なLCP率が81%であるのに対し、依然としてJPEGのみに依存しているページでは64%です。JPEG XLがより幅広いブラウザサポートを獲得するにつれて、この差はさらに広がるはずです。JXLの配信を有効にした後、Real User Monitoringデータを監視することで、実際のユーザーがどれだけの恩恵を受けているかを正確に知ることができます。

適切なfallbackを備えた、今日のJPEG XLの配信方法

実装には階層化された戦略が必要です。HTML画像用の<picture>要素、CSSおよび動的に参照される画像用のサーバーサイドのコンテンツネゴシエーション、および利用可能な場合はCDNによる自動化です。

picture要素

<picture>要素は、最もクリーンなクライアントサイドのアプローチを提供します。ブラウザは<source>要素を上から下へと評価し、最初にサポートされているフォーマットを使用します。

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

この画像がヒーロー画像であり、LCP要素になる可能性が高い場合は、loading="lazy"を削除し、fetchpriorityをhighに設定します。絶対にLCP画像を遅延読み込み（lazy load）しないでください。

レスポンシブ画像の場合、各ソースに幅記述子付きの独自のsrcsetが必要です。これにより、画像あたり12種類以上（3〜4フォーマット × 3〜4サイズ）のバリアントという組み合わせの爆発が生じます。ここでCDNの自動化が不可欠になります。

サーバーサイドのコンテンツネゴシエーション

サーバーサイドのコンテンツネゴシエーションでは、Acceptヘッダーを検査します。Safari 17以降は、Acceptヘッダーにimage/jxlを送信します。Nginxの構成では、これをファイル拡張子にマッピングします。

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

重要な詳細：CDNやプロキシキャッシュがフォーマットごとに個別のバリアントを保存するように、レスポンスヘッダーには常にVary: Acceptを含めてください。これがないと、キャッシュされたJXLのレスポンスが、それをデコードできないブラウザに配信されてしまいます。

CDNのサポート

CDNのサポートはまちまちです。Cloudinaryは、f_autoパラメータを通じて完全なJPEG XLサポートを提供しています。Cloudinaryがこのフォーマットの共同作成者であり、すでに1日あたり約10億枚のJPEG XL画像を配信していることを考えれば、驚くことではありません。FastlyのImage Optimizerは2024年7月に完全なJPEG XLサポートを追加し、4スレッドでエンコードeffort 3を使用し、JPEGと比較して約60%の節約になると主張しています。Cloudflareは、コミュニティからの強い要望にもかかわらず、そのImage Resizing製品でのJPEG XL変換をサポートしていません。Vary: Acceptを介してオリジンからJXLバリアントをキャッシュすることはできますが、それらを生成することはできません。Cloudflareを使用している場合は、役立つ設定についてCore Web VitalsのためにCloudflareを設定するガイドを確認してください。AWS CloudFront、Akamai、Azureは、ネイティブなJPEG XLサポートを提供していません。

ツール

JPEG XLファイルを生成するためのツールは、libjxlリファレンス実装のcjxlが中心です。主要なパラメータは、距離の-d（0 = ロスレス、Web品質の非可逆の場合は1.0〜2.0）、effortの-e（1〜9、デフォルトは7）、およびプログレッシブエンコードの-pです。JPEG入力の場合、cjxl input.jpg output.jxlはデフォルトでロスレストランスコードを実行します。これは可能な限り最もシンプルな移行パスです。ImageMagick、libvips（8.11以降）、Photoshop v25もJXLをサポートしています。ただし、sharp（Next.jsを駆動するNode.js画像ライブラリ）はv0.31.3以降で実験的なJXLサポートを備えていますが、npm経由で配布されるビルド済みバイナリにはJXLコーデックが含まれていません。libjxlをサポートしたlibvipsを自分でコンパイルする必要があり、メンテナーはビルド済みJXLバイナリのリクエストをクローズしています。これは、Next.jsには実用的なJPEG XLサポートがすぐに使える状態では備わっていないことを意味します。WordPressコアのサポートはチケット #52788として追跡されていますが、本当のブロッカーはPHPのGD拡張機能がJPEG XLをサポートしていないことです。PHP 8.5（2025年11月）でも、依然としてJXLに対するGDサポートが欠けています。

ハロウィンの決定と3年越しの撤回

ChromeにおけるJPEG XLの政治的歴史は、Web標準に対するブラウザベンダーの権力に関するケーススタディです。これを理解することは、どのテクノロジーがユーザーに届くかを形作る力を明らかにするため重要です。

2022年10月31日、すぐに「ハロウィンの決定」というあだ名が付けられた出来事において、GoogleのChromeチームのJim Bankoski氏はJPEG XLの実験的サポートの削除を発表しました。明言された理由は4つありました。実験的なフラグを無期限に残すべきではないこと、エコシステムの関心が不十分であること、既存のフォーマットと比較して漸進的な利点が不十分であること、そしてメンテナンスの負担です。Bankoski氏は、ChromeでJPEG XLを望む人々にとってWebAssemblyが「素晴らしい前進の道」であると提案しました。

反発は即座に起こり、そして持続しました。このChromiumのIssueは、プロジェクトの全歴史の中で2番目に多くスターを獲得し、1,000以上の賛成票（upvotes）と、Intel、Adobe、Meta、Shopify、The Guardian、Flickr、Krita Foundationの代表者からのコメントを集めました。CloudinaryのJPEG XL共同作成者であるJon Sneyers氏は、Googleが公開した比較テストにおいて、バグのあるJPEG XL実装とAVIFに偏った指標が使用されていたことを示す詳細な技術的反論（「The Case for JPEG XL」）を発表しました。フリーソフトウェア財団 (Free Software Foundation)は、Googleの決定はGoogle ChromeがWeb標準の決定者になった証拠であるとし、同社が自社の利益のために行動していると非難しました。AVIFは、Googleが共同設立したAlliance for Open Mediaによって開発されたAV1に由来しているためです。

観察者たちはその皮肉を見逃しませんでした。Google自身がPIKプロジェクトを通じてJPEG XLを共同作成したにもかかわらず、Chromeからそれを削除するという決定は、より一層不可解なものでした。JPEG XLがInterop 2024に向けて提案されたとき、646件のコミュニティの反応を集めました。これは2位の提案の4.5倍です。 それでも、「コンセンサスの欠如」という説明だけで却下されました。

最終的にこの決定を覆したのは、Chromeの不在を擁護できないものにしたエコシステムの勢いでした。2023年9月にAppleがJPEG XLサポートを備えたSafari 17をリリースしたことが、最初の大きな突破口でした。Mozillaが「否定的」から「中立的」へ、そして（Rustデコーダーによる）実装へ積極的に意欲を示すようになったことで、さらに圧力がかかりました。2025年10月にPDF AssociationがJPEG XLをPDFの推奨HDRフォーマットとして発表したことが、転換点になったのかもしれません。Chromeの内蔵PDFビューアーが準拠し続けるには、JXLサポートが必要になるからです。2025年11月21日、Rick Byers氏（Chrome Architecture Tech Lead）は撤回を投稿し、Chromiumにパフォーマンスが高くメモリ安全なJPEG XLデコーダーを統合するための貢献を歓迎しました。2026年1月までにRustベースのjxl-rsデコーダーがマージされ、Chrome 145は2026年2月にそれをフラグ付きでリリースしました。

結論：高品質なソースを保存し、オンデマンドで変換する

JPEG XLは、技術的に見て現在利用可能な最高の汎用画像フォーマットです。実用的なエンコード速度においてAVIFよりも優れた圧縮率、競合他社が提供していないプログレッシブデコード、そして品質を一切損なうことなく即座に20%の節約をもたらすロスレスJPEGトランスコードを備えています。3年間にわたりその採用を阻んできた政治的障害は解消されつつあります。Chromeはツリー内にコードを持ち、Firefoxは同じRustデコーダーを積極的に統合しており、Safariは2023年からサポートをリリースしています。

今後の実用的な道筋は、可能な限り高品質なソース素材を保存し、配信パイプラインにフォーマット変換を任せることです。 ロスレスPNGまたは高品質のマスターJPEGをオリジナルとして保持してください。自動フォーマットネゴシエーションを備えたCDNを使用します。Cloudinaryのf_auto、Fastly Image Optimizer、またはCloudflare Polishは、ブラウザのAcceptヘッダーを検査し、あなたが事前に単一のバリアントを生成することなく、JXL、AVIF、WebP、またはJPEGを配信します。セルフホストする場合は、サーバーサイドキャッシュの背後にlibvipsまたはImageMagickを使用したオンデマンド変換を設定し、事前に画像ごとに4つのバリアントを一括生成するのではなく、最初のリクエスト時にフォーマットごとに1回だけ変換します。JPEG XLのロスレストランスコードは、このモデルに完全に適合します。既存のJPEGがソースであり、それらをJXLに変換することは、実質的に品質劣化ゼロのオンデマンド変換です。残された疑問は、JPEG XLが幅広いブラウザサポートを獲得するかどうかではなく、Chromeがいつデフォルトでフラグをオフからオンに切り替えるかです。そして、唯一の正直な答えは、スケジュールは発表されていないということです。このフォーマットが3年間Chromeから追放されていたという事実は、熱狂を現実主義で和らげるべきです。サポートされている場所ではそれを配信し、他の場所では適切にfallbackさせ、残りはCDNや変換パイプラインに任せましょう。