ブラウザ モニタリングのPageViewTimingイベントは、各データ ポイントが利用可能になるとすぐに個別のイベントとして送信します。タイミングを制限していないため、発火のタイミングに関係なく、最初のペイントまたは最初のインタラクション データを受け取ることができます。このドキュメントでは、 PageViewTimingとその属性を使用してサイト、コンポーネントの読み込み、およびユーザー パフォーマンス メトリックに関するデータを照会する理由と方法について、ビジュアルと応答性の両方の観点から説明します。
PageViewTimingを使う理由は？
非同期ページや動的ページを使用しているアプリケーションでは、サイトやコンポーネントの読み込みに関する追加情報が必要な場合があります。しかし、ページは様々な方法でコンテンツをロードすることができ、ユーザーはいつそのコンテンツとインタラクトするかをコントロールすることができます。このような理由から、ユーザー中心のパフォーマンス指標は、ブラウザエージェントの標準的なウィンドウのオンロード（ページロード時間）の外側で行われます。
例えば、ユーザーはせっかちになり、コンテンツがウェブページに表示されるとすぐにクリックし始めるかもしれません。あるいは、コンテンツが読み込まれてからしばらくしてからページの利用を始めるかもしれません。
PageViewTimingイベントは、他のイベントに依存しない、よりリアルタイムの配信メカニズムを提供します。追加のメトリックは、視覚的および応答性の両方の観点から、ユーザーがサイトをどのように体験するかを理解するのに役立ちます。
Googleのコアウェブバイタルのサポート
ブラウザ監視のエージェント バージョン 1177では、コアウェブバイタルを完全にサポートしています。 この機能は、エージェントのすべてのバージョン (Lite、Pro、または Pro+SPA) で利用できます。
コアウェブバイタルを構成するメトリクスは時間の経過とともに進化することに注意してください。 現在のセットは、ユーザー エクスペリエンスの 3 つの側面、つまり読み込み、対話性、視覚的な安定性に焦点を当てています。 これには、次のメトリクスとそれぞれの閾値が含まれます。
Largest contentful paint (LCP)
: 読み込みパフォーマンスを測定します。 良好なユーザー エクスペリエンスを提供するには、ページの最初の読み込み開始時に LCP が
within 2.5 seconds
発生する必要があります。
Interaction to next paint (INP)
：全ユーザーインタラクションのレイテンシをページごとに計測します。 優れたユーザー エクスペリエンスを提供するには、ページの INP が
less than 200 milliseconds
である必要があります。
: 視覚的な安定性を測定します。 優れたユーザー エクスペリエンスを提供するには、ページは
less than 0.1
の CLS を維持する必要があります。
これらの各メトリクスについて、ほとんどのユーザーに対して推奨ターゲットに達していることを確認するには、モバイル デバイスとデスクトップ デバイス間でセグメント化されたページ読み込みの75th percentileを測定するのが適切な閾値です。
もっと詳しく知りたい方は、 Nerd Days talk on perceived performanceをご覧ください。
ビジュアル、インタラクティブ性、応答性の詳細な評価指標
BrowserInteractionイベントとPageViewイベントは、ページ ウィンドウの読み込み(またはウィンドウの読み込みと AJAX) のタイミングを受け取ると、レポートを終了します。ただし、ペイントとインタラクティブ メトリックはいつでも発生する可能性があります。PageViewTimingは、これらの指標を個別のイベントとして次の目的に配信します。
- このタイミングのばらつきを考慮する。
- 任意のタイムアウトを設定することは避けてください。
BrowserInteractionおよびPageViewイベントを無期限に保持しないようにします。
追加データ | コメントコメント |
|---|---|
|
|
|
Google の調査によると、最大の要素がレンダリングされたタイミングを見ることが、ページのメインコンテンツが読み込まれて有用になったタイミングを測定するより正確な方法であることがわかりました。この指標についての制限や考慮点などの詳細は、 w3c draft をご覧ください。 また、LCP を使用した累積レイアウト シフト スコア属性も報告します。 この属性は 最大のコンテンツ ペイントは、Google がコア ウェブ バイタルとして識別する 3 つのメトリックのうちの 1 つです。 2.5 秒までの LCP 値は「良好」とみなされ、2.5 ～ 4 秒の間は「改善が必要」とみなされ、4 秒を超えると「不良」とみなされます。 |
|
また、ユーザーの最初のインタラクションの時点での累積レイアウト シフト (CLS) スコア属性も報告します。この属性は次のように報告されます。 INP は、Google によってコアウェブバイタルとして特定された 3 つのメトリクスのうちの 1 つです。 200 ミリ秒以下の INP スコアは「良好」とみなされ、200 ～ 500 ミリ秒の場合は「改善が必要」とみなされ、500 ミリ秒を超えると「不良」とみなされます。 |
| 累積レイアウト シフト (CLS) は、 エージェント v1177 以降で使用できます。 CLS は、ユーザー エクスペリエンスが予想外にレイアウトを変更する頻度を定量化するのに役立つため、視覚的な安定性を測定するためのユーザー中心の重要なメトリクスです。 CLS が低いと、ページが魅力的であることが保証されます。 累積レイアウトシフトは、Google がコアウェブバイタルとして特定した 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) は、Web ページ上のコンテンツの安定性を測定するメトリクスです。 詳しい説明については、 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 or higher:
レイアウトシフトの値はウィンドウに取り込まれます。最初のシフトと最後のシフトの間が5秒以内で、互いに1秒以内に発生したレイアウト・シフトは、同じウィンドウに含まれます。CLSスコアは、レイアウトシフト値の合計が最も大きいウィンドウのレイアウトシフト値の合計を表します。
Prior to Browser agent v12xx:
CLSスコアは、そのページの寿命までに発生したすべてのレイアウトの変化の合計を表します。
イベントデータの検索
ここでは、イベントデータに対するいくつかのサンプルクエリをご紹介します。