LighthouseのLCP request discovery：チェック項目と解決策

LCP request discoveryから、LCP画像について何がわかるのか？

LCP request discoveryは、「Preload Largest Contentful Paint image」と「Largest Contentful Paint image was lazily loaded」に代わってLighthouse 13で導入されたインサイトです。チェック対象は、訪問者が表示を待っているメイン写真（LCP画像）がHTMLから検出可能かどうかです。HTMLが到着した瞬間に、ブラウザが高い優先度でダウンロードを開始できたかを確認します。解決策は、HTML内に写真を<img>として記述し、loading="lazy"を付けずにfetchpriority="high"を指定することです。

手早く修正したい場合は、WordPress、ページビルダー、Shopify、またはNext.jsの解説へ移動してください。

LCP request discoveryの3つのチェック項目は何を意味するのか？

Lighthouse 13やPageSpeed Insightsでは、「HTMLからLCP画像をすぐに検出できるようにし、lazy loadingを避けてLCPを最適化してください」という通知が表示されます。その下には3つのチェック項目があり、それぞれ緑または赤で表示されます。

ホテルのトップページの大きな写真にloading="lazy"が設定されている場合の通知例。Lighthouse 13.6、DevToolsのスロットリング適用時。

• fetchpriority=high should be applied：ブラウザがfetchpriority="high"なしでLCP画像をリクエストしました。写真がpreload経由で読み込まれている場合、このチェックには「fetchpriority=high should be applied to the image preload request」と表示されます。preload側にも指定が必要です。合格すると、「fetchpriority=high applied」と表示されます。
• Request is discoverable in initial document：写真のURLがHTML自体（<img>またはpreload内）に存在し、preload scanner（HTMLを先読みするブラウザの機能）によって検出できる状態を指します。スタイルシート内の背景画像、JavaScriptでスライドを生成するスライダー、あるいはURLをdata-srcに移すlazy loadingスクリプトを使用していると、このチェックは赤色になります。
• LCP resources shouldn’t use loading=lazy：写真にloading="lazy"が指定されているため、画面内に表示されることがレイアウト計算で確定するまで、ブラウザはその画像をリクエストしません。

赤色のチェックが1つでもあると、通知全体が赤色になります。下部にある「LCP element」（HTMLコード付きのサムネイル）は、Lighthouseがスマートフォンの画面上で計測した要素を示しています。「Unscored」はこの項目自体がスコアに直接加点されないことを意味しますが、LCPはPerformanceスコアの4分の1を占めており、Googleの評価は実際の訪問者が体験する数値に基づいて行われます。この通知は、LCP要素が画像（<img>、CSS背景画像、動画のポスター画像など）である場合にのみ表示されます。

LCP画像の開始が遅れるとなぜページが遅くなるのか？

スマートフォンでは、大きな写真が入るはずの空白エリアの周りに見出しやテキストだけが表示された状態が、1秒以上続くことになります。

HTMLのダウンロード中、Chromeのpreload scannerはコードを先読みし、loading="lazy"が付いていない<img>のsrcやsrcsetにあるすべての画像を即座にリクエストします。これが、写真のダウンロードを最も早く開始できるタイミングです。それ以外の方法で配置された写真は、すべて開始が遅れます。スタイルシート内の画像は、そのCSSファイルの読み込みとレイアウト計算を待たなければなりません。style属性内にある画像やloading="lazy"が付いた画像はレイアウト計算を待ちますが、レイアウト計算の前にはすべてのrender blockingなスタイルシートの処理が必要です。スライダーやlazy loadingスクリプトの場合は、スクリプト自体のダウンロードと実行が完了するまで画像がリクエストすらされません。

この待ち時間であるresource load delayは、通常、ダウンロード自体よりも長い時間を要します。LCPが不良なサイトの中央値では、画像のリクエスト開始までに1,290 ms待たされ、その後のダウンロードはわずか350 msで終わっています（web.dev）。

ページビルダーを使ったWordPressサイトを模して作成したホテルのトップページで、同一の写真を7通りの方法で配置し、スロットリングを適用したスマートフォンでそれぞれの読み込みを計測しました。

低速4G（Slow 4G）、CPU 4倍減速の条件下で5回読み込んだ際の中央値（秒）。HTMLの到着はいずれも0.58秒でした。

どの構成でも同じ63 kBの写真が読み込まれています（スマートフォン向けの小さなファイルに切り替えられないstyle属性を除く）。差を生んだのはリクエスト開始のタイミングです。HTML内に記述された写真はHTMLが届いた瞬間にリクエストされましたが、それ以外は1.7秒時点の最初の描画や、2.4秒時点のスクリプト実行まで待たされました。

同じくスロットリングを適用したスマートフォンで、読み込み開始から2.5秒後のホテルページ。

fetchpriority="high"は、その画像が重要であることを最初の瞬間からChromeに伝え、ネットワーク接続を優先的に割り当てさせます。写真が多数のスクリプトやスタイルシートと競合するような要素の多いページでは、これによりLCPを短縮できます。GoogleがGoogle Flightsで計測した事例では、2.6秒から1.9秒へと短縮されました。ただし、これが効果を発揮するのはブラウザがすでに検出できている写真だけです。スタイルシートやスクリプト内にある写真の場合は、まずHTML側の記述を修正する必要があります。

画像にfetchpriority="high"を指定しているのに赤色のままなのはなぜか？

このチェックが見ているのは、LCP画像を実際に読み込んだリクエストです。ログアウトした状態でページのソースコードを開き、写真のファイル名を検索してください。主な原因は次のとおりです（解決策は後述）。

• 意図しないpreloadが存在する。 テーマ、ホスティングサーバー、またはCDNが、Linkヘッダーや103 Early Hintsで写真のpreloadを送信している場合があります。また、キャッシュプラグインやNext.jsがhead内に<link rel="preload">を追加していることもあります。ヘッダーを確認するには、DevToolsのNetworkパネルを開き、最初のリクエスト（ページ自体）をクリックしてHeadersを確認してください。
• lazy loadingプラグインが画像を書き換えている。 検出のチェック項目（discoverable）も赤色になっている場合は、写真にdata-srcやdata-lazy-srcが付いていないか確認してください。プラグインがURLをそこに移動させ、後からスクリプトで写真をリクエストしている状態です。
• WordPressが別の画像に属性を付与してしまった。 WordPressはファーストビュー内にある最初の大きな画像（50,000ピクセル以上）にfetchpriority="high"を自動付与します。例えば600×200ピクセルのように2倍のサイズでアップロードされたロゴが先にあると、そちらに属性が奪われてしまいます。
• Lighthouseが別の画像を計測した。 通知の下部にある「LCP element」を見れば、どの画像が対象になったかがわかります。スマートフォンの場合、モバイル専用のヒーロー画像が別で用意されており、CSSで非表示にしたデスクトップ用の写真側に属性が付いているケースがあります。

lazy loadingスクリプトを使用したホテルページ：2つのチェックが赤色になります。Lighthouse 13.6、DevToolsのスロットリング適用時。

訪問者はLCP画像をどれくらい待っているのか？

field dataを見れば、実際の訪問者がどれだけ待たされているかがわかります。CoreDashでモバイルのLCP Breakdownを開き、「More dimensions」から「LCP Priority」を選択してください。各行はLCP画像の読み込み方法を表しており、それぞれのp75 LCPが内訳に分解されています。緑色の部分がload delay（読み込み遅延）であり、HTMLが到着してから画像のダウンロードが開始されるまでの待ち時間です。URLでグループ化すれば、この遅延が長くなっているテンプレートを特定できます。

モバイルにおけるCoreDashのp75データ：各LCP Priorityの行にある緑色の部分を比較してください。

画像の開始がどれだけ遅れたかをDevToolsで確認するには？

Chrome DevToolsのPerformanceパネルでページのトレースを記録し、Insightsサイドバーで「LCP request discovery」を開きます。先ほどのホテルのテストページ（ページビルダーのスタイルシート内で写真を背景画像として指定したもの）では、HTMLの最初のバイト、つまり「最も早い開始可能ポイント（earliest start point）」からどれだけ遅れて写真のリクエストが始まったかがインサイトに表示されます。Networkトラックの縞模様のバーが、その待ち時間を示しています。

写真のリクエストがスタイルシートの後に開始されています。Chrome DevTools、Performanceパネル、スロットリングを適用したスマートフォン。

Networkパネルの写真の横にある「Initiator」列を見れば、その画像をリクエストしたファイルが特定できます。スタイルシートか、スライダースクリプトか、それとも正常なタイミングで開始できたHTML自体かが確認できます。

LCP request discoveryをどう修正するか？

ページのソースコード内で写真のファイル名を検索してください。<img>のsrcやsrcsetにあれば、ブラウザは早期に検出できます。一方、data-srcやスタイルシート内にある場合、あるいはソースコード内に見当たらない場合は、そこを変更する必要があります。目指すべきゴールは共通です。HTML内にその写真を1つの<img>として配置し、loading="lazy"を外してfetchpriority="high"を付与することです。意図せず出力されているpreloadがある場合は、fetchpriority="high"を追加するか、preload自体を無効化してください。モバイル専用のヒーロー画像を別で分けるのをやめて共通の1枚にするか、あるいは<picture>タグを使い、スマートフォン用ファイルへの<source>とfetchpriority="high"を指定した<img>で記述します。

WordPressとlazy loadingプラグイン

WordPressは、先頭の画像をlazy loadingから除外した上で、最初の大きな画像にfetchpriority="high"を付与します。それでも通知が赤色のままの場合、大抵はプラグインがこの動作を上書きしています。

• WP Rocket: デフォルトで有効な「Optimize Critical Images」は、実際のアクセスからLCP画像を学習し、fetchpriority="high"を付けてpreloadするとともにLazyLoadから除外します。キャッシュの再構築後に再度テストしてください。
• Perfmatters: 「Exclude Leading Images」と「Preload Critical Images」を、スマートフォンのファーストビュー内にある画像の数（通常は1）に設定します。
• LiteSpeed Cache: 「Lazy Load Image Excludes」に写真のファイル名を追加するか、「Viewport Images」を有効にします。
• FlyingPress: 写真にloading="eager"とpreloadが指定されているか確認してください。指定されていない場合は、lazy loadingから除外します。

ロゴは表示サイズ通りの大きさでアップロードしてください。そうすれば属性がメインの写真に正しく割り当てられます。lazy loadingの機能は1つのプラグインに絞りましょう。さもないと、片方で除外しても別のプラグインによって遅延読み込みされてしまいます。カバーブロックでは、「固定背景（Fixed background）」を使うと写真がstyle属性内の背景画像になってしまいます。これをオフにすれば、写真は再び<img>として出力されます。私が開発したプラグインWP Core Web Vitalsは、訪問者のデータから画面サイズごとのLCP画像を学習し、高い優先度で最優先に読み込みます。

Elementorなどのページビルダー

Elementorのコンテナやセクションの背景として設定された写真はElementorのCSS内に出力されるため、ブラウザはそのCSSとレイアウトの処理が終わるまで画像を見つけられません。ヒーロー写真には画像ウィジェットを使用してください（Elementorのヒーローに画像ウィジェットを使う方法）。そうすれば、「Optimized Image Loading（設定 ＞ パフォーマンス）」がWordPress標準と同様に処理してくれます。デフォルトでオンになっている「Lazy Load Background Images」は、お知らせバーの下にある背景ヒーローの読み込みを遅らせてしまうことがあります。他のページビルダーでも同様に、最初の写真には画像要素を使ってください。

スライダー

1枚目のスライドは、HTML内に<img>として配置し、loading="lazy"を付けずにfetchpriority="high"を指定する必要があります。2枚目以降のスライドにはloading="lazy"とfetchpriority="low"を指定します。スライドをJavaScriptで生成するスライダーは、そのスクリプトの実行が終わるまで1枚目のスライドの読み込みを開始できません。1枚目のスライドをHTML内に出力するスライダーを使うか、スマートフォンでは単一の静止写真を表示するようにしてください。Elementorの画像カルーセル（Image Carousel）では、「Lazyload」を有効にするとすべてのスライドのURLがdata-srcに入ってしまうため、この設定をオフにしてください。

Shopify

DawnやHorizon、およびこれらをベースにしたテーマは、テンプレートの最初のセクションにある画像にfetchpriority="high"を付与して即座に読み込みます。そのため、バナーやスライドショーを必ず最初のセクションに配置してください。Dawnの商品ページではメイン写真にfetchpriorityが設定されていません。snippets/product-thumbnail.liquidを開き、lazy_loadがfalseの場合（1枚目の写真）のimage_tagにfetchpriority: 'high'を追加してください。テーマのアップデートでこのファイルが上書きされることがあるため、更新後は属性を確認してください。アプリがJavaScriptで生成するヒーロー画像は、テーマ側の工夫に関係なく開始が遅れます。テーマ標準のセクションを使用してください。

他のテーマでは、セクションのLiquidファイル内でloading: 'lazy'やdata-srcを持つlazyloadクラスを探し、セクションの表示順序に応じて優先度を分岐させます：

{%- liquid
  assign fetch_priority = 'auto'
  if section.index == 1
    assign fetch_priority = 'high'
  endif
-%}
{{ section.settings.image | image_url: width: 1600 | image_tag: widths: '750, 1100, 1600', sizes: '100vw', fetchpriority: fetch_priority }}

loadingパラメータを指定しない場合、image_tagは4番目以降のセクションにある画像を自動的にlazy loadingします。

CSS背景画像

テーマやページビルダーに画像設定のオプションがない場合、この対応には開発者が必要です。まずは背景画像を<img>に変更します。これでブラウザがHTML内から画像を見つけられるようになり、srcsetを使えば画面サイズごとに適切なファイルを選択させることができます。object-fitを使えば、従来の背景画像と同じように領域全体を覆うことができます：

<section class="hero">
  <img class="hero-img" src="/wp-content/uploads/2026/10/terrace-1024.jpg"
    srcset="/wp-content/uploads/2026/10/terrace-768.jpg 768w, /wp-content/uploads/2026/10/terrace-1024.jpg 1024w, /wp-content/uploads/2026/10/terrace-1600.jpg 1600w"
    sizes="100vw" width="1600" height="1067" alt="Terrace above the sea" fetchpriority="high">
</section>

.hero { position: relative; }
.hero-img { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; }

どうしても背景画像のまま維持しなければならない場合は、CSSが画面サイズごとに選択するファイルを、CSSと同じメディアクエリおよびfetchpriority="high"とともにpreloadします。別のファイルをpreloadしてしまうと、写真が二重にダウンロードされます。このpreloadはそのページのテンプレートにのみ追加してください。例えば768 px未満で768 px用のファイルに切り替えるCSSの場合、次のように記述します：

<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-768.jpg" media="(max-width: 767px)" fetchpriority="high">
<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-1600.jpg" media="(min-width: 768px)" fetchpriority="high">

Next.js、Astro、React

next/imageはデフォルトでlazy loadingを行います。Next.js 15以降では、priority（バージョン16ではpreload）を指定すると画像がeagerになりpreloadされますが、fetchpriorityが付与されないためチェックは赤色のままになります。priorityは使わず、次のように両方のプロパティを自身で明示的に指定してください：

<Image src={hero} alt="Terrace above the sea" sizes="100vw" loading="eager" fetchPriority="high" />

Astro 5.10以降では、<Image>のpriorityプロパティで両方が設定されます。Reactがブラウザ側で描画するヒーロー画像は、JavaScriptが実行された後にしか存在しません。サーバー側でレンダリングするかページを事前レンダリング（prerender）し、HTML内に<img>が存在する状態にしてください。

直接変更できないヒーロー画像

写真の差し替えを行うA/Bテストや、JavaScriptでヒーロー画像を生成するウィジェットは、画像の読み込み開始を遅らせます。写真のURLが変わらないのであれば、自身のテンプレート内にfetchpriority="high"を指定したpreloadを記述することで、読み込みを前倒しできます。レスポンスが遅いサーバーでは、全画面で同じファイルを使用する画像に対して103 Early Hintsを使えば、HTMLが到着する前にダウンロードを開始できます。いずれの対応も開発者による作業が必要です。

LCP画像はHTMLと同時に開始されるようになったか？

Lighthouseを再実行してください。3つのチェックがすべて緑色になり、写真がLCP要素として認識されているはずです。DevToolsでは、写真のリクエストがHTMLの直後に開始されます。すべて合格したにもかかわらずLCPがまだ遅い場合は、LCPの他の構成要素を確認してください。遅いサーバー（time to first byte）、写真のダウンロード時間の長さ（load duration）、あるいは描画を妨げているスタイルシートやスクリプト（render delay）が原因として考えられます。実際の訪問者への影響については、CoreDashを使ってスマートフォンでのload delayを監視してください。Search Consoleへの反映には最大28日かかります。

Core Web Vitals パワーアワーは、本記事の解説だけでは対応しきれない画像のためのサポートです。設定項目がないページビルダー、スライダー、アプリによって出力されている画像や、3つのチェックすべてに合格しているのにスマートフォンでのLCPが依然として遅いケースが該当します。実際のページのトレースをHTMLの受信から画面表示まで追跡し、何がボトルネックになっているのかを突き止めます。