Web サイトの画像パフォーマンス監査 - Core Web Vitals 改善の実践ガイド
画像がパフォーマンスに与える影響 - なぜ画像監査が重要なのか
Web ページの総転送量のうち、画像が占める割合は平均 50% 以上です。HTTP Archive のデータによると、デスクトップページの画像転送量の中央値は約 1MB、モバイルでも約 800KB に達します。画像の最適化は、Web パフォーマンス改善において最もインパクトの大きい施策の 1 つです。
Core Web Vitals への影響:
- LCP (Largest Contentful Paint): ページの最大コンテンツ要素の表示完了時間。多くのページで LCP 要素はヒーロー画像や商品画像です。画像の読み込みが遅いと LCP が悪化し、Google 検索ランキングに悪影響を与えます。
- CLS (Cumulative Layout Shift): レイアウトの予期しないずれの累積量。画像に width/height 属性や aspect-ratio が指定されていないと、画像読み込み時にレイアウトがずれ、CLS が悪化します。
- INP (Interaction to Next Paint): 画像の遅延読み込みやデコード処理がメインスレッドをブロックすると、ユーザーインタラクションへの応答が遅延します。
ビジネスへの影響:
ページ読み込み速度の 1 秒の遅延は、コンバージョン率を 7% 低下させるとされています (Akamai の調査)。EC サイトでは、画像の最適化だけで売上が数パーセント改善した事例が多数報告されています。特にモバイルユーザーは低速回線での閲覧が多く、画像サイズの影響を強く受けます。
画像パフォーマンス監査は、これらの問題を体系的に発見し、優先順位をつけて改善するためのプロセスです。一度きりの作業ではなく、継続的なモニタリングと改善のサイクルとして実施することが重要です。
監査ツールと指標 - 何を測定し、どう評価するか
画像パフォーマンスを監査するためのツールと、注目すべき指標を紹介します。複数のツールを組み合わせることで、包括的な監査が可能になります。
Lighthouse (PageSpeed Insights):
Google が提供する Web パフォーマンス監査ツールです。画像関連では以下の項目を検出します。適切なサイズの画像を配信しているか (Properly size images)。次世代フォーマット (WebP、AVIF) を使用しているか (Serve images in next-gen formats)。画像を効率的にエンコードしているか (Efficiently encode images)。オフスクリーン画像を遅延読み込みしているか (Defer offscreen images)。各項目について推定される節約量 (KB) が表示されるため、改善の優先順位付けに役立ちます。
WebPageTest:
実際のブラウザでページを読み込み、詳細なウォーターフォールチャートを生成します。各画像のダウンロード開始時刻、完了時刻、サイズ、圧縮率を確認できます。「Image Analysis」タブでは、各画像の最適化余地を個別に分析し、WebP 変換時の推定サイズ削減量を表示します。
Chrome DevTools:
- Network パネル: 画像のサイズ、読み込み時間、HTTP キャッシュの状態を確認。「Img」フィルタで画像リクエストのみを表示できます。
- Performance パネル: LCP 要素の特定と、画像デコードにかかる時間の計測。
- Coverage パネル: 使用されていない CSS 背景画像の検出。
- Rendering パネル: 「Layout Shift Regions」を有効にすると、CLS の原因となる画像を視覚的に特定できます。
カスタム監査スクリプト:
Puppeteer や Playwright を使って、サイト全体の画像を自動的にクロールし、サイズ、フォーマット、圧縮率、alt 属性の有無などを一括チェックするスクリプトを作成できます。定期実行して結果をダッシュボードに表示すれば、継続的な監視が可能です。
LCP の改善 - ヒーロー画像の最適化戦略
LCP (Largest Contentful Paint) は Core Web Vitals の中で最も画像の影響を受ける指標です。多くのページで LCP 要素はヒーロー画像、バナー画像、または商品画像です。LCP を 2.5 秒以内に収めるための具体的な戦略を解説します。
プリロードによる早期読み込み:
LCP 画像は <link rel="preload" as="image" href="hero.webp"> で優先的に読み込みます。通常、ブラウザは HTML をパースして <img> タグを発見してから画像のダウンロードを開始しますが、preload を使えば HTML のパース開始と同時にダウンロードを開始できます。レスポンシブ画像の場合は imagesrcset と imagesizes 属性を使用します。
fetchpriority="high" の指定:
LCP 画像に fetchpriority="high" を指定すると、ブラウザがリソースの優先度を引き上げ、他のリソースより先にダウンロードします。特に、ファーストビューに複数の画像がある場合に効果的です。逆に、ファーストビュー外の画像には fetchpriority="low" を指定して帯域を譲ります。
適切なサイズの配信:
表示サイズより大きな画像を配信すると、無駄な転送量とデコード時間が発生します。srcset と sizes 属性を使って、デバイスの画面幅と DPR (Device Pixel Ratio) に応じた最適なサイズの画像を配信します。例えば、モバイルで 375px 幅に表示する画像に 2,000 px 幅の画像を配信するのは無駄です。750px (375px × 2 DPR) の画像で十分です。
CDN とキャッシュの活用:
画像を CDN (CloudFront、Cloudflare) 経由で配信し、エッジサーバーからの低レイテンシ配信を実現します。適切な Cache-Control ヘッダー (max-age=31536000, immutable) を設定し、再訪問時のダウンロードを排除します。ファイル名にハッシュを含めることで、長期キャッシュと即時更新を両立します。
画像フォーマットの最適化:
LCP 画像は最も効率的なフォーマットで配信します。<picture> 要素で AVIF → WebP → JPEG の順にフォールバックを設定し、ブラウザが対応する最も効率的なフォーマットを自動選択するようにします。AVIF は JPEG 比で 50% 以上のサイズ削減が可能な場合があります。
CLS の防止 - 画像によるレイアウトシフトの排除
CLS (Cumulative Layout Shift) は、ページ読み込み中にコンテンツが予期せずずれる現象を定量化した指標です。画像は CLS の主要な原因の 1 つであり、適切な対策が必要です。Google は CLS 0.1 以下を「良好」としています。
width/height 属性の明示:
すべての <img> タグに width と height 属性を指定します。ブラウザはこの情報からアスペクト比を計算し、画像読み込み前にスペースを確保します。HTML の属性値はピクセル単位の整数で指定し、CSS でレスポンシブにリサイズする場合は width: 100%; height: auto; を併用します。
aspect-ratio CSS プロパティ:
CSS の aspect-ratio プロパティを使えば、コンテナのアスペクト比を明示的に指定できます。.hero-image { aspect-ratio: 16 / 9; width: 100%; object-fit: cover; } のように設定すると、画像読み込み前から正しいスペースが確保されます。
プレースホルダーの活用:
画像読み込み中に表示するプレースホルダーを設定することで、ユーザー体験を向上させつつ CLS を防止します。LQIP (Low Quality Image Placeholder) は、極小サイズ (20-40px 幅) のぼかし画像を base64 エンコードしてインラインで埋め込む手法です。BlurHash や ThumbHash はさらに効率的で、数十バイトのハッシュ値からプレースホルダー画像を生成します。
遅延読み込みと CLS の関係:
loading="lazy" を使用する場合、ファーストビュー内の画像には適用しないことが重要です。ファーストビュー内の画像を遅延読み込みすると、スクロールなしで表示される領域でレイアウトシフトが発生する可能性があります。ファーストビュー外の画像にのみ loading="lazy" を適用し、ファーストビュー内の画像は即座に読み込みます。
レスポンシブ画像と CLS:
<picture> 要素や srcset を使用する場合、すべてのソース画像が同じアスペクト比であることを確認します。異なるアスペクト比の画像が条件によって切り替わると、レイアウトシフトの原因になります。アートディレクション (デバイスによって異なる構図の画像を表示) を行う場合は、各ブレークポイントで適切な aspect-ratio を設定します。
転送量の削減 - 画像の圧縮と配信の最適化
画像の転送量を削減することは、ページ読み込み速度の改善に直結します。特にモバイル環境では、帯域幅の制約が大きいため、転送量の削減効果が顕著です。
適切な圧縮レベルの設定:
画像の用途に応じて圧縮レベルを調整します。ヒーロー画像やポートフォリオ写真は品質 85-90 (JPEG) で高品質を維持し、サムネイルやリスト表示の画像は品質 70-80 で十分です。背景画像やデコレーション画像はさらに低い品質 (60-70) でも視覚的に問題ない場合が多いです。
レスポンシブ画像の実装:
srcset と sizes を使って、デバイスに最適なサイズの画像を配信します。一般的なブレークポイントとして、320w、640w、960w、1280w、1920w の 5 段階を用意します。DPR 2x のデバイスでは表示幅の 2 倍の画像が必要ですが、DPR 3x では 2x と同じ画像で十分な場合が多いです (人間の目は 2x 以上の差を知覚しにくい)。
画像 CDN の活用:
Cloudinary、imgix、Cloudflare Images などの画像 CDN を使えば、URL パラメータで動的にリサイズ、フォーマット変換、品質調整が可能です。オリジンには高解像度のマスター画像を 1 枚だけ保持し、配信時にデバイスに最適な画像を動的生成します。Accept ヘッダーに基づく自動フォーマット選択 (Auto Format) により、ブラウザが対応する最も効率的なフォーマットを自動配信できます。
HTTP/2 Server Push と Early Hints:
HTTP/2 Server Push は非推奨になりましたが、103 Early Hints を使えば、HTML レスポンスの前に重要なリソースのプリロードヒントを送信できます。LCP 画像の URL を Early Hints で通知することで、ブラウザが HTML パース前にダウンロードを開始できます。CloudFront や Cloudflare が Early Hints をサポートしています。
継続的な監視と改善サイクル - パフォーマンス文化の構築
画像パフォーマンスの改善は一度きりの作業ではなく、継続的なプロセスとして組織に定着させることが重要です。新しいコンテンツの追加や機能変更のたびに、パフォーマンスが回帰するリスクがあります。
パフォーマンスバジェットの設定:
ページごとに画像の転送量上限 (パフォーマンスバジェット) を設定します。例えば「トップページの画像転送量は 500KB 以下」「商品詳細ページは 800KB 以下」のように具体的な数値を定めます。CI/CD パイプラインでバジェット超過を検出し、マージをブロックする仕組みを導入します。bundlesize や Lighthouse CI でバジェットチェックを自動化できます。
RUM (Real User Monitoring) の導入:
Lighthouse のラボデータだけでなく、実際のユーザーのパフォーマンスデータ (フィールドデータ) を収集します。Chrome UX Report (CrUX)、web-vitals ライブラリ、または商用 RUM ツール (Datadog、New Relic) を使用して、実際のユーザー体験を継続的に監視します。地域、デバイス、回線速度ごとのパフォーマンス分布を把握し、最も改善が必要なセグメントを特定します。
画像最適化の自動化:
CMS やビルドパイプラインに画像最適化を組み込み、人間の介入なしに最適な画像が配信される仕組みを構築します。アップロード時の自動リサイズ・圧縮・フォーマット変換、ビルド時の srcset 生成、デプロイ時の CDN キャッシュ更新を自動化します。Next.js の Image コンポーネントや Nuxt Image モジュールは、これらの多くを自動的に処理します。
チームへの教育と文化:
デザイナーやコンテンツ担当者にも画像パフォーマンスの基礎知識を共有します。「2,000 px 以上の画像をアップロードしない」「PNG ではなく JPEG/WebP を使う」「alt 属性を必ず設定する」などのシンプルなガイドラインを策定し、チーム全体でパフォーマンス意識を高めます。定期的なパフォーマンスレビュー会議を設け、改善の進捗と新たな課題を共有します。