ディメンション: Long Animation Frames (lurl)
LOAF ディメンションは、ユーザーのセッション中に Long Animation Frames を引き起こしたスクリプトの URL を表示します。各値はスクリプトの URL です。ファーストパーティのバンドル、サードパーティのアナリティクス タグ、チャット ウィジェット、同意管理マネージャー、またはレンダリングをブロックするほど長く実行されたその他のものが含まれます。これは、DevTools で再構築しなければならない単なるスタック トレースではなく、ソース レベルでの帰属です。
CoreDash は、[url=https:\/\/developer.chrome.com\/docs\/web-platform\/long-animation-frames]Long Animation Frames API (LoAF)[\/url] を使用してこのデータを収集します。これは、Chrome が古い Long Tasks API の代替として提供しているものです。Long Tasks はフレームに時間がかかりすぎたことしか教えてくれませんでしたが、LoAF はそのフレーム内でどのスクリプトが実行され、その URL が何であったかを教えてくれます。この違いこそが、このディメンションを本番環境で有用なものにしています。
なぜ Long Tasks では不十分だったのか
2017 年から利用可能な Long Tasks API は、50 ミリ秒を超えるメインスレッド タスクにフラグを立てましたが、帰属情報はほとんど得られませんでした。ブロックが発生したことはわかりますが、何が原因かはわかりませんでした。開発者は、タスクのタイムスタンプとネットワーク ウォーターフォールを関連付けることに何時間も費やし、どのスクリプトが原因であるかを推測していました。
LoAF API はこれを変えます。これは PerformanceLongAnimationFrameEntry オブジェクトを報告し、各オブジェクトには scripts 配列が含まれています。その配列の各エントリには、invokerType、sourceURL、および duration があります。CoreDash は、長いフレーム中に実行された各スクリプトの sourceURL を読み取り、LOAF ディメンション値として保存します。その結果、ユーザーの長いフレームに表示される頻度でランク付けされたスクリプト URL のリストが得られます。
CoreDash が LoAF データをどのように活用するか
ユーザー インタラクションが Long Animation Frame をトリガーするたびに、CoreDash は INP の観察結果とともに、寄与したスクリプト URL を記録します。つまり、INP データを LOAF URL でフィルタリングして、どのスクリプトが最悪のインタラクションの原因であるかを確認できます。ディメンションは URL ごとにグループ化されるため、そのスクリプトが長いフレームを引き起こしたセッションの数を確認できます。
LOAF ディメンションに表示される典型的なエントリ:
https:\/\/www.googletagmanager.com\/gtm.js (Google タグ マネージャーのコンテナ)
https:\/\/cdn.cookielaw.org\/consent\/... (OneTrust または同様の同意管理プラットフォーム)
https:\/\/js.intercomcdn.com\/... (チャット ウィジェット)
\/static\/js\/app.bundle.js (自社のアプリケーション コード)
https:\/\/connect.facebook.net\/en_US\/fbevents.js (Meta ピクセル)CoreDash のデータでは、サードパーティ スクリプトが約 60 ～ 70% のサイトで Long Animation Frames の原因となっています。タグ マネージャーだけでも、監視対象のプロパティの約 45% で長いフレームに寄与しています。残りはファーストパーティのバンドルが占めており、通常は React の再レンダリングや最適化されていないイベント ハンドラーが原因です。
LoAF による INP への帰属
INP は、ユーザー インタラクションから次のフレームの描画までの時間を測定します。そのギャップが 200 ミリ秒を超えると、Google はその体験を「改善が必要」と分類します。LoAF データは、そのギャップの間にどのスクリプトが実行されたかを教えてくれます。INP が 280 ミリ秒で、そのうち 210 ミリ秒が同意管理スクリプトに起因する場合、INP が 280 ミリ秒で 190 ミリ秒が自社のチェックアウト ハンドラーに起因する場合とは、全く異なる問題です。修正方法も、担当チームも、緊急度も異なります。
LoAF による帰属がなければ、どちらも INP ヒストグラムでは同じに見えます。LoAF があれば、すぐに適切な担当者に問題を割り振ることができます。
デバッグのワークフロー
- CoreDash で LOAF ディメンションを開く: 頻度 (その URL が長いフレームに表示されたセッション数) でソートします。一番上のエントリが、最優先のターゲットです。
- INP とクロスフィルタリングする: INP 指標ビューに LOAF フィルタを適用します。そのスクリプトが実行されたセッションを分離したときに、INP p75 が変化するかどうかを確認します。30 ミリ秒以上の増加があれば、そのスクリプトが本番環境での INP 低下に寄与していることが確認されます。
- ファーストパーティかサードパーティかを分類する: URL に自社ドメインが含まれている場合は、自分で修正をコントロールできます。サードパーティの CDN URL の場合は、ベンダー スクリプトを削除、遅延、または置換する必要があります。
- 修正を適用して検証する: サードパーティ スクリプトの場合は、ファサードや遅延初期化を使用して、最初のユーザー インタラクション後までロードを遅らせます。ファーストパーティ コードの場合は、CPU スロットリングを 4 倍に設定した Chrome DevTools で特定のプロファイルのプロファイルを作成します。変更をデプロイし、実際のユーザー トラフィックから 24 ～ 48 時間以内に LOAF ディメンションが更新されるのを確認します。
エンジニアリングの目安
- 5% 以上のセッションで長いフレームに表示される単一のスクリプト URL は、調査する価値があります。 その割合であれば、1 か月を通じてかなりの数の実ユーザーに影響を与えています。
- サードパーティ スクリプトは、インタラクション ハンドラー中に実行すべきではありません。 クリック イベントでタグ マネージャーが同期的に起動する場合、それはブラウザの制限ではなく構成の問題です。
- 単一のスクリプトで 200 ミリ秒を超える長いフレーム期間は、明確なシグナルです。 LoAF API はフレーム内のスクリプトごとの期間を報告します。フレームの 200 ミリ秒以上を消費しているスクリプトは、その後に続く INP の主な原因です。
- LOAF リストのファーストパーティ スクリプトは、フレームワークのオーバーヘッドを指していることがよくあります。 React、Vue、Angular はすべて、状態の更新中に長いフレームを生成する可能性があります。LOAF URL は自社のバンドルになります。ネットワークだけでなく、コンポーネント ツリーのプロファイルを作成してください。
LOAF ディメンションは、合成テストでは得られないもの、つまり本番環境でどのスクリプトが実ユーザーをブロックしているかの証拠を、実世界の頻度でランク付けして提供します。これでフィルタリングし、INP データとクロスリファレンスすれば、何をどの順番で修正すべきかを示す優先順位付きリストが得られます。
[include]sidebarcoredash.html[\/include]