画像はたいていページで最も重いものであり、それゆえ自分で握れる最大の速度のてこです。寸法とファイル容量を正しくすればページは瞬時に感じられます。間違えれば、どれだけコードがきれいでもCore Web Vitalsに落ちます。ここに目標と、それを達成する手順を示します。
寸法の目標
画像のピクセルサイズを、実際に表示される場所に合わせます。おおよその目安です。
- 全幅のヒーロー画像： 1600〜2000 px幅でほとんどのデスクトップレイアウトをまかなえます。これより広くしてもまず役立たず、多くのバイトを食います。
- 本文中の写真： コンテンツ列の幅、一般的には800〜1200 px。
- サムネイル／カード画像： 300〜500 px。
- アバター／アイコン： 表示サイズで48〜200 px。
4000pxの画像を800pxの枠に出すと、ブラウザは表示する25倍のピクセルをダウンロードしてデコードします。純粋な無駄であり、大きな画像のデコードはメインスレッドをカクつかせもします。
容量の目標
寸法が上限を決め、圧縮が実際の容量を決めます。目安は次のとおり。
- ヒーロー画像： 200 KB未満（理想は100〜150 KB）。
- 本文中の写真： 80〜150 KB。
- サムネイル： 10〜30 KB。
- ページあたりの画像合計： ページ全体で約1 MB未満に収めるよう努める。
1枚の画像が約300 KBを超えたら、調べるべきバグとして扱いましょう。
なぜこれがCore Web Vitalsを左右するのか
GoogleのLargest Contentful Paint (LCP) は、画面上で最大の要素が描画されるまでの時間を測ります。そしてほとんどのページで、その最大の要素は画像（たいていヒーロー）です。重く大きすぎるヒーローはLCPを直接押し上げます。良いLCPは2.5秒未満で、肥大したヒーローはモバイル回線でそれだけで軽々と超えてしまいます。
もう2つ、画像関連の勝ち筋。
- width属性とheight属性を設定し、ブラウザに場所を確保させます。これがCumulative Layout Shift (CLS) スコアを守ります。
- ヒーローを優先（LCP画像を遅延読み込みしない）し、ファーストビューより下はすべて遅延読み込みします。
2ステップの手順
ステップ1 — 実際の表示幅にリサイズ。 画像リサイザーを使い、各画像を表示されるサイズまで下げます。縦横比ロックをオン、高品質縮小で。これだけで容量が80〜90%減ることがよくあります。
ステップ2 — 圧縮。 リサイズしたファイルを画像コンプレッサーへ。写真は品質75〜85（見た目上は無劣化）、PNGは256色量子化。元より大きなファイルは決して出力せず、一括処理に対応し、任意の幅上限があるので、実質2ステップを一度に行えます。現代のブラウザ向けには、写真をWebPに変換するとさらに25〜35%絞り出せます。
推測せず、測る
画像を最適化したら、ページが実際に速くなったか確かめましょう。IMG.DIYのページQAは公開URLをGoogle PageSpeed Insights経由で監査し、ページの画像容量を報告するので、まだ重すぎるファイルを見つけられます。1つ注意点。ページQAにはインターネット接続が必要です。画像ツールと違い、GoogleのPageSpeed APIを呼ぶので、オフラインでは動きません。デプロイ後に使い、実際のLCPと画像予算を確認しましょう。
既定でプライベート
リサイズ・圧縮・変換の各ツールは、CanvasとWebAssemblyを使って完全にブラウザ内で動きます。何もアップロードされず、初回アクセスのあとキャッシュされてオフラインで動きます。接続なしでサイト1つ分の画像をまるごと準備し、ページが公開されたらオンラインでページQAを実行できます。
手早いおさらい。寸法を適正サイズにし、容量の目標まで圧縮し、LCPのためにヒーローを優先し、ページQAで検証する。