画像最適化完全ガイド：Webサイトのパフォーマンスを実質的に改善する実践手法

画像を圧縮したのに、ページの表示はあまり速くならない。反対に、容量は小さくなったものの、図の文字が読めなくなった。画像最適化では、何を伝える画像か、どの大きさで、いつ届けるかを一緒に考えます。

表紙は表示先による構図の違いを表すAI生成の概念イラストです。実際のブラウザ表示や速度測定結果ではありません。

30秒で要点

• 写真・図解・スクリーンショットでは、守りたい画質が違う。形式は用途から選ぶ。
• 表示幅と画像ファイルの幅は別。画面密度も踏まえて、複数の候補を用意する。
• 先頭の主要画像は早く届け、本文の下にある画像は必要な時期まで遅らせる。
• 容量の削減率、LCP、読めるかどうかを別々に確認する。容量80%減は表示時間80%減を意味しない。

圧縮の前に、画像の役割と置き場所を決める

画像の仕事は、ページを飾ることだけではありません。商品写真なら形や質感を伝え、操作画面なら押す場所を示し、図解なら複雑な関係を短時間で理解できるようにします。まずは一枚ごとに、読み手が何を分かればよいのかを決めます。

そのうえで、最初の画面で必要な画像か、下まで読んだときに必要な画像かを分けます。LCPは、最も大きな画像や文章が画面に描画されるまでの時間です。LCPの対象が画像なら、容量だけでなく、ブラウザがその画像をいつ見つけ、いつ表示できるかも影響します。LCPの改善ガイド

表が収まらない場合は、横にスクロールできます

図の重要な情報は、近くの本文でも説明します。代替テキスト（alt）は画像を見られない場合の意味を伝え、キャプションは図の条件や読み方を補います。「画像1」「図解」という名前だけでは、読み手に役割が伝わりません。

形式は「新しさ」ではなく内容で選ぶ

Webで一般的に使うJPEGは非可逆圧縮です。情報の一部を捨てて小さくするため、保存時の設定によっては文字の輪郭などがにじみます。PNGは元の情報を保つ可逆圧縮です。WebPには両方の方式があります。MDNの画像形式ガイド

表が収まらない場合は、横にスクロールできます

SVGは形や線の情報で画像を表します。図解と相性がよい一方、写真のような複雑な内容には画素で表す形式が向きます。

AVIFは2026年10月3日時点のMDNではChrome・Edge・Firefox・Safariなどに対応しています。「対応ブラウザがごく限られた実験的形式」として一律に除外する前提は古くなりました。ただし、訪問者が使う古い環境や組み込みブラウザまで含めて一律に対応済みとは言えません。必要ならpictureで代替形式を用意します。形式と対応状況

「WebPにすれば30%軽い」「AVIFなら最小」という固定の期待値は置かず、自分の画像で比較します。もともと強く圧縮された小さな画像なら、変換の効果が小さい場合もあります。比較の基準は同じ設定値ではなく、必要な情報が同じように読めることです。

表示する幅と、届ける画像の幅をそろえる

画面上で横360pxに見える画像に、横3,000pxの写真をそのまま配る必要があるとは限りません。一方、幅360pxの画像だけを用意すると、高密度の画面で粗く見える場合があります。

ここで区別するのは、CSSで指定する表示幅と、ファイルに含まれる画素数です。表示幅360CSS px、画面密度2の端末なら、横720px程度の候補を検討する、という考え方になります。これは寸法を理解するための計算例であり、その画像をブラウザが常に選ぶという保証ではありません。実際の選択には画面密度や環境も関係します。レスポンシブ画像の仕組み

srcsetは候補、sizesは表示幅のヒント

srcsetには用意した画像とその横幅、sizesには画面条件ごとの表示幅を指定します。次の例は、本文が最大800px、狭い画面では左右16pxずつ余白を取るレイアウトです。画像ファイルは同じ縦横比で用意します。

<img
  src="guide-800.webp"
  srcset="guide-480.webp 480w, guide-800.webp 800w, guide-1600.webp 1600w"
  sizes="(max-width: 832px) calc(100vw - 32px), 800px"
  width="1600"
  height="1000"
  loading="lazy"
  alt="問い合わせが受付、確認、回答へ進む流れ"
  style="display: block; width: 100%; max-width: 800px; height: auto;"
/>

480wは、候補ファイルの実際の横幅が480pxであることを示します。sizesを広く書きすぎると、実際には小さな欄の画像に大きな候補が選ばれる原因になります。逆に狭く書きすぎると、必要な画質を得にくくなります。レイアウトの変更時は、この指定も見直します。

widthとheightは、この例では元画像の比率をブラウザに伝える役割もあります。CSSの幅を変えて表示しても、読み込み前に高さを見積もれるため、本文が後から押し下げられることを抑えられます。画像寸法とCLS

pictureで形式や構図を切り替える

同じ写真をAVIF・WebP・JPEGで用意するときは、次のように候補を示せます。コードは一つの寸法で形式を切り替える例です。画面幅に応じた寸法も変える場合は、各sourceに対応するsrcsetとsizesを設定します。

<picture>
  <source srcset="workspace.avif" type="image/avif" />
  <source srcset="workspace.webp" type="image/webp" />
  <img
    src="workspace.jpg"
    width="1200"
    height="800"
    loading="lazy"
    alt="壁側に作業机、中央に打ち合わせ席を配置したオフィス"
    style="max-width: 100%; height: auto;"
  />
</picture>

pictureは、スマートフォンだけ主役を大きく切り取った構図にする場合にも使えます。これは画像を単に縮める操作と違います。人物や操作対象が小さすぎるなら、容量調整の前に切り取り方を変えたほうが理解しやすくなります。MDNの構図と解像度の切り替え

先頭の主要画像と本文中の画像では、読み込み方を変える

遅延読み込みは、画像が必要になる時期まで取得を後回しにする仕組みです。本文の下部に置く画像には有用ですが、最初の画面の主要画像に適用すると表示を遅らせることがあります。

LCPになる画像ではloading="lazy"を避けます。必要に応じて優先度を上げますが、全画像を高優先度にすると重要な画像が区別できなくなります。LCP画像の発見と優先度

<!-- 初期表示の主要画像であることを測定で確認した例 -->
<img
  src="hero-1200.webp"
  width="1200"
  height="800"
  loading="eager"
  fetchpriority="high"
  alt="このサービスで支援する企画、制作、改善の3領域"
  style="max-width: 100%; height: auto;"
/>

このコードをすべての画像にコピーするのではなく、初期表示の一枚に使うかを判断します。画面幅によってLCP対象が変わる場合もあるため、PCとスマートフォンを両方確認してください。

軽くしたのに遅いときの切り分け

画像の転送が早く終わっても、表示の準備が別の処理を待っていればLCPは大きく変わりません。以下のように確認すると、再圧縮を繰り返すだけの状態から抜けやすくなります。

表が収まらない場合は、横にスクロールできます

この表は調査の順序を決めるためのものです。原因が複数ある場合は、影響する区間を一つずつ直します。全体の測定方法はWebパフォーマンス最適化入門で説明しています。

Next.jsでは自動処理に渡す情報を正しくする

Next.jsのImageは、画像の寸法候補や配信を扱います。ただし、どの画像が重要か、実際の表示幅はいくつか、altに何を書くかは設計する側の仕事です。

以下は、最大800px幅の本文画像を表示する例です。写真・スクリーンショットなどのローカル静止画を想定し、元画像の縦横比と同じ値を指定しています。

import Image from 'next/image';

export function ArticleImage() {
  return (
    <Image
      src="/images/workflow.webp"
      alt="問い合わせを受付、確認、回答の順に進める流れ"
      width={1600}
      height={1000}
      sizes="(max-width: 832px) calc(100vw - 32px), 800px"
      style={{ width: '100%', maxWidth: 800, height: 'auto' }}
    />
  );
}

レスポンシブな画像ではsizesを指定します。Imageの既定の読み込みはlazyなので、初期表示に必要な画像は用途に応じてloading="eager"などを選びます。priorityはNext.js 16から非推奨になっています。公式資料のpreload、loading、fetchPriorityの使い分けを確認し、これらを目的なく重ねて付けないでください。Next.js Imageの仕様

同資料では、変換形式の既定はWebPで、ブラウザが送るAcceptヘッダーと設定から出力が選ばれます。AVIFを配信するかは設定次第です。「Imageを使えばすべてAVIFになる」「元画像の画質まで自動で適切になる」という理解は避けます。

運用で確認したいのは、コンポーネント名よりも実際の通信です。開発環境と公開環境で同じ配信経路とは限りません。公開後の代表ページでも、どの画像URLが、どの形式と容量で届いているかを確認します。

CDNを入れる前に、変換とキャッシュの責任を決める

画像CDNは、画像の変換や配信をまとめる選択肢です。導入判断では「速くなるサービスか」だけでなく、誰が元画像を管理し、いつ変換し、差し替えがどう反映されるかを確認します。

たとえば、素材を差し替えても以前の画像が表示されると、容量の改善以上に運用上の問題になります。反対に、毎回同じ寸法の画像を変換し直す構成なら、生成処理が待ち時間になります。以下は導入前に確認するための観点です。

• 更新時にファイル名を変えるのか、キャッシュを更新するのか。
• 元画像、変換後の画像、バックアップをどこに保存するのか。
• 必要な寸法と品質の候補が、際限なく増えないよう管理できるか。
• 配信障害時に本文の意味が伝わるaltと説明があるか。
• 変換、保存、配信の費用を誰が継続して確認するか。

これは特定サービスの機能保証ではありません。採用するサービスの仕様と、サイトの更新手順に合わせて設計するためのチェック項目です。

一枚の画像で、品質・容量・時間を分けて検証する

最初の実験には、閲覧の多いページの画像を一枚選びます。大量変換から始めると、文字のつぶれや構図の問題も一緒に広がるためです。

1. 変更前を記録する。 元の形式、幅×高さ、容量、実際の表示幅、LCP対象かどうかを残す。
2. 候補を作る。 同じ構図で寸法または形式を一つずつ変え、実際の幅で見比べる。
3. 通信を確認する。 ブラウザのNetworkパネルで、想定した候補が取得されたかを見る。
4. 同条件で再測定する。 回線・端末・キャッシュ条件をそろえ、表示時間と配置のずれを複数回確認する。
5. 公開後を追う。 実利用の数値と、画像の読みやすさに問題が出ていないか確認する。

画面密度やキャッシュが変わると、取得されるファイルが変わる場合があります。小さな画面にしたのに大きな画像が残る場合は、新しく開いた状態でも調べてください。

記録には次のような表を使えます。これは記入例の形式であり、実測した改善結果ではありません。

表が収まらない場合は、横にスクロールできます

容量削減率を出すなら、（変更前の容量−変更後の容量）÷変更前の容量×100です。分母は元のファイル容量で、LCPの秒数ではありません。転送待ち以外の時間が残るため、容量の変化をそのままページ速度や売上の変化へ置き換えないでください。

画像を小さくすることは手段です。説明に必要な情報を保ち、必要な時期に、必要な寸法で届けられたか。その3点を確認できると、画像を増やして読みやすくする判断と、軽くする判断を両立できます。