ディメンション: リソース: LCP Priority
LCP Priorityディメンションは、ブラウザがLCPリソースをどのように検出し、優先順位を付けたかに基づいてパフォーマンスデータをセグメント化します。「Element Type」ディメンションは要素の種類(テキストか画像か)を示すのに対し、このディメンションはブラウザがなぜその読み込みを遅延させたのかを示します。
これは、Load Delayを監査するための主要なツールです。LCPアセットが帯域幅を奪い合っているのか、それとも正しくないHTML属性によって人為的に遅延させられているのかを明らかにします。

優先順位の階層
ブラウザはすべてのリソースにダウンロードの優先順位を割り当てます。このディメンションは、LCP要素を5つの具体的な読み込み状態のいずれかにマッピングします。これらは、最も悪影響の大きいもの(Lazy Loaded)から、最も最適なもの(Text/High Priority)まで順にランク付けされています。
背景: ユーザーが「戻る」ボタンや「再読み込み」ボタンでページに戻ると、ほとんどのブラウザは前回のスクロール位置にユーザーを戻します。この位置がファーストビューより下(below the fold)である場合、最適化されたヒーロー画像はもはやLCPではありません。代わりに、ブラウザは現在のviewport内にある最も大きな要素を計測します。これにより、データセットに避けられない「Not Preloaded」のイベント群が発生します。しかし、これはまったく問題ありません!
1. Lazy Loaded
LCP要素の10%以上がこのバケットに含まれる場合、問題が発生しています。lazy loadingされる画像は、キューに入るのが大幅に遅れます(高速なpreload scannerではなく、低速なDOM parserによるためです)。このloading="lazy"属性は、レイアウトが計算され、要素がviewportに近づくまでダウンロードを待機するようブラウザに指示します。
解決策: このloading属性を削除する必要があります。LCP要素を決してlazy loading of 対象にしてはいけません。
<!-- 誤り --> <img src="hero.jpg" loading="lazy" alt="Hero Image" /> <!-- 正しい例 --> <img src="hero.jpg" fetchpriority="high" alt="Hero Image" />
2. Not Preloaded
これはブラウザのデフォルトの動作を示しています。ブラウザは初期パース時にHTML内の画像を検出したものの、他の画像より優先してダウンロードするような指示を受けていません。
ページ速度への影響は、ウェブページの複雑さに依存します。LCP画像はリソース競合キューに入ります。ページ内にダウンロードすべきスクリプト、フォント、他の非遅延画像、あるいはスタイルシートが多く存在する場合、ブラウザはこの画像のダウンロードを後回しにし、Load Delayが増加する原因になります。
3. Preloaded
これは、ドキュメントのhead内にある<link rel="preload">タグを介してリソースが検出されたことを示します。このpreloadリンクにより、画像への参照がDOMの奥深くに埋め込まれている場合や、CSSファイル(背景画像)内に隠されている場合であっても、基本的に早期検出が可能になります。
プリロードはダウンロードを強制的に早める最も効果的な方法ですが、画像のURLと完全に一致する個別のリンクタグを管理し続ける必要があります。両者が乖離してしまうと、アセットを二重にダウンロードすることになります。
4. High fetchpriority
これは現在の開発標準です。ブラウザはfetchpriority="high"属性によって、この特定の画像を最優先リソースとして扱うよう指示されます。
アプローチ: これは画像ベースのLCPにおける目標状態です。手動のpreloadタグを維持管理する手間をかけずに、要素自体に直接重要性を指示し、ダウンロードキュー内の優先順位を他のアセットより高めることができます。
5. Not an Image
ステータス: テキストノード / SVG
LCP要素がテキストブロック(h1、p)または生のSVGである状態です。テキストはHTMLドキュメントに最初から含まれているため、Load Delayがゼロになります。これはアーキテクチャとして理想的な状態です。
最適化方法: LCPがこのカテゴリに属しているにもかかわらず遅い場合、ボトルネックは完全にRender Delayにあります。ダウンロードする画像ファイルが存在しないため、Critical Rendering Path(CSS/JSのレンダリングブロック)またはフォントの読み込み戦略(font-display: swap)を最適化する必要があります。
ワークフロー: Load Delayの最適化
このディメンションを使用して、フロントエンドのリソース戦略を検証します。
- lazy loadingの排除: Lazy Loadedでフィルタリングします。この値が0%より大きい場合、ヒーロー画像に
loading="lazy"を付与しているコンポーネントを見つけて削除してください。これは、すべてのメディアにグローバルにlazy loadingを適用するCMSテンプレートでよく見られる問題です。 - Fetchpriorityへの移行: トラフィックをNot PreloadedおよびPreloadedからHigh fetchpriorityへ移行させます。
<link rel="preload">をfetchpriority="high"に置き換えることで、<head>内が整理され、優先度判定のロジックをコンポーネントに直接ひも付けることができます。 - 背景画像の監査: Not Preloadedのトラフィックが多く、LCPが背景画像である場合、ブラウザがその画像を検出するのが遅すぎます(CSSが解析された後にしか検出されません)。これを、
fetchpriority="high"を指定したHTMLの<img>タグに書き換えるか、Preloadヘッダーを強制送信させてください。
開発における経験則
このディメンションにおける配信目標は極めて厳格です。
- 10%未満 Lazy Loaded
- 90%超 High fetchpriority(画像LCPの場合)
- 100% Not an image(テキストLCPの場合)
「Not Preloaded」に分類されるトラフィックは、リソース優先度の制御をブラウザのデフォルトのヒューリスティック(自己判断)に委ねてしまっている未最適化の状態を意味します。

