Core/Dashディメンション： LOAF

Long Animation Framesを発生源に特定することで、main threadをブロックしINPを悪化させている正確なスクリプトのURLを見つけ出します。

無料トライアル

Trusted by market leaders · Client results

ディメンション：Long Animation Frames (lurl)

LOAFディメンションは、ユーザーのセッション中にLong Animation Framesを引き起こしたスクリプトのURLを特定します。それぞれの値は、ファーストパーティのバンドル、サードパーティのアナリティクスタグ、チャットウィジェット、同意管理マネージャーなど、レンダリングをブロックするのに十分な長さで実行されたスクリプトのURLです。これは発生源レベルでの特定であり、DevToolsで再構成する必要がある単なるスタックトレースではありません。

CoreDashは、Chromeが従来のLong Tasks APIの代替として提供しているLong Animation Frames API (LoAF)を使用してこのデータを収集します。Long Tasksはフレームの処理時間が長すぎることしか教えてくれませんでしたが、LoAFはそのフレーム内でどのスクリプトが実行され、そのURLが何であったかを示します。この違いこそが、本番環境でこのディメンションが有用である理由です。

coredash loaf scripts

なぜLong Tasksだけでは不十分だったのか

Long Tasks API（2017年から利用可能）は、50msを超えるmain threadのタスクを検出しましたが、その特定情報はほとんど提供されませんでした。ブロッキングが発生したことは分かっても、何が原因であるかは分からなかったのです。開発者はタスクのタイムスタンプとネットワークのウォーターフォールを突き合わせ、どのスクリプトが原因であるかを推測するために何時間も費やしていました。

LoAF APIはこれを変えます。このAPIはPerformanceLongAnimationFrameEntryオブジェクトを報告し、その中にはscripts配列が含まれています。配列の各エントリには、invokerType、sourceURL、durationが含まれます。CoreDashは、長いフレーム中に実行された各スクリプトのsourceURLを読み取り、それをLOAFディメンションの値として保存します。その結果、ユーザーの長いフレームに出現した頻度順にソートされたスクリプトURL of ランキングリストが得られます。

CoreDashにおけるLoAFデータの活用方法

ユーザー操作によって長いアニメーションフレームが発生するたびに、CoreDashはその原因となったスクリプトのURLをINPの測定値とともに記録します。これにより、INPデータをLOAF URLでフィルタリングし、最悪の操作の原因となっているスクリプトを特定できます。このディメンションはURLごとにグループ化されるため、各スクリプトが長いフレームを引き起こしたセッションの数を確認できます。

LOAFディメンションでよく見られるエントリの例：

https://www.googletagmanager.com/gtm.js (Google Tag Manager コンテナ)
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は、ユーザー操作から次のフレームが描画されるまでの時間を測定します。その間隔が200msを超えると、Googleはそのユーザー体験を「改善が必要」と分類します。LoAFデータは、その間隔の間にどのスクリプトが実行されたかを示します。280msのINPのうち210msが同意管理スクリプトに起因するケースは、280ms of INPのうち190msが自社のチェックアウトハンドラーに起因するケースとはまったく異なる問題です。修正方法も、担当チームも、緊急度も異なります。

LoAFによる原因特定がなければ、INPのヒストグラム上では両者はまったく同じに見えます。しかし、LoAFデータがあれば、すぐに適切な担当者に問題を割り振ることができます。

デバッグのワークフロー

CoreDashでLOAFディメンションを開く： 頻度（そのURLが長いフレーム内で検出されたセッションの数）でソートします。最上位のエントリが最優先のターゲットです。
INPとクロスフィルタリングする： INPメトリックのビューにLOAFフィルターを適用します。そのスクリプトが実行されたセッションのみを抽出したときに、INPのp75が変化するかどうかを確認します。30ms以上の増加が見られる場合、そのスクリプトが本番環境でINPを悪化させている原因であることが裏付けられます。
ファーストパーティかサードパーティか分類する： URLが自社ドメインであれば、自ら修正を管理できます。サードパーティのCDNのURLである場合は、そのベンダースクリプトを削除、遅延読み込み、または別のものに置き換える必要があります。
修正を適用して検証する： サードパーティスクリプトの場合、ファサードや遅延初期化を使用して、最初のユーザー操作の後まで読み込みを遅らせます。ファーストパーティコードの場合、Chrome DevToolsのCPUスロットリングを4倍に設定し、特定の関数をプロファイリングします。変更をデプロイし、実際のユーザートラフィックが流入してから24〜48時間以内にLOAFディメンションが更新されることを確認します。

エンジニアリングの経験則

5%以上のセッションで長いフレームに出現するスクリプトURLは、調査する価値があります。 その割合に達している場合、1か月を通じて実際のユーザーの無視できない割合に影響を与えています。
サードパーティのスクリプトは、インタラクションハンドラーの実行中に動作させるべきではありません。 タグマネージャーがクリックイベント時に同期的に実行される場合、それはブラウザの制限ではなく、設定の問題です。
単一スクリプトの長いフレームの処理時間が200msを超えている場合は、明確なシグナルです。 LoAF APIはフレーム内のスクリプトごとの処理時間を報告します。フレームの200ms以上を消費しているスクリプトは、その後に続くあらゆるINP値の主な原因です。
LOAFのリストにあるファーストパーティスクリプトは、フレームワークのオーバーヘッドを指し示していることがよくあります。 React、Vue、Angularはすべて、状態更新の際に長いフレームを生成する可能性があります。LoAF URLは自社のバンドルになります。ネットワークだけでなく、コンポーネントツリーをプロファイリングしてください。

LOAFディメンションは、合成テストでは決して得られないものを提供します。それは、本番環境でどのスクリプトが実際のユーザーをブロックしているかを示す確たる証拠であり、現実世界での発生頻度順に並べられています。このディメンションでフィルタリングし、INPデータとクロス参照すれば、何をどの順番で修正すべきかを示す優先順位付きのリストが完成します。