ブラウザ モニタリングのPageViewTimingイベントは、各データ ポイントが利用可能になるとすぐに個別のイベントとして送信します。タイミングを制限していないため、発火のタイミングに関係なく、最初のペイントまたは最初のインタラクション データを受け取ることができます。このドキュメントでは、 PageViewTimingとその属性を使用してサイト、コンポーネントの読み込み、およびユーザー パフォーマンス メトリックに関するデータを照会する理由と方法について、ビジュアルと応答性の両方の観点から説明します。
PageViewTimingを使う理由は？
非同期ページや動的ページを使用しているアプリケーションでは、サイトやコンポーネントの読み込みに関する追加情報が必要な場合があります。しかし、ページは様々な方法でコンテンツをロードすることができ、ユーザーはいつそのコンテンツとインタラクトするかをコントロールすることができます。このような理由から、ユーザー中心のパフォーマンス指標は、ブラウザエージェントの標準的なウィンドウのオンロード（ページロード時間）の外側で行われます。
例えば、ユーザーはせっかちになり、コンテンツがウェブページに表示されるとすぐにクリックし始めるかもしれません。あるいは、コンテンツが読み込まれてからしばらくしてからページの利用を始めるかもしれません。
PageViewTimingイベントは、他のイベントに依存しない、よりリアルタイムの配信メカニズムを提供します。追加のメトリックは、視覚的および応答性の両方の観点から、ユーザーがサイトをどのように体験するかを理解するのに役立ちます。
GoogleのCore Web Vitalsへの対応
ブラウザ監視用のエージェント バージョン 1177の時点で、 Google の Core Web Vitalsを完全にサポートしています。この機能は、エージェントのすべてのフレーバー (Lite、Pro、または Pro+SPA) で使用できます。
なお、Core Web Vitals を構成するメトリクスは、時間の経過とともに 進化しています。現在のセットは、ユーザーエクスペリエンスの3つの側面（読み込み、双方向性、視覚的安定性）に焦点を当てています。以下の指標とそれぞれのしきい値が含まれています。
Web Vitalsの主な評価基準は、読み込み、インタラクティブ性、視覚的安定性です。
- Largest Contentful Paint (LCP) : 読み込みパフォーマンスを測定します。良好なユーザーエクスペリエンスを提供するために、LCPは ページが最初にロードを開始してから 2.5秒以内に発生する必要があります。
- First Input Delay (FID) : インタラクティブ性を測定します。良いユーザー体験を提供するために、ページのFIDは 100ミリ秒以下であるべきです 。
- Cumulative Layout Shift (CLS) : 視覚的な安定性を測定します。良いユーザーエクスペリエンスを提供するために、ページはCLS 0.1以下を維持する必要があります。.
これらの指標について、ほとんどのユーザーに推奨されるターゲットを達成していることを確認するためには、モバイルデバイスとデスクトップデバイスに分けて、ページロードの 75パーセンタイル を測定するのが良い閾値となります。
もっと詳しく知りたい方は、 Nerd Days talk on perceived performanceをご覧ください。
ビジュアル、インタラクティブ性、応答性の詳細な評価指標
BrowserInteractionイベントとPageViewイベントは、ページ ウィンドウの読み込み(またはウィンドウの読み込みと AJAX) のタイミングを受け取ると、レポートを終了します。ただし、ペイントとインタラクティブ メトリックはいつでも発生する可能性があります。PageViewTimingは、これらの指標を個別のイベントとして次の目的に配信します。
- このタイミングのばらつきを考慮する。
- 任意のタイムアウトを設定することは避けてください。
BrowserInteractionおよびPageViewイベントを無期限に保持しないようにします。
追加データ | コメントコメント |
|---|---|
|
|
|
Google の調査によると、最大の要素がレンダリングされたタイミングを見ることが、ページのメインコンテンツが読み込まれて有用になったタイミングを測定するより正確な方法であることがわかりました。この指標についての制限や考慮点などの詳細は、 w3c draft をご覧ください。 また、LCP を使用した累積レイアウト シフト (CLS) スコア属性も報告します。この属性は Largest Contentful Paint は、Google が Core Web Vitals として特定した 3 つのメトリクスのうちの 1 つです。LCP値が2.5秒までは"「良好」、" 2.5～4.0秒は"「改善が必要」、" 4.0秒以上は"「不良」とされています。" |
|
また、ユーザーの最初のインタラクションの時点での累積レイアウト シフト (CLS) スコア属性も報告します。この属性は次のように報告されます。 First Input Delay は、Google が Core Web Vitals として特定した 3 つのメトリクスのうちの 1 つです。FID値が100msまでは、"「良い」、" 100～300msは、"「改善が必要」、" 300ms以上は、"「悪い」とされています。" より詳細な説明については、「 リリースノート。 |
| Cumulative Layout Shift (CLS) は、 エージェント v1177 以上で利用可能です 。CLSは、 視覚的安定性 を測定するための重要なユーザー中心の指標です。なぜなら、ユーザーが予期せぬレイアウトシフトを経験する頻度を定量化するのに役立つからです。CLSが低いと、ページが 喜ばしい であることを保証するのに役立ちます。これは、Google が Core Web Vitals として特定した 3 つのメトリクスのうちの 1 つです。 Cumulative Layout Shift は、Google が Core Web Vitals として特定した 3 つのメトリクスの 1 つです。CLSのスコアが0.1までは、"「良好」、" 0.1～0.25は、"「改善が必要」、" 0.25以上は、"「不良」とみなされます。" |
| 次のペイント (INP) への相互作用は、 エージェント v1227 以降で使用できます。 INP は、 実行時の応答性 とユーザーが知覚するパフォーマンスを測定するための新しいメトリックです。 ユーザーの操作とページの応答または再描画の間の最大の待機時間を測定します。これは実験的なものですが、 Web Vitals v3 で追加された重要な指標として識別されます。 200 ミリ秒までの INP スコアは「良好」と見なされ、200 ～ 500 ミリ秒の間は「改善が必要」と見なされ、500 ミリ秒を超えると「不良」と見なされます。 |
|
|
| これは、指定されている場合、 |
| これは、 |
| エージェント v1227から、長いタスクのレポートが利用可能になりました。 このイベントは、メイン UI スレッドを 50 ミリ秒以上ブロックするタスクを報告する実験的な PerformanceLongTaskTiming APIによって観測されたエントリごとに表されます。 注: このイベントは実験的な機能として利用できますが、そのデータは自動的に収集されません。 ユーザー入力や対話の処理の遅延を防ぐために、これらのタスク を分割して最適化する ことをお勧めします。 長いタスクは、 |
| エージェント v1177 以降で使用可能な また、累積レイアウト シフト (CLS) スコア属性を |
|
また、累積レイアウト シフト (CLS) スコア属性を |
| エージェント v1163 以降で使用可能な また、累積レイアウト シフト (CLS) スコア属性を |
互換性と要件
要件：
- Meets installation requirements.
- このイベントの報告には 、ブラウザ エージェント バージョン 1153 以降が必要です。
ブラウザエージェントのリリースノート をフォローすると、新しいメトリクスがリリースされたときに知ることができます。
これらのメトリックは、次のブラウザー バージョンでサポートされています。サポートされていないブラウザの場合、 PageViewTimingイベントは記録されません。
指標 | 対応するブラウザのバージョン |
|---|---|
|
|
|
|
|
|
| これらの指標には
|
|
|
|
|
| このイベントは現在、14.1 (デスクトップ) または 14.5 (iOS) 未満の Safari を除く、ほとんどの最新のブラウザー バージョンでサポートされています。MDN ドキュメントによる互換性マトリックス。 |
| このイベントは現在、デスクトップとモバイルのすべてのブラウザーでサポートされています。MDN ドキュメントによる互換性マトリックス。 |
| このイベントは現在、デスクトップとモバイルのすべてのブラウザーでサポートされています。MDN ドキュメントによる互換性マトリックス。 |
累積レイアウトリフト
CLS（Cumulative Layout Shift）とは、ウェブページ上のコンテンツの安定性を測る指標です。詳しい説明は、 web.dev/cls をご覧ください。
CLSはどのようにしてNew Relicに取り込まれるのか
Layout Instability APIによって報告されるページ レイアウトの変化は、ページの有効期間全体にわたって集計され、すべてのPageViewTimingイベントの属性として報告され、そのイベントが発生したときの CLS 値を表します。
このモデルを使うと、ユーザーはページのさまざまな時点でのCLS値を見ることができます。たとえば、ユーザーが初めてページに触れるまでのCLS値や、ページを非表示にするまでのCLS値などです。
他のCLSソースとの近似性
Lighthouse は、ページが読み込まれるまでの CLS 値のみをキャプチャします。これは、開発環境またはラボ環境で役立ちます。windowLoad PageViewTimingイベントを調べることで、Lighthouse の値を概算できます。
CrUX レポートは、ページの存続期間にわたってキャプチャされた値を使用します。これは、RUM 環境での最悪のケースの変化を分析するのに役立ちます。windowUnload PageViewTimingイベントの CLS 属性を調べることで、CrUX 値を概算できます。これらの値は、サンプル セットが異なり、長期間有効な Web ページの値がどのように含まれているかが異なるため、まったく同じではありません。New Relic ブラウザー監視エージェントは、ページのアンロード時に CLS をキャプチャし、CrUX はページの存続期間全体にわたってメトリックを収集および更新します。
CLSの集計方法
2021年7月現在、GoogleはCLS値の集計方法を更新しています。ブラウザ監視エージェントのバージョンv12xxでは、 Evolving the CLS metric で説明されている方法を使用しています。
Browser Monitoring Agent v12xx以上。
レイアウトシフトの値はウィンドウに取り込まれます。最初のシフトと最後のシフトの間が5秒以内で、互いに1秒以内に発生したレイアウト・シフトは、同じウィンドウに含まれます。CLSスコアは、レイアウトシフト値の合計が最も大きいウィンドウのレイアウトシフト値の合計を表します。
Browser agent v12xxより前のバージョンです。
CLSスコアは、そのページの寿命までに発生したすべてのレイアウトの変化の合計を表します。
イベントデータの検索
ここでは、イベントデータに対するいくつかのサンプルクエリをご紹介します。