LCPとSEOのためのクリティカルイメージ抽出

Last updated: June 28, 2026

クリティカルな画像抽出とは、ページの最初の視覚的な印象を決定づける単一の画像を特定することを意味します。多くの商品ページ、ランディングページ、ブログ投稿において、その画像はヒーローイメージ、メインの商品写真、または大きなアバブ・ザ・フォールド（above-the-fold）のイラストです。これを早期に特定できれば、すべての画像を均等に高速化するのではなく、適切なファイルをプリロードしたり優先度を上げたりすることができます。

クリティカルな画像はどのように抽出しますか？

クリティカルな画像抽出を使用して、Largest Contentful Paint要素になる可能性が最も高い画像を特定し、そのファイルに特別な読み込み処理を施します。通常、これは初期ビューポート内の最大の可視画像に対して fetchpriority="high" を設定し、lazy loadingを使用せず、寸法を固定化し、場合によっては <link rel="preload"> を追加することを意味します。

すべての大きなファイルをプリロードしてはいけません。ヒーローイメージや商品画像をプリロードするのは、ブラウザがそれを見つけるのが遅くなる可能性がある場合（例えば、CSS内、カルーセル内、クライアントレンダリングされたコンポーネント内、または複雑なソース選択を持つレスポンシブな <picture> スタックなど）に限定すべきです。

変更後には、結果を検証してください。Googleの Largest Contentful Paint documentation はLCPを最大の可視コンテンツ要素を中心に定義しており、PageSpeed Insightsはどの要素が測定されたかを示します。Chrome DevToolsでも、ウォーターフォール（waterfall）の早い段階でクリティカルな画像リクエストが表示されるはずです。

以下の順序を使用してください：

1. 現実的なモバイルビューポートでページを読み込む。
2. アバブ・ザ・フォールドにある最大の画像またはポスターを見つける。
3. PageSpeedまたはLighthouseがそれをLCPとして報告するか確認する。
4. その画像から loading="lazy" を削除する。
5. 寸法、またはアスペクト比を追加する。
6. <img> の場合は fetchpriority="high" を追加する。
7. 発見が遅い場合にのみプリロードを行う。
8. ビューポート以下の画像は lazy に保つ。
9. レイアウト、CMS、またはヒーローのコピーを変更した後に再テストする。

クリティカルな画像とは何ですか？

クリティカルな画像とは、訪問者がページが有用だと感じる前に待っている画像のことです。これはLCP要素であることが多いですが、必ずしもそうではありません。ページ上部の小さなロゴが最初に読み込まれるかもしれませんが、それが知覚される準備完了度を制御することは稀です。画面の半分を占めるヒーローイメージは、通常その役割を果たします。

レンダリングされたサイズ、ビューポートの位置、そして目的を組み合わせて使用してください。ナビゲーションメニュー内のサムネイルは可視ですが、それはメインコンテンツではありません。見出しの背後にある背景画像は、最大の可視要素である場合、クリティカルである可能性があります。メタデータ内のソーシャルカード画像は共有にとって重要ですが、テンプレートがそれも表示しない限り、レンダリングされたページのためにフェッチされるわけではありません。

GoogleのLCPガイドラインでは、<img>要素、SVG内の画像要素、ビデオポスター画像、およびCSS背景画像を可能な候補として挙げています。これは、抽出が最初の <img> タグを検索することに留まらない必要があることを意味します。レンダリングされたページを検査する必要があります。

関連する作業については、より広範な image optimization for SEO チェックリストを手元に置いてください。クリティカルな画像抽出は優先度を決定しますが、圧縮、ファイル名、altテキスト、構造化コンテンツが、画像がロードされた後に有用であるかどうかを決定します。

どの画像にプリロードまたは高優先度を与えるべきですか？

一つの画像に高い優先度を与えてください。それは現在のページのLCPになりそうな画像です。2つの候補が近い場合、モバイルで最も大きい方を選ぶようにしてください。なぜなら、モバイルのCore Web Vitalsは通常、合格するのがより難しいからです。

クリティカルな画像が通常の <img> または <picture> 要素内のフォールバック <img> の場合は fetchpriority="high" を使用します。Googleの fetch priority guidance は、このヒントがマークアップの発見パスを変更することなく、ブラウザのリソース優先度を変更することを説明しています。

プリロードを使用するのは、発見自体が問題である場合です。MDNの rel="preload" reference は、プリロードをページロードの早い段階でリソースを要求する方法として説明しています。これは、画像URLがCSS内に現れる場合、ハイドレーション後に到着する場合、またはブラウザが十分に早く発見できないマークアップの背後にある場合に役立ちます。

通常のレスポンシブ画像の場合、マークアップは次のようになります：

<img
  src="/images/product-hero-960.webp"
  srcset="/images/product-hero-480.webp 480w, /images/product-hero-960.webp 960w, /images/product-hero-1440.webp 1440w"
  sizes="(max-width: 640px) 100vw, 960px"
  width="960"
  height="640"
  fetchpriority="high"
  alt="開いた黒い革のバックパックにラップトップスリーブが見える様子"
>

画像がCSS背景であり、まだHTMLに移動できない場合は、初期ビューポートで使用される同じアセットをプリロードします：

<link
  rel="preload"
  as="image"
  href="/images/home-hero-960.webp"
  imagesrcset="/images/home-hero-480.webp 480w, /images/home-hero-960.webp 960w"
  imagesizes="100vw"
>

image preloading guide は構文をより詳細にカバーしています。ここでの重要なルールは、より限定的です。プリロードは抽出後に行い、前には行わないということです。

どの画像を lazy-load から除外しますか？

Lazy loadingは最初のビューポート以下に属します。クリティカルな画像に対してこれを適用するのは誤りであり、ブラウザにレイアウトと距離のチェックが完了するまで待つように指示することになります。Googleの browser-level lazy loading guide は、すぐに可視となる画像を lazy-loading にすることに警告しています。

グローバルな画像コンポーネントを注意深く監査してください。多くのフレームワークは、ほとんどの画像がビューポート以下にあるため、lazy loadingをデフォルトとして設定します。このデフォルト設定は、ヒーローイメージがギャラリーサムネイルと同じコンポーネントでラップされているページでは機能しません。

以下の場所を確認してください：

1. CMSのリッチテキスト画像レンダラー。
2. 商品ギャラリーコンポーネント。
3. ブログのカバー画像コンポーネント。
4. ホームページのヒーロー背景ユーティリティ。
5. JavaScriptが実行されるまですべてのスライドを隠すスライダー。
6. data-src を src に置き換えるプレースホルダーコンポーネント。
7. サードパーティのパーソナライゼーションブロック。
8. ヒーローマークアップを遅延させるA/Bテストラッパー。

修正は通常小さいものです。コンポーネントに priority、aboveFold、または isLcp オプションを追加し、テンプレートオーナーに明示的に選択してもらうようにします。ビューポート以下のボディ画像は、スクリーンショットや図を含む長いガイドの場合など、ネイティブの lazy loading を引き続き使用すべきです。

モバイルが中心となるページについては、mobile image optimization guide と組み合わせてください。正しく優先されたヒーローであっても、スマートフォンが390 pxのスロットのために2400 pxのデスクトップクロップをダウンロードすると、パフォーマンスは低下します。

実際のページから画像を抽出する方法は？

アセットライブラリではなく、ブラウザから開始してください。アセットライブラリは存在するものを教えてくれますが、ブラウザはユーザーが受け取るものを教えてくれます。

この手動ワークフローを使用してください：

1. 幅390 pxでページを開き、キャッシュを無効にして再読み込みする。
2. スクロールする前に見える最大の画像に注目する。
3. その要素を検査し、最終的なURLを記録する。
4. それが <img>、<picture>、ビデオポスター、またはCSS背景のどれであるかを確認する。
5. レンダリングされた幅と高さを確認する。
6. ダウンロードされたファイルの幅とレンダリングされたスロットを比較する。
7. loading="lazy" や JavaScriptによる遅延 src の代入がないか探す。
8. DevTools Networkでリクエストの開始時間と優先度を確認する。
9. PageSpeed Insightsを実行し、LCP要素を記録する。
10. ヒーローがブレークポイントによって変わる場合は、デスクトップでも繰り返す。

テンプレート監査を行う場合は、コード編集の前に小さな抽出テーブルを作成してください：

この記事の図はすべてWebPファイルとして生成し、それぞれ40 KB未満に抑えました。これは写真に対する普遍的な目標ではありませんが、有用なリマインダーです。抽出された画像は、優先度を受ける前に適切なサイズになっているべきです。もしファイルがまだ巨大な場合は、出荷する前に image compression deep dive と batch resize guide を使用してください。

ツールでクリティカルな画像を検証する方法は？

検証には2つの役割があります。第一に、選択された画像が実際にLCP要素であるか、または深刻なLCP候補であることを証明すること。第二に、ブラウザがそれを十分に早く発見することを証明することです。

フィールドとラボの両方のコンテキストにはPageSpeed Insightsを使用します。診断パネルは通常LCP要素の名前を挙げ、スクリーンショットは報告された要素がページの視覚的なヒーローと一致するかどうかを確認するのに役立ちます。ローカルなトレースが必要な場合は、LighthouseまたはDevTools Performanceを使用してください。

リクエストの動作にはDevTools Networkを使用します：

1. 画像リクエストでフィルタリングする。
2. キャッシュを無効にして再読み込みする。
3. クリティカルな画像がウォーターフォールのほぼ上部から開始することを確認する。
4. 優先度がHighであるか、早期にアップグレードされていることを確認する。
5. ビューポート以下の画像すべてが同時に競合していないことを確認する。
6. ステータスコード、コンテンツタイプ、転送サイズ、およびキャッシュヘッダーを確認する。

マークアップの誤りにはレンダリングされたHTML検査を使用します：

1. クリティカルな画像は初期マークアップに src または発見可能な srcset を持っている。
2. loading="lazy" を持っていない。
3. width と height、または安定したCSSアスペクト比を持っている。
4. その alt text は、画像がコンテンツである場合に可視の主題を説明している。
5. CDN URLはクローリング可能な 200 レスポンスを返す。

検索に関して、Googleの image SEO best practices もまた、記述的なファイル名、altテキスト、および有用な周辺テキストを強調しています。クリティカルな画像抽出は読み込み優先度を改善しますが、同じ画像には依然として検索コンテキストが必要です。

クリティカルな画像抽出を妨げるものは何ですか？

最も一般的な失敗は、すべてのページが同じヒーローを持っているかのように扱うことです。ブログインデックス、商品ページ、価格設定ページは異なるLCP候補を持つ可能性があります。この抽出ステップはテンプレートレベルおよびブレークポイントレベルで行われる必要があります。

以下の落とし穴に注意してください：

1. Open Graph画像のプリロード。 ソーシャルカード画像はページ上でレンダリングされないかもしれません。
2. 最初の製品写真の lazy-loading。 商品ギャラリーはサムネイルのデフォルト設定を継承しがちです。
3. すべてのカルーセルスライドへの優先度付け。 ロード時にクリティカルなのは、最初に見えるスライドだけです。
4. モバイルクロップの無視。 デスクトップとモバイルでは異なるLCP画像が選択される可能性があります。
5. 意味のあるコンテンツにCSS背景を使用すること。 これらは優先度を付けにくく、アクセシビリティも低いです。
6. 寸法を忘れること。 優先度はレイアウトシフトを防ぎません。
7. 巨大なソースを一つ配信すること。 高優先度の3 MBの画像でも、依然として遅いです。
8. ローカルWi-Fiでのみテストすること。 遅い4Gは発見の遅延を露呈させます。

問題が主にファイルサイズである場合は、complete image optimization checklist から始めるべきです。問題がフォーマットの選択である場合は、配信ルールを変更する前に AVIF vs WebP を比較してください。

まとめ：クリティカルな画像抽出チェックリスト

クリティカルな画像抽出は、アセットの名前付けの演習ではなく、ページスピードに関する決定です。最初のビューポートを制御する画像を特定し、その画像のみに早期読み込み処理を与え、ページの残りの部分がそれと競合しないように保つ必要があります。

公開する前に、以下の点を確認してください：

1. おそらくLCPとなる画像がテンプレートまたは監査ノートで名前付けされていること。
2. モバイルおよびデスクトップの候補が個別にチェックされていること。
3. クリティカルな画像が lazy-load されていないこと。
4. 可視な <img> LCP候補に対して fetchpriority="high" が使用されていること。
5. プリロードは、発見が遅い場合にのみ使用されること。
6. 選択されたファイルがリサイズされ、圧縮されていること。
7. 幅と高さ、またはアスペクト比がレイアウトスペースを確保していること。
8. ビューポート以下の画像が lazy のままであること。
9. PageSpeed Insightsが期待されるLCP要素を報告していること。
10. DevToolsがクリティカルな画像リクエストをウォーターフォールの早い段階で示していること。
11. CDN URLが予想される画像タイプと共に 200 を返すこと。
12. 画像に有用な alt text と近くの説明的なコンテンツがあること。

画像クレジット

• カバー、LCP候補図、優先度決定木、および検証トレースは、ImageMagickを使用して生成され、WebPとしてエクスポートされました。