Web 画像最適化チェックリスト - 実務で使える 15 項目を徹底解説
なぜ画像最適化チェックリストが必要なのか - 数値で見るインパクト
Web ページの総転送量のうち、画像が占める割合は平均 50% 以上です。HTTP Archive の 2024 年データによると、モバイルページの画像転送量の中央値は約 1,000KB で、これはページ全体の 52% に相当します。画像最適化を体系的に行うことで、ページ読み込み時間を 40-60% 短縮できるケースは珍しくありません。
しかし、画像最適化は「圧縮すれば終わり」という単純な作業ではありません。フォーマット選択、解像度設定、配信方法、読み込み戦略、キャッシュ設計など、複数のレイヤーにまたがる施策を組み合わせる必要があります。1 つの項目を見落とすだけで、他の最適化効果が相殺されることもあります。
このチェックリストは、実際のプロダクション環境で繰り返し使える実務ツールとして設計しています。新規サイト構築時のレビュー、既存サイトの改善監査、リリース前の最終確認など、さまざまな場面で活用できます。各項目には具体的な数値目標と検証方法を含めているため、「何をどこまでやれば十分か」の判断基準が明確です。
Google の Core Web Vitals において、LCP (Largest Contentful Paint) の 75 パーセンタイルが 2.5 秒以内であることが「良好」の基準です。LCP 要素の 70% 以上が画像であるという調査結果を踏まえると、画像最適化は SEO ランキングに直結する最重要施策と言えます。
フォーマットと圧縮の最適化 - チェック項目 1 から 5
最初の 5 項目は、画像ファイル自体の最適化に関するチェックです。
- 項目 1: 適切なフォーマット選択 - 写真は AVIF/WebP/JPEG、イラストやロゴは SVG/WebP/PNG を使用しているか確認します。特に透過が不要な写真に PNG を使っている場合、JPEG に変更するだけでファイルサイズが 60-80% 削減されます。
<picture>要素で AVIF → WebP → JPEG のフォールバックチェーンを構築するのが理想です。 - 項目 2: 品質パラメータの最適化 - JPEG は品質 75-85、WebP は品質 75-80、AVIF は品質 50-65 が一般的な最適値です。品質 100 と品質 80 の視覚的差異は人間の目ではほぼ判別できませんが、ファイルサイズは 2-3 倍異なります。
- 項目 3: メタデータの除去 - EXIF、XMP、ICC プロファイル (sRGB の場合) を除去します。スマートフォンで撮影した写真には GPS 情報を含む 10-50KB のメタデータが付与されています。
exiftool -all= image.jpgで一括除去できます。 - 項目 4: 可逆圧縮の最適化 - PNG は
oxipngやpngquantで再圧縮します。pngquant による 256 色への減色で、視覚的劣化なしに 60-80% のサイズ削減が可能です。SVG はsvgoで不要な属性やコメントを除去します。 - 項目 5: アニメーション画像の最適化 - GIF アニメーションは WebP アニメーションまたは MP4 動画に変換します。10 秒の GIF アニメーションが 5MB の場合、WebP アニメーションで 1MB、MP4 で 300KB 程度まで削減できます。
レスポンシブと解像度の最適化 - チェック項目 6 から 9
デバイスの画面サイズとピクセル密度に応じた最適な画像を配信するためのチェック項目です。
- 項目 6: srcset と sizes の設定 -
<img srcset="img-400.jpg 400w, img-800.jpg 800w, img-1200.jpg 1200w" sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 600px">のように、ブレークポイントごとの表示幅を正確に指定します。sizes が未指定の場合、ブラウザはビューポート幅 100% と仮定して不必要に大きな画像をダウンロードします。 - 項目 7: Retina 対応の適正化 - 2x 解像度の画像を提供する場合、表示サイズの 2 倍の解像度で十分です。3x 以上の画像を全ユーザーに配信するのは過剰です。600px 幅で表示する画像なら、1,200 px 幅の画像を用意すれば Retina ディスプレイでも十分な鮮明さが得られます。3x 画像は 1,800 px 必要ですが、ファイルサイズが 2x の 2 倍以上になるため、コスト対効果が低下します。
- 項目 8: 不要な解像度の排除 - 実際の表示サイズより大きな画像を配信していないか確認します。CMS から出力される画像が 4,000 px 幅で、実際の表示が 800px の場合、帯域幅の 96% が無駄になっています。
max-widthに基づいて適切なリサイズを行います。 - 項目 9: アートディレクション - モバイルとデスクトップで異なるクロップやアスペクト比が必要な場合、
<picture>要素の<source media="...">でデバイスごとに最適な画像を指定します。横長のバナー画像をモバイルでそのまま縮小すると、テキストが読めなくなる問題を防げます。
これらの項目を適切に実装することで、モバイルユーザーへの転送量を 50-70% 削減できます。特に項目 8 は見落とされがちですが、最も効果が大きい施策の 1 つです。WordPress サイトでは、アップロード時に自動生成されるサムネイルサイズの設定を見直すだけで大幅な改善が見込めます。
読み込み戦略の最適化 - チェック項目 10 から 12
画像をいつ、どのように読み込むかの戦略は、体感速度に直結します。
- 項目 10: 遅延読み込みの適用 - ファーストビュー外の画像には
loading="lazy"を設定します。ただし、LCP 候補となるファーストビュー内の画像には絶対にloading="lazy"を付けてはいけません。これは LCP を 300-500ms 悪化させる典型的なミスです。Chrome DevTools の Performance パネルで LCP 要素を特定し、その画像にはloading="eager"(デフォルト) を維持します。 - 項目 11: fetchpriority の設定 - LCP 画像には
fetchpriority="high"を明示的に設定します。これによりブラウザのリソース優先度キューで画像が最優先で取得され、LCP が 100-300ms 改善されます。逆に、装飾的な背景画像やアイコンにはfetchpriority="low"を設定して、重要なリソースの帯域を確保します。 - 項目 12: preload の活用 - CSS 背景画像や JavaScript で動的に挿入される画像は、ブラウザのプリロードスキャナーが検出できません。
<link rel="preload" as="image" href="hero.avif" type="image/avif">を<head>に記述して、早期にダウンロードを開始させます。ただし、preload の乱用はかえって他のリソースの読み込みを遅延させるため、LCP 画像 1 枚に限定するのが原則です。
これら 3 項目の組み合わせにより、画像の読み込み優先度を精密に制御できます。実測データでは、項目 10-12 を適切に実装したサイトは、未実装のサイトと比較して LCP が平均 800ms 改善されています。特に低速回線 (3G 相当) での改善効果が顕著で、モバイルユーザーの体験を大きく向上させます。
配信とキャッシュの最適化 - チェック項目 13 から 15
画像の配信インフラとキャッシュ戦略に関する最終チェック項目です。
- 項目 13: CDN の活用 - 画像を CDN (Content Delivery Network) 経由で配信し、ユーザーに最も近いエッジサーバーからレスポンスを返します。CDN 未使用の場合、東京のサーバーからニューヨークのユーザーへの RTT (Round Trip Time) は約 200ms ですが、CDN 経由なら 20ms 以下に短縮されます。Cloudflare、CloudFront、Fastly などの CDN は画像の自動最適化機能も提供しています。
- 項目 14: キャッシュヘッダーの設定 - 画像ファイルには長期キャッシュを設定します。
Cache-Control: public, max-age=31536000, immutable(1 年間) が推奨値です。ファイル名にハッシュを含める (例:hero-a3f2b1.webp) ことで、コンテンツ更新時にキャッシュを確実に無効化できます。immutableディレクティブにより、ブラウザの条件付きリクエスト (304 レスポンス) も省略され、リピートアクセス時の表示が高速化します。 - 項目 15: HTTP/2 以上の活用 - HTTP/2 のマルチプレキシングにより、複数の画像を並列ダウンロードできます。HTTP/1.1 の 6 接続制限がボトルネックになっている場合、HTTP/2 への移行だけで画像の読み込み完了時間が 30-50% 短縮されます。さらに HTTP/3 (QUIC) では、パケットロス時の Head-of-Line Blocking が解消され、モバイル回線での安定性が向上します。
配信インフラの最適化は、個々の画像ファイルの最適化とは独立して効果を発揮します。すでに画像圧縮を十分に行っているサイトでも、CDN 導入とキャッシュ設定の見直しで追加の 20-40% の速度改善が得られることがあります。特に国際的なユーザーベースを持つサイトでは、CDN の効果が劇的です。
チェックリストの運用方法 - 優先順位と自動化
15 項目すべてを一度に実装する必要はありません。効果の大きさと実装コストに基づいた優先順位付けが重要です。
即効性が高い施策 (1 日で実装可能): 項目 2 (品質パラメータ)、項目 3 (メタデータ除去)、項目 10 (遅延読み込み) は、既存の画像に対して一括適用でき、即座に効果が現れます。これら 3 項目だけで転送量を 30-50% 削減できるケースが多いです。
中期的な施策 (1 週間で実装可能): 項目 1 (フォーマット選択)、項目 6 (srcset/sizes)、項目 11 (fetchpriority) は、テンプレートやビルドパイプラインの変更が必要ですが、一度実装すれば以降のすべての画像に自動適用されます。
インフラ施策 (1 ヶ月で実装可能): 項目 13 (CDN)、項目 14 (キャッシュ)、項目 15 (HTTP/2) は、サーバー設定やインフラ構成の変更を伴いますが、サイト全体に恩恵をもたらします。
自動化の観点では、CI/CD パイプラインに画像最適化チェックを組み込むことを推奨します。lighthouse ci で LCP スコアを監視し、閾値を下回った場合にデプロイをブロックする仕組みが効果的です。また、sharp や squoosh-cli をビルドプロセスに統合し、画像のリサイズ・フォーマット変換・圧縮を自動化することで、開発者が個別に最適化を意識する必要がなくなります。定期的な監査には unlighthouse (サイト全体の Lighthouse スキャン) や WebPageTest の API を活用し、パフォーマンスの回帰を早期に検出します。