画像最適化チェックリスト：高速なWeb画像を構築するための全ステップ

最終更新日: June 28, 2026. 一貫した結果を得るために、公開前に必ずこのチェックリストを再実行してください。

画像最適化は単一のステップではなく、一連のプロセスです。どの段階もスキップすると、結果が遅いか、ぼやけたものになります。本チェックリストでは、フォーマットの選択、リサイズ、圧縮、レスポンシブな配信、lazy loading、CDN設定といったすべての段階を、実際に実行する順序で解説します。これにより、公開前に確認し、画像が高速にロードされ、シャープに見えることを保証できます。

クイックアンサー：完全な画像最適化プロセスには何が含まれますか？

完全なプロセスとは、適切なフォーマット（写真にはWebP、ベクターにはSVG、透過にはPNG）を選択し、表示寸法に合わせてリサイズし、ターゲットのファイルサイズに圧縮し、srcsetを使用してレスポンシブなバリアントを提供し、ビューポート外の画像をlazy-loadingで処理し、CDNから配信することを意味します。どの段階もスキップするとパフォーマンスが損なわれます。未圧縮の画像は遅く、過剰なサイズの画像はバイトを無駄にし、lazy loadingがない画像は初期レンダリングを遅延させます。単にいくつかの段階を選ぶのではなく、チェックリスト全体を実行してください。

なぜアドホック（場当たり的）ではなくチェックリストで実行するのか？

画像最適化には多くの小さなステップがあり、一つでも忘れると他の作業が無駄になります。チェックリストは、忘れがちな多段階のプロセスを、一貫した結果を生み出す再現可能なルーティンに変えます。

• 各ステージは、異なるパフォーマンス要因に対処します。
• ステージをスキップすると、その要因が未処理のままになります。
• これらのステージは独立しているため、チェックリストとして信頼性高く確認できます。

ステージ1：適切なフォーマットを選択する

フォーマットは最初の決定事項であり、後続のすべてに制約を与えます。画像の内容に合わせてフォーマットを合わせることが重要です。

• WebP — 最新ブラウザにおける写真のデフォルト形式。同じ品質であればJPEGよりも小さい。
• AVIF — WebPよりもさらに小さく、サポートが拡大している。WebPまたはJPEGのフォールバックと併用する。
• SVG — ロゴ、アイコン、ベクターグラフィック向け。無限にスケーリング可能で、ファイルサイズが非常に小さい。
• PNG — 透過性が必要な画像やロスレス品質を保ちたい画像向け。
• JPEG — 最新フォーマットがサポートされていない場合の写真の万能フォールバック。

format comparison guide および AVIF vs WebP guide で、トレードオフを深く解説しています。コンテンツに対して許容できる品質で最小のファイルサイズを提供するフォーマットを選択してください。

ステージ2：表示寸法にリサイズする

画像が実際に表示されるよりも大きなサイズの画像を配信してはいけません。600ピクセルのスロットに4000ピクセルの写真を使用すると、帯域幅を浪費し、ページを遅くします。Resize を使用して、レティナ（2x）を考慮に入れ、画像が表示される最大のサイズまでリサイズしてください。

圧縮の前にリサイズを行うことが重要です。なぜなら、圧縮はピクセル数に基づいて機能するからです。ピクセルが少なければ少ないほど、バイトも少なくなるためです。resize guide では、品質を失わずにこれを行う方法を解説しています。

ステージ3：ターゲットのファイルサイズに圧縮する

リサイズ後、compress を使用してバイト数を削減します。目に見える品質低下がない最小のファイルを目標にしてください。

• 写真: 品質80のWebPまたはJPEG。
• フラットカラーのグラフィック: PNGまたはロスレスWebP。
• 100%ズームでテストし、目に見えるアーティファクトがないことを確認する。
• ヒーロー画像は200 KB以下、コンテンツ画像は100 KB以下を目指す。

compression guide では、技術と品質設定を解説しています。

ステージ4：レスポンシブバリアントを提供する

異なる画面には異なる画像サイズが必要です。すべてのデバイスが万能な単一のファイルではなく、適切なファイルをダウンロードするようにsrcsetを使用して配信してください。

• レティナ画面向けに1x、2x、3xのバリアントを生成する。
• レスポンシブレイアウトのためにsizesと組み合わせて幅指定子（400w、800wなど）を使用する。
• ブラウザに適切なファイルを選択させる。
• responsive images guide でマークアップを解説しています。

ステージ5：ビューポート外の画像をlazy-loadする

画面の下部（below the fold）にある画像は、ユーザーがスクロールしてそれまで移動するまでロードされるべきではありません。これにより初期レンダリングのための帯域幅が確保され、Largest Contentful Paint (LCP) メトリックが改善します。

• ビューポート外の画像にloading="lazy"を追加する。
• ヒーロー画像はeager-loaded（即時読み込み）にしておくことで、LCP要素が速くロードされるようにする。
• lazy loading guide で実装を解説しています。

ステージ6：CDNから配信する

画像をコンテンツデリバリーネットワーク (CDN) から配信することで、各ユーザーに近いエッジロケーションからロードされます。CDNはレイテンシを削減し、オリジンサーバーの負荷を軽減します。これは地理的に広範囲にわたるオーディエンスを持つサイトにとって最も重要です。そうでない場合、別の大陸にいるユーザーはすべての画像がその距離を越えるのを待つことになります。CDN guide はセットアップ方法を網羅しており、CDNがオンザフライでリサイズや再フォーマットできる変換機能についても触れています。また、Core Web Vitals guide は、高速な画像配信とランキングに影響を与えるメトリックを結びつけています。

CDNはトラフィックの急増も吸収します。ページがバイラルになったり、キャンペーンが大量の訪問者を送ったりした場合、エッジキャッシュがオリジンではなく画像を配信するため、単一のサーバーでは処理しきれない負荷がかかってもサイトが高速に保たれます。平均ロード時間と同じくらいアップタイムが重要なサイトにとって、この回復力はレイテンシ削減と同じくらい価値があります。

一般的な最適化のミス

チェックリストを使用しても、いくつかのエラーは繰り返され、作業を無駄にしてしまいます。これらを知っておくことで、検証ステップが迅速になります。

• リサイズする前に圧縮すること — 破棄されるピクセルに対して労力を浪費します。必ず先にリサイズしてください。
• すべてのデバイスに単一のサイズを提供すること — スマートフォンがデスクトップサイズのファイルをダウンロードしてしまいます。srcsetを使用してください。
• ヒーロー画像をlazy-loadingにすること — LCP要素を遅延させます。ビューポート内の画像はeagerにしておくべきです。
• widthとheight属性を忘れること — 画像がロードされる際にレイアウトシフトを引き起こします。必ず含めてください。
• 写真にPNGを使用すること — ファイルサイズを膨らませてしまいます。写真コンテンツにはWebPまたはJPEGを使用してください。

検証：最適化は機能したか？

チェックリストを実行した後、推測ではなく測定によって結果を確認してください。ツールは画像が実際に高速にロードされるかどうかを確定し、最適化が機能したかどうかを知る唯一の方法は測定です。視覚的な検査ではファイルサイズやロード順序はわかりません。ブロードバンドとモバイルデータ接続の両方でこれらのチェックを実行してください。なぜなら、ブロードバンドでは問題ないように見える最適化でも、モバイルデータでは苦戦する可能性があるからです。

1. Google PageSpeed Insights を実行し、画像関連の機会を確認する。
2. LCP要素が2.5秒以内にロードされることを確認する。
3. ネットワークタブを確認し、デバイスごとに適切なサイズのファイルがロードされていることを確認する。
4. lazy-loadedされた画像がスクロールまで遅延することを確認する。

web.dev performance measurement guide はPageSpeedがページをどのようにスコアリングするかを文書化しており、Mozilla performance guide はメトリックを深く解説しています。これらのチェックをクリアしたページは、単に最適に見える画像ではなく、真に高速な画像を持っています。より広範なSEOの文脈では、image SEO guide がこれらのパフォーマンス向上と検索ランキングを結びつけています。

よくある質問

完全な画像最適化プロセスには何が含まれますか？

適切なフォーマットの選択、表示寸法へのリサイズ、ターゲットファイルサイズへの圧縮、srcsetを使用したレスポンシブバリアントの提供、ビューポート外のlazy-loading、そしてCDNでのキャッシングです。どの段階もスキップすると、バイト数や品質を無駄にすることになります。チェックリストは、どの段階も見落とさないように存在します。

なぜアドホックではなくチェックリストで実行するのですか？

なぜなら、アドホックな最適化では段階が欠落することがあるからです。開発者が圧縮を行うもののリサイズを忘れたり、srcsetを追加したもののlazy-loadingを忘れるといったことが起こります。チェックリストは、サイト全体を通してすべての画像にすべての段階が一貫して適用されることを保証します。一貫性こそが、Core Web Vitalsをスケールで向上させる鍵です。

最大の画像最適化のメリットは何ですか？

表示寸法へのリサイズです。6000pxのカメラ写真が800pxで配信される場合、ほとんどのサイトで最大の単一の無駄となります。まずリサイズし、それ以外のすべては正しくサイズ指定された基盤の上に積み重なります。

レスポンシブバリアントはどうやって提供しますか？

ブレークポイントが必要なサイズのすべての画像を生成し、その後srcsetとsizesを使用して、ブラウザにビューポートに応じて適切なファイルを選択させます。ブラウザは必要なバリアントのみをダウンロードするため、小さな画面でのバイト数を節約できます。responsive images guide を参照してください。

画像の再最適化はどのくらいの頻度で行うべきですか？

新しい画像を追加するたびに、そしてCore Web Vitalsが低下した際には既存のセットを監査する必要があります。数年前に最適化された古い画像は、WebPの方が小さくなるはずなのにJPEGになっている場合があります。定期的な監査を行うことで、フォーマットや圧縮のズレを発見できます。

既存サイトの画像をどのように監査しますか？

クローラー（Lighthouse、またはScreaming Frogのようなツール）を実行して、すべての画像とそのサイズと寸法をリストアップし、表示スロットに対して過剰なサイズのものが含まれていないか、WebPの方が小さいはずなのにJPEGとして提供されていないか、あるいはwidth/height属性が欠落しているものをフラグ付けします。まず最も大きな問題の画像を修正してください。通常、数枚の巨大な画像がページの重さの大部分を占めます。改善を確認するために、修正後に監査を再実行してください。