画像の最適化 — WebP・遅延読み込み・サイズ指定

画像はページ転送量の大半を占めるため、その最適化は表示速度に最も効きます。やることは決まっていて、WebP や AVIF で軽くし、srcset で表示サイズに合った画像を配り、折りたたみより下は遅延読み込み、逆にファーストビューの LCP 画像は優先読み込み、そして width/height を指定してレイアウトのずれを防ぎます。

執筆: JIT株式会社公開: 2026年7月17日

なぜ画像の最適化が必要なのですか？

画像はページ全体の転送量の大部分を占めることが多く、ここを軽くするのが表示速度改善の近道だからです。テキストや CSS をいくら削っても、数 MB の画像が 1 枚あれば台無しになります。フォーマット変換・適正サイズ配信・遅延読み込み・寸法指定という定番の対策を順に当てれば、体感速度も Core Web Vitals も大きく改善します。

多くのサイトで、ページの転送量の内訳を見ると画像が過半を占めています。HTML や CSS、JavaScript は頑張って数十 KB を削れますが、書き出し設定を見直していない写真は 1 枚で数 MB になることがあり、桁が違います。つまり表示速度を上げたいなら、まず画像から手を付けるのが費用対効果として最も高いのです。

画像の最適化がうまくいくと、次のような効果が同時に得られます。

読み込みが速くなる — 転送量が減り、回線の細い環境でも早く表示が始まる
LCP が改善する — ファーストビューの主役画像が軽く・速く出れば、Core Web Vitals の LCP に直接効く
レイアウトが安定する — 寸法を先に確保すれば、画像の到着で文章が飛ぶ CLS を防げる

やることは大きく分けて 5 つ、フォーマット・適正サイズ・遅延読み込み・寸法指定・圧縮/CDN です。以下で順に見ていきます。なお、画像の alt（代替テキスト）はアクセシビリティと画像検索の話で、速度とは別テーマなので、そちらは alt 属性の正しい書き方を参照してください。

どの画像フォーマットを使うべきですか？

写真は WebP、透過やロゴは WebP か PNG／SVG、というのが基本方針です。WebP や AVIF は JPEG・PNG より同じ見た目で大幅に軽く、対応ブラウザも十分に広がっています。写真系は WebP（さらに軽い AVIF も選択肢）、透過が要る画像は WebP か PNG、単純な図形やアイコンは SVG、と中身で使い分けます。

同じ見た目でも、フォーマットを変えるだけでファイルサイズは大きく変わります。写真を JPEG のまま置いているなら、WebP に変えるだけで多くの場合 3〜4 割ほど軽くなります。さらに軽い AVIF という選択肢もありますが、書き出し（エンコード）に時間がかかるため、静的な書き出しか変換サービス経由での利用が現実的です。

主な画像フォーマットの得意分野
フォーマット	得意な用途	特徴
`WebP`	写真・透過画像・全般	JPEG/PNG より軽く、透過もアニメも可。対応ブラウザは広く、まず第一候補
`AVIF`	写真	WebP よりさらに軽いことが多い。エンコードは重めで、静的書き出し向き
`JPEG`	写真（フォールバック）	互換性が最も高い。WebP/AVIF が読めない環境の受け皿として残す
`PNG`	透過・図・スクショ	劣化しない可逆圧縮だが重い。写真には不向き
`SVG`	ロゴ・アイコン・図形	ベクターなので拡大しても劣化せず、多くの場合とても軽い

「新しい形式が読めない環境が心配」という場合は、<picture> で複数の形式を並べておけば安全です。ブラウザは上から順に、自分が対応する最初の形式を選び、どれも読めなければ最後の <img> にフォールバックします。

picture でフォーマットを段階的に指定する

<!-- AVIF → WebP → JPEG の順に、ブラウザが対応する最初の形式を選ぶ。
     どれも読めない古い環境でも、最後の <img> が確実に表示される -->
<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="製品の外観写真" width="800" height="600">
</picture>

適正なサイズで配信するにはどうすればいいですか？

表示サイズに合った画像を配ることが重要で、srcset と sizes で解像度ごとに出し分けます。横 400px で表示する枠に 2000px の画像を入れて縮小表示するのは、無駄な転送そのものです。srcset に複数の幅を並べ、sizes で実際の表示幅を伝えれば、ブラウザが画面に応じて最適な 1 枚を選びます。

フォーマットの次に効くのが「大きすぎる画像を配らない」ことです。スマホの横幅いっぱい（実質 400px 前後）で表示するサムネイルに、元の 3000px の写真をそのまま置き、CSS で縮めているサイトは珍しくありません。見た目は同じでも、ブラウザは巨大な元画像をまるごとダウンロードしているため、転送量は何倍にもなります。

解決策が srcset と sizes です。同じ画像を複数の幅で用意して srcset に列挙し、sizes で「この画像は実際どのくらいの幅で表示されるか」を伝えます。あとはブラウザが、画面幅と端末の解像度から最も無駄のない 1 枚を自分で選んでダウンロードします。

srcset / sizes でレスポンシブに出し分ける

<!-- 同じ画像を複数の幅で用意し、sizes で「実際の表示幅」を伝える。
     ブラウザは画面幅と解像度から、srcset の中の最適な 1 枚を自分で選ぶ -->
<img
  src="/hero-800.webp"
  srcset="/hero-400.webp 400w,
          /hero-800.webp 800w,
          /hero-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450"
  alt="トップページのメインビジュアル">

sizes の (max-width: 600px) 100vw, 800px は、「画面幅 600px 以下ならビューポート幅いっぱい、それ以外は 800px で表示する」という意味です。この情報があるからこそ、ブラウザは小さい画面に大きな画像を選ばずに済みます。

遅延読み込み（lazy）はどの画像に付けますか？

折りたたみより下の画像に loading="lazy" を付け、逆にファーストビューの LCP 画像には付けないのが正解です。lazy は画面外の画像の読み込みを後回しにして初期表示を速くしますが、最初に見える主役の画像まで遅延させると LCP がかえって悪化します。主役は fetchpriority="high" や preload でむしろ優先します。

loading="lazy" を付けた画像は、画面に近づくまで読み込みが後回しになります。記事の下のほうにある画像を最初から全部ダウンロードする必要はないので、折りたたみ（ファーストビュー）より下の画像には積極的に付けて構いません。初期表示に不要な通信が減り、体感が速くなります。

ただしここに一つ、必ず守るべき例外があります。ページを開いて最初に目に入る主役画像 ——多くの場合これが LCP（最大コンテンツの描画）の対象——を lazy にしてはいけません。遅延読み込みは「後回し」の指示なので、主役を後回しにすれば LCP はむしろ遅くなります。主役は逆に、fetchpriority="high" や <link rel="preload"> で優先的に読ませます。

下の画像は lazy、LCP 画像は優先

<!-- 折りたたみより下の画像: 読み込みを後回しにして初期表示を速くする -->
<img src="/section3.webp" alt="機能の紹介" width="640" height="360" loading="lazy">

<!-- ファーストビューの LCP 画像: lazy にせず、むしろ優先で読ませる -->
<img src="/hero.webp" alt="メインビジュアル" width="1200" height="600" fetchpriority="high">

<!-- さらに、<head> 内で先読みしておくと表示開始が早まる -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

width と height を指定するのはなぜですか？

画像に width と height（または CSS の aspect-ratio）を指定しておくと、読み込み前からブラウザが表示領域を確保でき、レイアウトのずれ（CLS）を防げるからです。寸法が無いと、画像が届いた瞬間に下の文章が押し下げられ、読んでいた場所がずれます。実寸のピクセル値を属性で書けば、この飛びはほぼ無くせます。

画像に width と height を書かないと、ブラウザは読み込みが完了するまで画像の大きさが分かりません。そのため最初は高さ 0 の隙間として扱い、画像が届いた瞬間に本来の高さへ広がって、下の文章を一気に押し下げます。読んでいた行が急に下へずれるあの現象が、レイアウトシフト（CLS）です。

対策は単純で、実寸のピクセル値を width / height 属性に書くだけです。 CSS で表示サイズを変えても、この 2 つの属性から縦横比が伝わるので、ブラウザは読み込み前に正しい高さの場所を確保できます。背景画像や、高さが可変になるレイアウトで属性を書けない場合は、CSS の aspect-ratio で比率を先に確保します。

属性が書けない場合は aspect-ratio で比率を確保

/* width/height 属性を書けない場面（背景・レスポンシブで高さ可変）は
   CSS の aspect-ratio で縦横比を先に確保すると、CLS を防げる */
.thumb {
  width: 100%;
  aspect-ratio: 16 / 9; /* 高さを比率で確保しておく */
  object-fit: cover;
}

CLS の考え方や測り方そのものは、Core Web Vitals の解説で詳しく扱っています。画像の寸法指定は、その中でも最も費用対効果の高い CLS 対策です。

圧縮や CDN 配信はどれくらい効きますか？

配信前に画像を適切に圧縮し、できれば CDN から配ると、転送量と距離の両方を短縮できて効果は大きいです。書き出し時の品質を少し下げるだけで、見た目をほぼ保ったままファイルサイズは大きく減ります。加えて CDN は利用者に近い拠点から配信するため、遠方からのアクセスでも読み込みが速くなります。

フォーマットとサイズを整えたら、最後に圧縮の品質を見直します。写真の書き出し品質を 100% から 75〜85% 程度に下げても、見た目の違いはほとんど分からない一方で、ファイルサイズは大きく減ることが多いです。画質と容量はトレードオフなので、実際に画面で見比べて許容できる下限を探します。

さらに、画像を CDN（コンテンツ配信ネットワーク）から配ると、利用者に地理的に近い拠点から届くため、遠方からのアクセスでも待ち時間が短くなります。多くの CDN や画像配信サービスは、アクセス端末に応じた WebP/AVIF 変換やリサイズも肩代わりしてくれるので、ここまでの対策をまとめて任せられる場合もあります。

画像が最適化できているか、どう確認しますか？

ブラウザの開発者ツールのネットワークタブで、各画像の実転送サイズと表示サイズを見比べるのが基本です。表示 400px の枠に巨大画像が来ていないか、ファーストビュー画像が lazy になっていないか、寸法属性が付いているかを確認します。本ツールの診断でも、画像に関わる指標や Core Web Vitals を実測できます。

確認の起点は、ブラウザの開発者ツールのネットワークタブです。ページを再読み込みして画像を種類で絞り込み、次の点を上から順に見ていきます。

重い画像はどれか — 転送サイズの大きい順に並べ、突出して重い 1 枚がないか
表示サイズと元サイズの差 — 400px の枠に 2000px の画像が来ていないか（縮小表示の無駄）
フォーマット — 写真が JPEG/PNG のままで、WebP/AVIF になっていないか
LCP 画像が lazy になっていないか — 最初に見える主役が優先で読まれているか
寸法属性の有無 — width / height が付いていて、読み込み中に文章が飛ばないか

これらは一つずつ手で確認できますが、ページ全体でどれだけ効いているかは実測が確実です。本ツールの診断では、画像に関わる指標や Core Web Vitals を URL を入れるだけで計測できます。直したあとにもう一度かけて、LCP と CLS の数値が改善したかを見比べてください。