Core/Dash ディメンション: 要素タイプ (LCP)
アーキテクチャの要素タイプに基づいてトラフィックをフィルタリングすることで、Largest Contentful Paint を修正します。
Trusted by market leaders · Client results
ディメンション：リソース：要素タイプ LCP (lcpet)
要素タイプ (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. テキスト (Text)
CoreDash が要素タイプとしてテキストを報告する場合、静的ネットワークリソースの帯域幅がボトルネックになることはほとんどありません。テキストは HTML ドキュメント内に直接存在するため、コンテンツは最初のサーバー応答 (TTFB) 後にすぐに利用可能になります。ここで LCP が遅い場合、問題はほぼ間違いなくレンダリング遅延 (Render Delay) です。
これを修正するには、クリティカルレンダリングパス (Critical Rendering Path) に完全に焦点を当てます。ブラウザは、重い CSS 計算や <head> 内の同期 JavaScript によってテキストの描画をブロックされている可能性があります。さらに、フォントの読み込み戦略も確認してください。font-display: swap または optional を使用していない場合、ブラウザはフォントファイルのダウンロードを待っている間、人工的にテキストを隠しています (FOIT)。
2. 画像 (<img>)
このタイプは、発見、ダウンロード、デコードというリソースパイプライン全体をトリガーします。テキストとは異なり、画像の LCP はロード遅延とロード時間に大きく依存します。ここでは物理法則やネットワークのレイテンシと戦っているため、目標はアセットを軽くし、より早く発見できるようにすることです。
ここでの最適化には厳密なアセット管理が必要です。ロード遅延を最小限に抑えるために、初期の HTML ソースに <img> タグが存在することを確認してください (サーバーサイドレンダリング)。fetchpriority="high" を追加し、ブラウザの要求を遅らせる loading="lazy" 属性は厳密に削除してください。最後に、次世代フォーマット (AVIF/WebP) を提供し、srcset を使用してモバイルデバイスがデスクトップサイズのファイルをダウンロードするのを防ぐことで、ロード時間に取り組みます。
3. 背景画像 (Background Image)
この分類は、アーキテクチャの非効率性を示しています。画像は CSS (例: background-image: url(...)) で定義されているため、ブラウザはスタイルシートを完全にダウンロードして解析するまで URL を発見できません。プレロードスキャナ (Preload Scanner) は実質的にこのアセットを認識できないため、大規模なロード遅延が発生します。
堅牢な唯一のエンジニアリング修正はリファクタリングです。ビジュアルアセットを CSS から標準の HTML <img> タグに移動して、URL をブラウザにすぐに公開します。マークアップをリファクタリングできない場合は、ドキュメントの head に <link rel="preload"> を使用して早期発見を強制する必要がありますが、これはネイティブの画像要素を使用する場合と比較して、多くの場合メンテナンスの負担になります。
4. ビデオ (Video)
LCP 要素がビデオの場合、ブラウザはポスター画像または最初のフレーム (自動再生の場合) の描画時間を測定します。これは画像タイプと同様に機能しますが、ビデオアセットのファイルサイズのため、より重くなることがよくあります。
これを厳密に画像最適化タスクとして扱ってください。軽量のポスター属性が HTML に存在することを確認し、最初のピクセルをレンダリングするためにブラウザがビデオセグメントをダウンロードしなくても済むようにします。標準の LCP 画像と同じように、ポスター画像を積極的に圧縮します。
ワークフロー：LCP 要素タイプに基づいた LCP の問題の発見
LCP 要素タイプは静的ではなく、すべての訪問者で同じというわけでもありません。ユーザーのデバイスに基づいて頻繁に変更され、レスポンシブデザインの根本的な欠陥を明らかにします。
CoreDash のデバイスフォームファクタ (Device Form Factor) フィルターを使用して、モバイルとデスクトップの間で要素タイプを比較します。デスクトップユーザーには画像の LCP (例: ヒーローバナー) が表示される一方で、モバイルユーザーにはテキストの LCP が表示されることがよくあります。これは、モバイルの CSS レイアウトがヒーローバナーをファーストビューより下に押しやっているか、テキストの段落が「最大」の要素になるほど大幅に縮小していることを裏付けています。
このシナリオで、モバイルの LCP を改善するためにヒーロー画像を最適化している場合、努力の無駄になります。ブラウザは画像さえもカウントしていません。画像をメインビューに戻すようにレイアウトを調整するか、モバイルユーザー向けにテキストレンダリング (フォント/CSS) の最適化に焦点を移す必要があります。
