Web ページパフォーマンスとユーザーエクスペリエンス分析¶

Web RUM SDK は、実際のユーザーがページにアクセスした際の読み込み、レンダリング、インタラクション、レイアウト変更、エラー、リソース、ロングタスクのデータを、同一の view_id に関連付けます。アプリケーションデータが Guance に報告された後、まず Core Web Vitals で全体的なエクスペリエンスを判断し、次にページ、バージョン、ブラウザ、デバイス、ネットワークなどのディメンションで影響範囲を特定し、最後に view_id に沿ってエラー、リソース、ロングタスク、セッションリプレイをドリルダウンします。

このドキュメントのすべてのフィールド名は、Web RUM SDK が現在報告するデータ構造に基づいています。完全なフィールドリストについては、Web アプリケーションデータ収集 を参照してください。

分析前に統計の定義を明確にする¶

初回読み込みとルート遷移を区別する¶

view_loading_type は、2 種類の View を区別するために使用します。

• initial_load：ブラウザが初めて開く、またはページをリフレッシュする場合。
• route_change：シングルページアプリケーション（SPA）でルート遷移が発生する場合。

first_byte、first_input_delay、およびドキュメントナビゲーションタイミングフィールドは、initial_load View でのみ収集されます。loading_time、interaction_to_next_paint、cumulative_layout_shift、および View 関連のカウントは、initial_load と route_change の両方に適用されます。

RUM SDK 3.3.9 以降、SPA の場合、ネイティブ Soft Navigation API をサポートする Chrome では、route_change View で first_contentful_paint、largest_contentful_paint、largest_contentful_paint_element_selector を収集でき、view_navigation_type で push、replace、または traverse をマークします。ネイティブ API をサポートしないブラウザでも Route View は作成され、Navigation API、History API、または Hash ルートの互換性ロジックを通じて識別可能なナビゲーションタイプは保持されますが、そのルートには通常 FCP/LCP はありません。

したがって：

• ファーストビュー、ホワイトスクリーン候補、TTFB を分析する場合は、view_loading_type = "initial_load" でフィルターする必要があります。
• 初回読み込みの FCP/LCP を分析する場合は initial_load でフィルターします。SPA ルートの FCP/LCP を分析する場合は、route_change で、指標が存在し、ブラウザがネイティブ Soft Navigation API をサポートしているサンプルでフィルターします。
• SPA ルートのパフォーマンスを分析する場合は、loading_time、interaction_to_next_paint、cumulative_layout_shift、エラー、ロングタスクなどのフィールドも組み合わせて評価する必要があります。
• route_change で FCP または LCP が欠落しているレコードを、ゼロ値や異常として扱わないでください。

P75 を使用し、平均値だけを見ない¶

Core Web Vitals は、ページアクセスサンプルの第 75 パーセンタイル（P75）を使用して評価し、モバイルとデスクトップをそれぞれ観察することを推奨しています。P75 が目標を達成しているということは、少なくとも 75% のページアクセスが目標範囲内にあることを意味します。平均値は多数の高速サンプルによって希釈されやすく、低速ユーザーの実際のエクスペリエンスを代表しません。

以下の項目も同時に観察することをお勧めします。

• P50：典型的なユーザーエクスペリエンス。
• P75：Core Web Vitals の主要な判断基準。
• P90 または P95：低速ネットワーク、低性能デバイスなどのテールユーザーエクスペリエンス。
• 達成率：「良好」のしきい値内にある View の数が有効サンプル数に占める割合。
• サンプルサイズ：少数のサンプルに基づいてページやバージョンの品質を判断しないようにします。

指標の定義、しきい値、P75 の統計方法については、web.dev：Web Vitals および 実環境における Web Vitals 統計のベストプラクティス を参照してください。

単位に注意¶

• cumulative_layout_shift を除き、このドキュメントに記載されている時間指標は、データ内ではナノ秒（ns）で保存されます。
• 1s = 1,000,000,000ns、1ms = 1,000,000ns。
• cumulative_layout_shift は無単位のスコアであり、時間換算を行わないでください。
• DQL のしきい値は、元の保存単位を使用する必要があります。例えば、LCP 2.5 秒は 2500000000 と記述します。

コアエクスペリエンス指標¶

Core Web Vitals¶

LCP、INP、CLS のしきい値は、それぞれ LCP、INP、CLS を参照してください。

LCP：ユーザーが主要コンテンツをいつ表示するか¶

largest_contentful_paint は、ビューポート内の最大の画像、テキストブロック、またはビデオの描画が完了した時間を示します。SDK は同時に largest_contentful_paint_element_selector も報告し、LCP を生成したページ要素を特定するために使用します。

LCP が不良な場合、以下のフィールドを組み合わせて、どの部分で時間が消費されているかを判断します。

1. first_byte が高い場合：サーバー応答、リダイレクト、CDN、地域、ネットワークを優先的に確認します。
2. first_byte は正常だが first_contentful_paint が高い場合：レンダリングをブロックする CSS、JavaScript、クライアント側の初期化を優先的に確認します。
3. first_contentful_paint は正常だが largest_contentful_paint が高い場合：LCP 要素に対応するリソースの発見が遅すぎる、ダウンロードが遅すぎる、またはレンダリングが遅延していないかを優先的に確認します。
4. loading_time が LCP よりも明らかに高い場合：ページの主要コンテンツは既に表示されているが、ネットワークリクエストや DOM の変更が継続して発生している可能性があります。

INP：ページが操作にタイムリーに応答できるか¶

interaction_to_next_paint は、1 回のインタラクションにおける、入力、イベント処理から次のフレーム描画までの完全なレイテンシを測定します。SDK は View 内で継続的にインタラクションを監視し、最悪のインタラクションに近い値を報告し、同時に interaction_to_next_paint_target_selector で対応する要素を特定します。

INP が不良な場合、以下と重点的に関連付けます。

• view_long_task_count：メインスレッドを 50ms 以上ブロックするタスクがページに存在するか。
• view_error_count：インタラクション中にスクリプトエラーが発生したか。
• frustration_count：繰り返しクリック、無効なクリック、誤ったクリックなどのフラストレーション行動が発生したか。
• R::long_task の duration、blocking_duration、scripts：ブロック時間と関連スクリプトを特定します。

ユーザーインタラクションのない View には interaction_to_next_paint が存在しない可能性があります。INP を統計する際は、このフィールドが存在するサンプルのみを使用します。

CLS：ページコンテンツが予期せず移動していないか¶

cumulative_layout_shift は、ページ上の表示要素の予期しない移動を測定します。cumulative_layout_shift_target_selector は、最大の影響を与えた要素を指します。

CLS が不良な場合、よくある確認ポイントは次のとおりです。

• 画像、動画、広告、または iframe に幅と高さが予約されていない。
• 非同期コンテンツが既存のコンテンツの上に挿入されている。
• Web フォントの切り替えによりテキストサイズが変更されている。
• アニメーションがレイアウトをトリガーするプロパティを使用して実装されている。

初回読み込みの補助指標¶

FCP については、web.dev：FCP を参照してください。良好は 1.8 秒以内、不良は 3 秒を超える場合です。first_byte については、web.dev：First Byte Time を参照してください。0.8 秒以内が通常良好で、1.8 秒を超えると通常不良です。TTFB は Core Web Vitals ではなく、FCP および LCP と組み合わせて判断する必要があります。

ページ読み込みと使用エクスペリエンス指標¶

loading_time は視覚的な完了時間と同等ではありません。ページは LCP を先に完了できますが、バックグラウンドポーリング、API リクエスト、または継続的な DOM 更新により loading_time が長くなる可能性があります。逆に、loading_time が正常でも、ページの主要コンテンツが正しく表示されているとは限りません。

ページパフォーマンスのベースラインを確立する¶

ステップ 1：各ページの P75 を確認する¶

以下のクエリはダッシュボードチャート向けであり、DQL 内に [24h]、[1h] のような固定時間範囲を意図的に記述していません。時間範囲を省略すると、クエリはダッシュボード右上の時間ウィジェットに従います。DQL 内で時間範囲を直接指定すると、その優先順位がダッシュボードの時間ウィジェットよりも高くなり、チャートがその時間帯に固定されてクエリを実行します。詳細については、DQL 時間範囲指定 を参照してください。<APP_ID> をアプリケーション ID に置き換えてください。

ページごとに LCP P75 を確認する：

R::view:(percentile(largest_contentful_paint, 75) AS p75_lcp) {app_id = "<APP_ID>", view_loading_type = "initial_load", largest_contentful_paint = exists()} BY view_path_group SORDER BY p75_lcp DESC SLIMIT 20

ページごとに INP P75 を確認する：

R::view:(percentile(interaction_to_next_paint, 75) AS p75_inp) {app_id = "<APP_ID>", interaction_to_next_paint = exists()} BY view_path_group SORDER BY p75_inp DESC SLIMIT 20

ページごとに CLS P75 を確認する：

R::view:(percentile(cumulative_layout_shift, 75) AS p75_cls) {app_id = "<APP_ID>", cumulative_layout_shift = exists()} BY view_path_group SORDER BY p75_cls DESC SLIMIT 20

3 つの指標を直接合計してスコアにしないでください。LCP、INP、CLS はそれぞれ読み込み、応答性、安定性を表しており、いずれかが不良であれば個別に特定する必要があります。

ステップ 2：達成率を観察する¶

以下のクエリは、LCP が 2.5 秒を超えない有効な View の割合を計算します。

eval(100 * A / B, alias='LCP_good_rate', A="R::view:(count(view_id)) {app_id = '<APP_ID>', view_loading_type = 'initial_load', largest_contentful_paint <= 2500000000}", B="R::view:(count(view_id)) {app_id = '<APP_ID>', view_loading_type = 'initial_load', largest_contentful_paint = exists()}")

同様に、条件を以下のように置き換えることができます。

• INP 達成：interaction_to_next_paint <= 200000000
• CLS 達成：cumulative_layout_shift <= 0.1
• FCP 達成：first_contentful_paint <= 1800000000

分母は、指標が存在する有効なサンプルのみをカウントする必要があります。そうしないと、この指標をサポートしないブラウザ、インタラクションのない View、または早期に離脱した View によって結果が歪められます。

ステップ 3：主要なディメンションで分割する¶

以下の SDK フィールドを順にグループ化またはフィルターに使用することをお勧めします。

1. view_path_group：最初に影響を受けるページを特定します。
2. version：新しいバージョンによるリグレッションかどうかを判断します。
3. browser、browser_version_major：ブラウザの互換性や機能の違いを判断します。
4. device、screen_size：デバイスのパフォーマンスとレイアウトの違いを区別します。
5. network_type：Wi-Fi、セルラーネットワーク、到達不能なネットワークを区別します。
6. env、service：異なる環境やサービスのデータが混在しないようにします。

例えば、バージョンとページごとに Core Web Vitals を比較する：

R::view:(percentile(largest_contentful_paint, 75) AS p75_lcp, percentile(interaction_to_next_paint, 75) AS p75_inp, percentile(cumulative_layout_shift, 75) AS p75_cls) {app_id = "<APP_ID>"} BY version, view_path_group SORDER BY p75_lcp DESC SLIMIT 50

LCP は initial_load とネイティブ Soft Navigation API をサポートする route_change で条件が異なり、INP はインタラクションがないために欠落する可能性があるため、本番ダッシュボードでは、3 つの指標に対してそれぞれチャートを作成し、初回読み込みと SPA ルートの LCP を分けて統計し、同じページ、バージョン、デバイスのフィルター条件を使用して連携分析することをお勧めします。

ホワイトスクリーンと長時間コンテンツなしの分析¶

ホワイトスクリーンは SDK の直接的な指標ではない¶

現在の SDK は、white_screen という名前のフィールドを報告しません。ホワイトスクリーンは、収集された指標から候補セットを構築し、エラー、リソース、ロングタスク、セッションリプレイと組み合わせて確認する必要があります。

候補を 2 つのレベルに分けることをお勧めします。

1. 低速 FCP 候補：first_contentful_paint > 3000000000。ユーザーが最初のコンテンツを見るまでに 3 秒以上かかったことを示し、比較的安定した、統計可能なホワイトスクリーンエクスペリエンスの近似値です。
2. FCP 欠落候補：終了した初回読み込み View で、滞在時間が 3 秒を超えているが、first_contentful_paint が存在しない。このルールは調査目的でのみ使用でき、直接ホワイトスクリーンと同一視することはできません。

FCP の欠落は、以下の状況によっても発生する可能性があります。

• 現在のブラウザが SDK が使用する FCP 収集機能をサポートしていない。
• ページが FCP を生成する前にバックグラウンドに移動されるか、非表示になる。
• ユーザーがページを早期に閉じる。
• データサンプリング、ネットワークレポート、またはページライフサイクルの早期終了。
• route_change を誤って初回読み込みのホワイトスクリーン分析に含めている。

したがって、FCP 欠落ルールは view_loading_type = "initial_load" でフィルターし、browser ごとに収集カバレッジを検証する必要があります。ブラウザの機能の限界については、Browser Support を参照してください。

低速 FCP 候補の割合を統計する¶

eval(100 * A / B, alias='white_screen_candidate_rate', A="R::view:(count(view_id)) {app_id = '<APP_ID>', view_loading_type = 'initial_load', first_contentful_paint > 3000000000}", B="R::view:(count(view_id)) {app_id = '<APP_ID>', view_loading_type = 'initial_load', first_contentful_paint = exists()}")

この割合は、「有効な FCP サンプルのうち、コンテンツを表示するまでに 3 秒以上かかったもの」の割合を示し、視覚的に確認された実際のホワイトスクリーン率を表すものではありません。さらに view_path_group、version、browser、network_type で分割することをお勧めします。

低速 FCP View を特定する¶

R::view:(view_id, session_id, view_url, first_contentful_paint, first_byte, loading_time, view_error_count, view_resource_count, view_long_task_count, session_has_replay) {app_id = "<APP_ID>", view_loading_type = "initial_load", first_contentful_paint > 3000000000} ORDER BY first_contentful_paint DESC LIMIT 100

結果の解釈：

• first_byte も非常に高い場合：サーバー、CDN、ネットワーク、リダイレクトを優先的に確認します。
• first_byte は正常だが FCP が非常に高い場合：レンダリングをブロックするリソース、クライアントサイドレンダリング、同期 JavaScript を優先的に確認します。
• view_error_count > 0 の場合：エラースタックを優先的に確認し、初期化が中断されたかどうかを確認します。
• view_long_task_count > 0 の場合：最初の描画前にメインスレッドがロングタスクによってブロックされていないか確認します。
• session_has_replay = true の場合：session_id または view_id を使用してセッションリプレイを開き、ユーザーが実際に表示した画面を確認します。

FCP 欠落候補を特定する¶

R::view:(view_id, session_id, view_url, time_spent, view_error_count, view_resource_count, view_long_task_count, session_has_replay) {app_id = "<APP_ID>", view_loading_type = "initial_load", is_active = false, time_spent > 3000000000, first_contentful_paint != exists()} ORDER BY time_spent DESC LIMIT 100

この結果は、まず browser ごとに FCP をサポートしないサンプルを除外し、次にセッションリプレイとドリルダウンクエリを組み合わせて確認する必要があります。FCP の欠落のみに基づいて「実際のホワイトスクリーン率」のアラートを作成しないでください。

view_id に沿って根本原因をドリルダウンする¶

候補結果の <VIEW_ID> を以下のクエリに代入します。

スクリプトおよびランタイムエラーを確認する：

R::error:(error_type, error_source, error_message, error_stack) {app_id = "<APP_ID>", view_id = "<VIEW_ID>"} ORDER BY time ASC LIMIT 100

失敗または低速なリソースを確認する：

R::resource:(resource_url, resource_type, resource_status, duration, resource_ttfb, resource_trans) {app_id = "<APP_ID>", view_id = "<VIEW_ID>", resource_status >= 400} ORDER BY duration DESC LIMIT 100

HTTP エラーがない場合でも、リソースが遅すぎる疑いがある場合は、resource_status >= 400 を削除し、duration で最も遅いリソースを確認できます。resource_ttfb が高い場合は通常サーバーまたはネットワークの待機時間を示し、resource_trans が高い場合は通常コンテンツ転送時間を示します。

ロングタスクを確認する：

R::long_task:(duration, blocking_duration, scripts) {app_id = "<APP_ID>", view_id = "<VIEW_ID>"} ORDER BY duration DESC LIMIT 100

duration はロングタスクの総時間を示し、blocking_duration はそのうちユーザー入力をブロックした時間を示し、scripts は関連スクリプトの特定に使用できます。

一般的なエクスペリエンス問題の判断パス¶

ダッシュボードとアラートの推奨事項¶

少なくとも以下のビューを作成することをお勧めします。

1. LCP、INP、CLS の P75 トレンドと達成率。
2. FCP、first_byte、loading_time の P75 トレンド。
3. view_path_group でソートされた低速ページ Top 20。
4. version で比較したリリース前後のトレンド。
5. browser、device、network_type、地域で分割したテールエクスペリエンス。
6. view_error_count、view_long_task_count、frustration_count とパフォーマンス指標の関連グラフ。
7. 低速 FCP 候補の割合とリプレイ可能なサンプルリスト。

アラートは、P75 または達成率を優先的に使用し、最小サンプルサイズと連続トリガー条件を設定して、少数の異常サンプルや短時間のトラフィック変動による誤報を回避する必要があります。Core Web Vitals の「不良」しきい値から開始し、ビジネスページの重要度、履歴ベースライン、実際のトラフィックに基づいて調整することをお勧めします。

コンソールで分析を完了する¶

• 「リアルユーザーモニタリング（RUM） > 分析ダッシュボード > Web 端末」で、概要、ページパフォーマンス、リソース、エラー分析を表示します。
• 「リアルユーザーモニタリング（RUM） > エクスプローラー」で、view_id、session_id、ページ、バージョン、ブラウザで元の View をフィルターします。
• 個々の View に入った後、Resource、Error、Long Task、Action、セッションリプレイを関連付けて表示します。
• カスタム統計が必要な場合は、このドキュメントの DQL を使用してダッシュボードチャートまたはリアルユーザーモニタリング（RUM）指標検出を作成します。

コンソールの詳細な機能については、分析ダッシュボード、エクスプローラー、リアルユーザーモニタリング（RUM）指標検出 を参照してください。