スマートフォンで自社サイトのトップページを開くと、写真が上から順にじわじわと現れる。社内の回線では気にならなかったのに、外出先だと明らかに待たされる。計測ツールにかけると、ページの総容量のうち9割近くが画像でした。
こうしたとき、制作会社に相談すると「WebP にしましょう」という返答が返ってきます。これは概ね正しい答えです。ただ2026年に入って、画像形式の状況は少し動きました。判断材料が増えたぶん、先に効く手を飛ばして形式の議論から入ってしまうことも起きやすくなっています。
形式を変える前に、たいてい別の原因がある
画像が重いサイトを実際に開いて中身を見ると、最も多いのは形式の問題ではありません。4,000ピクセル幅の元画像を、そのまま貼って、表示側で小さく縮めているケースです。
スマートフォンの画面に幅400ピクセルで表示される写真に、4,000ピクセルの画像を送っている。この状態では、形式をどれに変えても効果は限定的です。まず送る量を減らすほうが桁違いに効きます。
- 表示される寸法に合わせて書き出す。 表示幅の2倍程度あれば高解像度ディスプレイでも十分です
- 画面外の画像は後から読む。
loading="lazy"を付けるだけで、最初に読み込む量が減ります - そもそも要らない画像を消す。 装飾目的の大きな背景写真は、削除が最も確実な高速化です
このあたりを片付けたうえで、まだ重いなら形式の出番です。読み込みを軽くする考え方全体は要らなくなったJavaScriptとサイト速度でも触れています。
3つの形式は、得意分野が違う
写真を載せる目的で使える形式は、実務上3つです。
| 形式 | ブラウザ対応 | 得意なもの | 実務上の位置づけ |
|---|---|---|---|
| WebP | ほぼ全ブラウザ | 写真・イラスト全般 | 迷ったらこれ。既定の選択肢 |
| AVIF | 主要ブラウザで利用可 | 写真、特に大きなもの | 圧縮率重視。書き出しは重い |
| JPEG XL | Safari のみ既定有効 | 写真・既存JPEGの再圧縮 | 単独では使えない。併記で使う |
WebP は対応が行き渡っており、同じ見た目なら JPEG より小さくなります。現時点で「これ1つにしておけば困らない」形式です。
AVIF は同じ画質ならさらに小さくできます。特に大きな写真で差が出ます。一方で書き出しに時間がかかり、CMS やビルド環境によっては変換が現実的でないこともあります。画像が主役のサイト（宿泊、飲食、物販）では検討する価値があります。
JPEG XL は圧縮性能では最も有望とされますが、2026年8月時点では配信の主軸にできません。 理由は次の通りです。
JPEG XL は「既定で有効」がまだ揃っていない
JPEG XL は一度 Chrome から削除された経緯があり、その後の動きが分かりにくくなっています。2026年8月時点の状況を整理すると、こうなります。
- Safari — Safari 17（2023年）以降、既定で表示できます。ただしアニメーションとプログレッシブ表示には未対応です
- Chrome — 2026年1月に Rust 実装のデコーダ jxl-rs が Chromium に取り込まれ、Chrome 145 で搭載されました。ただし既定は無効で、
chrome://flagsでの有効化が必要です - Firefox — Mozilla が Firefox 157 で全プラットフォーム既定有効にする計画を公表しました。157 は9月末のリリース予定です
つまり、Firefox 157 が出た後でも、シェアの大きい Chrome が既定オフのままという状態が続きます。JPEG XL だけで画像を配信すると、Chrome の利用者には画像が表示されません。
ここで押さえておきたいのは、これが「まだ早い」だけであって「使えない」ではないことです。フォールバックを併記する形なら、今日から入れて損はありません。 対応済みのブラウザには軽い画像が届き、そうでないブラウザには従来の画像が届きます。
併記の書き方は1つ覚えれば済む
複数形式を併記するには <picture> を使います。ブラウザは上から順に見て、自分が表示できる最初のものを選びます。
<picture>
<source srcset="/images/hero.jxl" type="image/jxl">
<source srcset="/images/hero.avif" type="image/avif">
<source srcset="/images/hero.webp" type="image/webp">
<img src="/images/hero.jpg" alt="工場の外観" width="1200" height="800" loading="lazy">
</picture>最後の <img> は、どの <source> にも当てはまらなかったときの受け皿であり、alt テキストや寸法の指定はここに書きます。 width と height を入れておくと、読み込み中にレイアウトがずれる現象を防げます。
注意点として、この書き方は同じ画像を形式の数だけ用意することを意味します。 手作業でやる運用にすると必ず破綻するので、CMS の自動変換機能か、ビルド時に生成する仕組みのどちらかに載せてください。手で3種類作って手で貼る運用は、3ヶ月後には誰もやらなくなります。
発注と検収で見るところ
サイト制作やリニューアルを依頼する側が確認するのは、形式の名前ではなく次の3点です。
- 画像の書き出しは自動か、手作業か。 記事を追加するたびに担当者が3形式を書き出す運用になっていないか。自動でないなら、更新のたびに重い画像が混ざり始めます
- フォールバックが入っているか。 新しい形式を使うなら
<picture>での併記になっているか。単独指定だと、一部の利用者に画像が出ません - 表示寸法と画像寸法が合っているか。 ブラウザの検証ツールで画像を選ぶと、実際のファイル寸法と表示寸法の両方が見えます。ここが極端に離れていれば、形式以前の問題です
3つ目は納品後でも自分で確認できます。制作会社を疑うためではなく、「更新を続けても重くならない状態か」を見るための確認です。図解やアイコンのように写真ではない画像は、そもそもこの3形式ではなくテキストのまま編集できるSVGで受け取るほうが、容量でも更新のしやすさでも有利になります。画像を差し替える運用が始まってから重くなるサイトは多く、その原因はたいてい形式ではなく運用側にあります。
次にやること
まず、自社サイトで最も重いページを1つ選んで、画像の合計サイズを見てください。 ブラウザの検証ツールのネットワークタブで、画像だけを絞り込めば数分で分かります。2MB を超えていれば、まず削減の余地があります。
そのうえで、画像の書き出しが自動化されているかを制作会社に確認してください。 自動化されているなら、JPEG XL の追加は将来的に設定1つで済みます。されていないなら、形式の追加より先にそこを直すほうが効きます。
サイトの表示速度改善、画像配信の設計、リニューアル時の運用設計については、グリームハブの HP 制作・リニューアル相談で承っています。現在の構成と更新体制によって取れる手が変わるため、個別にご相談ください。お問い合わせからどうぞ。
