Trusted by market leaders
ディメンション：ページ & ナビゲーション：URL (u)
要素タイプ (LCP) ディメンション (lcpet) は、Largest Contentful Paint ノードを text、image、background-image、または video の4つの構造クラスのいずれかに分類します。
Attribution Element ディメンションが正確な DOM ノードを特定するのに対し、要素タイプディメンションはハイレベルなエンジニアリング戦略を決定づけます。LCP は、TTFB、Load Delay、Load Time、Render Delay という4つのタイミング間隔の合計です。要素タイプは、これらの間隔のうちどれがスコアを悪化させているかを示し、推測に頼ることなく正しい最適化プロトコルを選択可能にします。
LCP 要素タイプによる Core Web Vitals の最適化
LCP 要素タイプとは無関係な TTFB を改善した後は、LCP 要素に着目し、異なるアプローチで LCP の最適化に取り組む必要があります。
1. テキスト
CoreDash が要素タイプとしてテキストを報告する場合、静的ネットワークリソースの帯域幅がボトルネックになることは稀です。テキストは HTML ドキュメント内に直接存在するため、最初のサーバー応答 (TTFB) の直後にコンテンツが利用可能になります。ここで LCP が遅い場合、問題はほぼ間違いなく Render Delay にあります。
これを修正するには、クリティカルレンダリングパスに全力を注いでください。ブラウザは、重い CSS 計算や <head> 内の同期 JavaScript によって、テキストの描画をブロックされている可能性が高いです。さらに、フォント読み込み戦略を確認してください。font-display: swap または optional を使用していない場合、ブラウザはフォントファイルのダウンロードを待つ間、人為的にテキストを隠してしまいます（FOIT）。
2. 画像 (<img>)
このタイプは、発見、ダウンロード、デコードという完全なリソースパイプラインをトリガーします。テキストとは異なり、画像の LCP は Load Delay と Load Time に大きく依存します。ここでは物理法則やネットワークレイテンシとの戦いとなるため、アセットを軽量化し、より早く発見できるようにすることが目標となります。
ここでの最適化には、厳格なアセット管理が必要です。Load Delay を最小限に抑えるために、<img> タグが初期 HTML ソース（サーバーサイドレンダリング）に存在することを確認してください。fetchpriority="high" を追加し、loading="lazy" 属性は厳密に削除してください。これらはブラウザのリクエストを遅延させるためです。最後に、次世代フォーマット（AVIF/WebP）を提供し、srcset を使用してモバイルデバイスがデスクトップサイズのファイルをダウンロードしないようにすることで、Load Time に対処します。
3. 背景画像
この分類は、アーキテクチャ上の非効率性を示唆しています。画像が CSS（例：background-image: url(...)）で定義されているため、ブラウザはスタイルシートを完全にダウンロードして解析するまで URL を発見できません。プリロードスキャナが事実上アセットを認識できないため、これにより大幅な Load Delay が発生します。
唯一の堅牢なエンジニアリングによる修正方法は、リファクタリングです。視覚的アセットを CSS から標準の HTML <img> タグに移動し、URL を即座にブラウザに公開してください。マークアップのリファクタリングが不可能な場合は、ドキュメントヘッド内で <link rel="preload"> を使用して早期発見を強制する必要がありますが、これはネイティブの画像要素を使用する場合に比べてメンテナンスの負担になることがよくあります。
4. 動画
LCP 要素が動画の場合、ブラウザはポスター画像または（自動再生の場合は）最初のフレームの描画時間を測定します。これは画像タイプと同様の挙動を示しますが、動画アセットのファイルサイズが大きいため、多くの場合より重くなります。
これは厳密に画像最適化タスクとして扱ってください。ブラウザが最初のピクセルを描画するために動画セグメントをダウンロードしなくて済むよう、軽量な poster 属性が HTML 内に存在することを確認してください。標準的な LCP 画像と同様に、ポスター画像を積極的に圧縮してください。
ワークフロー：LCP 要素タイプに基づく LCP の問題の発見
LCP 要素タイプは静的なものではなく、すべての訪問者にとって同じでもありません。ユーザーのデバイスに基づいて頻繁に変化し、レスポンシブデザインの根本的な欠陥を明らかにします。
CoreDash のデバイスフォームファクタフィルタを使用して、モバイルとデスクトップ間の要素タイプを比較してください。デスクトップユーザーは画像の LCP（例：ヒーローバナー）を取得し、モバイルユーザーはテキストの LCP を取得するというケースがよく見られます。これは、モバイルの CSS レイアウトがヒーローバナーをファーストビュー（above the fold）より下に押しやっているか、あるいは大幅に縮小しているために、テキストの段落が「最大（Largest）」の要素になっていることを裏付けています。
このシナリオでモバイルの LCP を改善するためにヒーロー画像を最適化しているなら、それは無駄な努力です。ブラウザはその画像をカウントさえしていません。レイアウトを調整して画像をメインビューに戻すか、モバイルユーザー向けのテキストレンダリング（フォント/CSS）の最適化に焦点を移す必要があります。
