ChromeがJPEG XLに対応｜写真の画質比較と段階導入の進め方

Chromeチームは2026年10月6日、Chrome 155からJPEG XLのデコードに対応すると発表しました。写真を多く扱うWebサイトでは、従来のJPEGやAVIFに加えて、JPEG XLを配信候補へ入れる判断材料になります。ただし、拡張子を一括で置き換えるだけでは導入できません。対象ブラウザー、変換処理、配信経路、画質を一組で検証する必要があります。

本稿は2026年10月27日に確認した公式資料に基づく動向解説です。JPEG XLの高画質用途での価値と、既存の画像配信へ小さく追加する方法を扱います。以下の比較手順と運用基準は本サイトの提案であり、実測結果ではありません。まず代表的な写真で試し、効果と運用負担が見合う範囲から採用してください。

2026年10月29日追記：Chrome公式発表が提供範囲として示しているのは、Chrome 155以降のJPEG XLデコード対応です。これは配信された画像を読み込む側の機能であり、CMSへJPEGをアップロードするとJPEG XLが自動生成されるという発表ではありません。導入時は、閲覧側の対応確認と、制作・サーバー側のエンコーダーや派生画像生成の準備を別々に進めてください。

JPEG XLを検討する理由を画像の用途から決める

発表の根拠はChrome公式の「Shipping JPEG XL in Chrome」です。Chromeチームは、AVIFとJPEG XLの両方を試すことを勧め、特に高忠実度や可逆圧縮の写真、細かな段階的デコードが望ましい用途でJPEG XLが有用としています。これは、すべての画像で一方が優れるという結論ではありません。

検討の出発点は、どの写真にどの品質が必要かです。商品写真なら素材の質感や色、作品紹介なら細部、記事の小さなサムネイルなら輪郭の分かりやすさが優先されます。同じファイル容量でも、失いたくない情報は用途によって異なります。圧縮率の宣伝値だけで形式を決めず、掲載場所ごとに受け入れる品質を決める方が比較を進めやすくなります。

今回のChromeの変更を、すべてのブラウザーやアプリ内WebViewの対応完了と読み替えないことも重要です。サイトの訪問者が使う実際の版を確認し、対応しない環境へ従来形式を残します。公開サイトでは利用者へブラウザー更新を強制しにくいため、対応環境だけが新形式を選べる構成にして、未対応環境の表示を維持するのが現実的です。

最初の比較では形式以外の条件をそろえる

検証用の画像は、日常的に掲載する素材から選びます。風景、人物、細かな布や髪、暗部のある写真、文字を含む画像など、劣化が見えやすい種類を含めます。一枚の写真だけで全体の採否を決めると、その素材に有利な条件をサイト全体へ広げてしまいます。制作担当者が普段困る素材を混ぜると、運用上の意味がある比較になります。

書き出し前の原画像を共通にし、縦横寸法、切り抜き、色の扱いをそろえます。既存JPEGを再圧縮したものと高品質な原画像から作ったものを比べると、形式の差と入力素材の差を区別できません。変換ツールの版と設定も記録し、後から同じ候補を作り直せるようにします。元画像を上書きせず、形式別の派生物として保存してください。

品質設定の数値は、異なるエンコーダー間で同じ見た目を意味するとは限りません。品質80同士だから公平とせず、実際の掲載サイズと拡大表示の両方で、許容する見た目に合わせます。そのうえで容量と処理時間を比べます。見た目を合わせず容量だけ比べると、品質を落とした効果を形式の改善として受け取るおそれがあります。

色の評価には表示環境も関係します。担当者の一台だけで確認せず、主要なスマートフォンとデスクトップで、肌色、暗いグラデーション、細い模様などを確認します。HDRなど通常と異なる表現を採用する場合は、対応画面と非対応画面の見え方を別に扱います。機能が形式に存在することと、現在の制作・配信経路で保持できることは同じではありません。

pictureでJPEG XLを追加し従来画像を残す

形式別の候補をHTMLへ明示する方法としてpictureを使えます。WHATWGのHTML Standardでは、pictureが内側のimgへ複数の画像ソースを提供し、sourceのtypeが未対応形式を読み飛ばすための情報になると定義されています。以下は同じ構図・寸法の画像を用意した場合の実装例です。

<picture>
  <source srcset="/images/gallery-1280.jxl" type="image/jxl">
  <source srcset="/images/gallery-1280.avif" type="image/avif">
  <img src="/images/gallery-1280.jpg"
       width="1280" height="853"
       alt="窓から自然光が入る木製家具の展示室">
</picture>

この例ではJPEG XLを先に提示し、その次にAVIF、最後にJPEGを置いています。三形式の中からブラウザーが最小容量を測って自動選択する指定ではありません。先に置く形式は、自分たちの画質比較と配信方針に合わせて決めます。AVIFを先にしたい用途なら順番を変え、形式ごとの採用理由をコンポーネントの仕様へ残してください。

画像パスは説明用で、実在する成果物へ差し替える必要があります。拡張子だけを変えたファイルではなく、対応するエンコーダーで作成した画像を配置します。widthとheightも実際の比率へ合わせます。代替テキストはimgで管理し、どの形式が選ばれても同じ内容を伝えるようにします。形式追加を理由に画像の意味や構図まで同時に変えない方が検証は簡単です。

ここでのフォールバックは、対応形式の選択に関するものです。選ばれたJPEG XLのURLが404だったり、ファイルが壊れていたりする場合に、必ず次の形式を再試行してくれる仕組みとして扱わないでください。未対応環境でJPEGが表示される確認と、対応環境でJPEG XLを正常に取得・デコードできる確認は、別々に実施します。

CMSとCDNが同じファイルを返しているか確認する

ローカルのHTMLで表示できても、CMSやCDNを通ると結果が変わることがあります。画像アップロード時の許可形式、派生画像の生成、保存先のファイル名、配信時のContent-Typeを順に確認します。管理画面がアップロードを受け付けたことだけで、公開ページまで正しい形式が保たれたと判断しないことが大切です。

最初は形式ごとに別URLを用意すると、何が配信されたかを追いやすくなります。同じURLからリクエスト条件で形式を変える構成は便利ですが、キャッシュの分離を含めた設計が必要です。既存の自動最適化サービスがJPEG XLをそのまま通すのか、別形式へ変換するのかも確認します。導入検証では、自動処理を通した後の成果物を実際に取得して比べてください。

画像の更新時は、JPEG XLだけが古いまま残らないようにします。原画像の変更から全形式の生成、アップロード、HTMLの参照更新までを一つの公開手順にします。変換が失敗した派生物へのsourceを先に公開すると、対応ブラウザーの利用者だけが画像を失うことがあります。必要なファイルがそろってから参照を切り替える順序が扱いやすいでしょう。

保存容量にも注意が必要です。形式を一つ増やすと、解像度候補の数だけ派生ファイルが増えます。容量削減の成果を利用者への転送量だけで評価せず、生成時間、保存量、キャッシュ、削除の手間も含めます。頻繁に差し替える画像と、長く使う高品質写真では、追加形式を維持する価値が異なる場合があります。

currentSrcとNetworkで選択結果を調べる

const image = document.querySelector('picture img');
console.table({
  selectedUrl: image.currentSrc,
  complete: image.complete,
  naturalWidth: image.naturalWidth,
  naturalHeight: image.naturalHeight
});

これは対象画像を一枚選んで状態を表示する確認例です。currentSrcで選択されたURLを読み、開発者ツールのNetworkでレスポンス、Content-Type、転送量を照合します。completeだけで成功と判定せず、表示と自然寸法も確認してください。画像の読み込み途中に実行すれば結果が変わるので、読み込み後に観察し、必要ならloadとerrorも記録します。

まずJPEG XLを扱える環境で想定するURLが選ばれるかを見ます。次に未対応環境で従来形式が選ばれ、画像の意味とレイアウトが保たれるかを確認します。ブラウザー名だけでなく版、OS、実機かエミュレーションかも記録します。利用者の環境を代表する組み合わせで試すことが、開発端末だけの成功を本番全体の成功と取り違えないための条件になります。

キャッシュありとなしの測定は分けます。すでに取得済みの画像なら、形式の違いよりキャッシュの状態が転送量や表示時間へ大きく影響します。初回訪問の比較では同じ通信条件にし、再訪時には適切に再利用されるかを確認します。一回の最速値を採用理由にせず、同じ条件で複数回記録して、ばらつきも判断材料にします。

容量だけでなく表示と制作の負担まで評価する

転送量が減っても、利用者が主画像を見るまでの時間が改善するとは限りません。画像の発見時点、取得優先度、デコード、描画など、ページ全体の経路が関わるからです。JPEG XLを入れる前後で主画像の表示とLCPを観察し、同時に他の最適化を大量に混ぜないようにします。形式変更の効果を説明できる比較条件を保つことが重要です。

段階的なデコードを評価する場合は、最終的な見た目だけでなく、読み込み途中にどの程度の内容が見えるかを観察します。ただし、書き出したファイルや実際の配信条件でその挙動を確認していなければ、形式の機能説明をそのまま自サイトの効果としないでください。低速回線での体験と高速回線での完了時間は、別々の評価として扱えます。

制作担当者にとっては、変換失敗時の再実行や元画像の探しやすさも品質の一部です。担当者が手作業で三形式を作っているなら、どの設定を使ったかが次回も分かる状態にします。自動処理ならエラーを通知し、不完全な派生物を公開しない条件を決めます。転送量の改善だけでは、更新するたびに起きる作業負担を正当化できない場合があります。

一部の写真から導入して戻せる状態を保つ

初回は写真中心の一ページや一つの画像コンポーネントへ絞ります。切り替え前のHTMLと従来画像を残し、表示失敗、色の変化、想定外の容量増加があればsourceを外して戻せるようにします。原画像やJPEGを削除してから問題を調べる運用は避けます。利用者が見る状態を早く戻せる構成なら、原因調査と公開復旧を分けられます。

採用基準には、対象ブラウザーでの表示成功、未対応環境の表示維持、同等の視覚品質、許容する生成時間、確認できた転送量の変化を含めます。何％減なら合格かは、画像の用途と運用コストに合わせて事前に決めてください。改善しない素材へ無理に適用せず、効果があった用途だけ残す方法でも構いません。

Chromeの対応は、新しい配信候補を実際の制作工程へ組み込む機会です。すべての画像を一斉に置き換えるより、品質を保つ必要がある写真で、形式選択から配信結果までを小さくつなぐ方が判断を具体化できます。公式発表の利点と、自分のサイトで確認した結果を分けて記録し、素材や利用者の環境が変わったときに再評価できる運用へつなげましょう。

関連記事

形式を選んだ後の解像度候補と表示幅の設計は、レスポンシブ画像のsrcsetとsizesの解説を参照してください。形式の比較と表示幅の最適化を分けて検証すると、改善の理由を追いやすくなります。

参考資料

Chrome for Developers：Shipping JPEG XL in Chrome（2026年10月6日）
WHATWG HTML Standard：picture・source・img