Trusted by market leaders · Client results
ディメンション: アトリビューション要素 (CLS、INP、LCP)
アトリビューション要素の指標 (clsel、inpel、lcpel) は、Core Web Vitalsイベントに関連付けられたHTML要素のノード名と特定のCSSセレクタを返します。
URLディメンションがアプリケーションのどこでパフォーマンスが低下しているかを示すのに対し、アトリビューション要素は、どの特定のコンポーネントがそのスコアの要因となっているかを示します。この粒度により、エンジニアリングの議論は一般的なページレベルの最適化から、特定のDOMレベルのターゲティングへと変化します。
アトリビューション要素フィルタリングの目的: 検証と発見
このディメンションは、パフォーマンスのワークフローにおいて2つの主要な戦略的機能（ターゲットの検証と動作の発見）を果たします。
- ターゲットの検証: 間違ったノードをターゲットにしていては、LCPを最適化することはできません。開発者はしばしば「ヒーロー画像」がLCP要素であると仮定して最適化を行いますが、ブラウザが実際にはテキストブロックやCookieバナーをLCPとしてフラグ付けしていたため、指標が改善しないことに気づくことがよくあります。このディメンションは、ブラウザが正確にどの要素を測定しているかを確認します。
- 動作の発見: ユーザーは、QA中に予想しない方法でサイトとやり取りします。ズームを期待して静止画像をクリックしたり、反応のないUI要素を怒りに任せて連打（レイジクリック）したりします。このディメンションは、高レイテンシを引き起こす、ユーザーが実際に操作した要素を明らかにし、テストカバレッジの死角を浮き彫りにします。
指標別のシナリオ
アトリビューション要素を表示する際、各Core Web Vitalsにはそれぞれ異なる分析アプローチが必要です。
Largest Contentful Paint (LCP)
LCPのアトリビューション要素は、「リソースの優先順位」に対する監査ツールです。これは「画面上の最大の要素は、自分が設計した通りの要素か？」という問いに答えます。
- 「予期しない」LCP:
div.cookie-consentやp.intro-textのような要素がLCPノードとして表示されることがよくあります。これは通常、読み込みエラーではなく、レスポンシブデザインの現実を示しています。特定のビューポート（特にモバイル）では、「ヒーロー画像」がテキストブロックよりも小さくレンダリングされたり、ファーストビューの完全に下に押しやられたりする場合があります。テキストブロックが画像よりもビューポート内で物理的により多くのピクセルを占有している場合、ブラウザはテキストをLCPとして正しく識別します。これらの要素をデバイスのフォームファクタディメンションと相互参照して、モバイルレイアウトが画像よりもテキストを主要コンテンツとして優先していないかを確認する必要があります。 - 「想定通り」のLCP: このディメンションによって、意図した
img.hero-bannerが実際にLCP要素であることが確認された場合、アセット固有の最適化を行うゴーサインが出たことになります。この特定の画像ファイルへの直接的な介入（圧縮、フォーマット変更、キャッシュ）が、総合スコアに直接影響を与えることが確実に分かります。
Interaction to Next Paint (INP)
INPの問題は、多くの場合、ユーザーの意図とインターフェースの応答性の不一致から生じます。このディメンションは、メインスレッドのブロックを引き起こす特定のクリック、タップ、またはキープレスのターゲットを強調表示します。
- 「隠れた」インタラクション: IMG.product-detailやDIV.background-wrapperなど、「インタラクティブ」とは見なしていなかった要素に高いINP値が付与されていることがあります。これは、ユーザーが存在しないフィードバック（ライトボックスやズームなど）を期待してこれらの要素をクリックしているか、本来そこにあるべきではない重いJavaScriptリスナーが実行されていることを示しています。
- 重い機能: INPUT.search-barやBUTTON.add-to-cartのような一般的なターゲットがここに頻繁に表示されます。これにより、パフォーマンスのボトルネックがこれらのコントロールにアタッチされた特定のイベントハンドラーに分離されます。遅延が一般的なページのラグではなく、その機能に結びついた特定の計算コスト（例：検索のオートコンプリートスクリプトの実行が過剰であるなど）であることが確認できます
Cumulative Layout Shift (CLS)
CLSのデバッグが難しいのは、「シフトする」要素が他の場所への動的コンテンツの挿入の被害者であることが多いためです。アトリビューション要素は、被害者である「移動した要素」を特定します。
- 原因の追跡: このディメンションでDIV.content-bodyがシフトしている要素として報告された場合、通常はDOM内のそのノードの直上を確認します。content-body自体が問題であることはまれです。遅延読み込みされる広告枠、バナー、またはフォントファイルの入れ替えなどのインジェクターによって押し下げられているのです。
- クラスター分析: これらのアトリビューションをグループ化することで、レイアウトの不安定性がシステム全体のものなのか（例：すべてのページロードで
footerがシフトする）、または特定のコンテンツタイプに固有のものなのか（例：プロフィールページでのみimg.user-avatarがシフトする）を確認できます。
要素ごとのCore Web Vitalsの改善
アトリビューション要素のディメンションを使用して、ユーザーへの影響に基づいてエンジニアリングバックログの優先順位付けを行います。
- 影響度によるソート: CoreDashテーブルで、影響度（Impact）列でソートします。これにより、グローバルスコアに最も大きなダメージを与えている特定のDOM要素がトップに浮上します。
- コンポーネントの分離:
button.submit-formがINPにおける最大の問題児である場合、一般的なJavaScriptバンドルの調査を止め、その特定のボタンのonsubmitハンドラーに完全に集中することができます。 - 修正の検証: 修正を展開した後（例：広告枠のスペースを確保するなど）、CLSのアトリビューション要素を監視します。特定のノードがリストから消えれば、修正は成功です。ノードが残っていてもスコアがわずかに改善した場合は、ズレを緩和しただけで解決には至っていないことを意味します。
