ページに置いた幅1920ピクセルの画像は、スマホのユーザーも丸ごとダウンロードしたうえで、画面上では390ピクセルに縮小されて表示されます。通信量は5倍に膨らみ、読み込みが遅くなるだけで、何の得もありません。srcsetを使えば、ブラウザが画面に合うバージョンを選んでくれます。ただし、そのバージョンを自分で用意しておくことが前提です。
なぜ画像1枚では足りないのか
Core Web VitalsのLCPは、たいていファーストビューの大きな画像が対象です。スマホに幅1920・400KBのファイルを返すと、LCPが2.5秒に収まることはまずありません。同じ回線で幅480・40KBのバージョンなら、桁違いに速くなります。Googleのページエクスペリエンスのシグナルは、この数値を直接見ています。
逆に、大画面のデスクトップに幅768の画像を表示するとぼやけます。そこで複数のサイズを用意し、選ぶのはブラウザに任せるわけです。
実用的なブレークポイント表
ブレークポイントは、ビューポートの幅ではなく、画像がページ上で実際に表示される幅に合わせます。よくある2つのケース、全幅バナーと記事内の図版で見てみましょう。
- 全幅画像（ヒーロー、バナー）：480、768、1200、1920。スマホ、タブレット、ノートPC、大型ディスプレイに対応します。
- 記事内の図版（コンテンツ列が最大800前後）：400、800、1200。1200は1.5x〜2xの画面向けです。
- サムネイルとカード（表示幅300前後）：300と600。
段階は多ければよいわけではありません。1段増えるごとに書き出しが1回、保存するファイルが1つ増えますし、ブラウザは多少のずれを許容します。段と段の間は1.5〜2倍あけるのがちょうどよい塩梅で、4段あればデバイスの組み合わせの9割以上をカバーできます。
2x版は必要か
Retinaやほとんどのスマホ画面は2x〜3xの密度で、表示幅400の画像をくっきり見せるには800ピクセルが必要です。表の大きい段は、すでに小さい段の2x版として働いています。768は幅390のスマホにとっての2x、1200は幅600のコンテンツ列にとっての2xです。
そのため、別に「@2x」のセットを用意する必要はありません。段の間隔を2倍前後に保てば、ブラウザが密度に応じて大きいほうを選びます。
形式：WebPを主役に、JPGは予備として
同じ画質ならWebPはJPGより25〜35%小さく、現行のブラウザはすべて対応しています。各サイズでWebPを書き出し、古いブラウザ向けにpicture要素でJPGのフォールバックを残すのがおすすめです。2020年より前のブラウザが対象読者にもう関係ないなら、WebPだけでも構いません。
AVIFはさらに小さくなりますが、ブラウザでのエンコードがはるかに遅く、大量のバッチでは割に合いません。トレードオフの詳細はAVIF・WebP・JPEGの比較で解説しています。
一式をまとめて書き出す
元画像を画像一括処理に入れ、段ごとに1回ずつ、幅とサフィックスを変えて実行します。
- サイズ：幅480、「拡大を許可」はオフ、WebP品質80%で出力、サフィックスは-480。
- 同じ設定で768（サフィックス-768）、続いて1200、1920。
- JPGのフォールバックが必要なら、出力をJPGに切り替え、サフィックスはそのままでもう一度実行。
1回の処理は数秒で、できあがるZIPにはhero-480.webp、hero-768.webpといったファイルがそのまま入っており、画像フォルダに置くだけです。「拡大を許可」は必ずオフにしておきましょう。そうすれば、1000ピクセルの元画像が1920まで引き伸ばされることはありません。
1枚の画像で段ごとのサイズ差を確かめたいときは、画像サイズ変更にそのファイルだけ入れて試してみてください。
HTMLに書く
全幅画像の場合：
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">記事内の図版では、sizesを実際の幅に合わせて指定します。例：sizes="(max-width: 840px) 100vw, 800px"。widthとheightは必ず入れてください。ブラウザが場所をあらかじめ確保するので、ページがガタつきません。
ここまで済んだら、画像の読み込みを速くする方法にある遅延読み込みと圧縮のアドバイスを加えれば、パフォーマンススコアのうち画像に関わる部分はほぼ満点です。