ページパフォーマンス¶
ユーザーエクスペリエンスを継続的に最適化することは、あらゆるWebサイトが長期的に成功するための鍵です。起業家、マーケター、デベロッパーを問わず、Web指標はサイトのエクスペリエンス指数を定量化し、改善の機会を発見するのに役立ちます。
Google の Core Web Vitals¶
Web Vitals は、優れたWebユーザーエクスペリエンスの提供に不可欠な品質シグナルについて、統一されたガイダンスを提供することを目的としてGoogleが開始した新たな取り組みです。
Core Web Vitals を構成する指標は、時間の経過とともに変化します。現在の2020年を対象とした指標構成は、ユーザーエクスペリエンスの3つの側面(読み込みパフォーマンス、インタラクティブ性、視覚的安定性)に焦点を当てており、以下の指標とそれぞれの目標しきい値が含まれます。
Largest Contentful Paint (LCP):最大コンテンツ描画。読み込みパフォーマンスを測定します。良好なユーザーエクスペリエンスを提供するには、LCP がページの読み込み開始から 2.5 秒以内に発生する必要があります。
First Input Delay (FID) :初回入力遅延。インタラクティブ性を測定します。良好なユーザーエクスペリエンスを提供するには、ページの FID が 100 ミリ秒以下である必要があります。
Cumulative Layout Shift (CLS):累積レイアウトシフト。視覚的安定性を測定します。良好なユーザーエクスペリエンスを提供するには、ページの CLS を 0.1 以下に保つ必要があります。
ほとんどのユーザーのアクセス中に推奨される目標値を達成していることを確認するには、上記の各指標について、ページ読み込みの75パーセンタイルを適切な測定しきい値とします。このしきい値はモバイルとデスクトップの両方に適用されます。
ページ収集指標¶
| 指標 | 型(単位) | 説明 |
|---|---|---|
view.time_spent |
number(ns) | ページ滞在時間 |
view.loading_time |
number(ns) | ページが ready 状態になり、ネットワークリクエストや DOM の変更がない状態。 > 詳細は ページ Loading Time を参照。 |
view.largest_contentful_paint |
number(ns) | 最大コンテンツ描画。読み込みパフォーマンスを測定します。良好なユーザーエクスペリエンスを提供するには、LCP がページの読み込み開始から 2.5 秒以内に発生する必要があります。 |
view.first_input_delay |
number(ns) | 初回入力遅延。インタラクティブ性を測定します。良好なユーザーエクスペリエンスを提供するには、ページの FID が 100 ミリ秒以下である必要があります。 |
view.cumulative_layout_shift |
number(ns) | 累積レイアウトシフト。視覚的安定性を測定します。良好なユーザーエクスペリエンスを提供するには、ページの CLS を 0.1 以下に保つ必要があります。 |
view.first_contentful_paint |
number(ns) | 初回コンテンツ描画 (FCP) 指標は、ページの読み込み開始からページコンテンツの一部が画面にレンダリングされるまでの時間を測定します。この指標における「コンテンツ」とは、テキスト、画像(背景画像を含む)、<svg> 要素、または白以外の <canvas> 要素を指します。> 詳細は w3c を参照。 |
view.first_byte |
number(ns) | ページリクエストから最初のバイトが応答されるまでの時間 |
view.time_to_interactive |
number(ns) | ページの読み込み開始から、主要なサブリソースのレンダリングが完了し、ユーザー入力に迅速かつ確実に応答できるようになるまでの時間 |
view.dom_interactive |
number(ns) | パーサーがドキュメントの解析を完了した時間。詳細は MDN を参照。 |
view.dom_content_loaded |
number(ns) | 純粋な HTML が完全に読み込まれ解析された時点で DOMContentLoaded イベントが発生します。スタイルシート、画像、サブフレームの読み込み完了を待つ必要はありません。詳細は MDN を参照。 |
view.dom_complete |
number(ns) | ページとすべてのサブリソースの準備が完了した状態。ユーザーにとっては、読み込み中のアニメーションが停止した状態です。詳細は MDN を参照。 |
view.load_event |
number(ns) | ページ全体と、スタイルシートや画像などの依存リソースがすべて読み込み完了したときに発生します。DOMContentLoaded とは異なり、依存リソースの読み込みを待たずにページ DOM の読み込み完了時に発生します。詳細は MDN を参照。 |
シングルページアプリケーション(SPA)について¶
シングルページアプリケーション(SPA)の場合、RUM ブラウザ SDK は loading_type タグを使用して initial_load と route_change を区別します。RUM SDK は、loading_type:route_change タグが付いた view イベントを生成します。RUM は History API を使用して URL の変更を監視します。
Loading Time の計算方法¶
モダンブラウザが提供する強力な API 機能に基づき、Loading Time はページの DOM 変更とネットワークリクエストの状況を監視します。
-
Initial Load:Loading Time は以下のうち、長い方の時間を取ります。
- loadEventEnd - navigationStart
- ページで最初にアクティビティがなくなった時刻 - navigationStart
-
SPA Route Change: ページで最初にアクティビティがなくなった時刻 - URL が変更された時刻
ページのアクティブ状態¶
以下のいずれかの条件を満たす場合、ページはアクティブ状態と判断されます。
- ページの DOM に変更があった場合
- 静的リソースの読み込みがあった場合(js、cssなどの読み込み)
- 非同期リクエストがあった場合
注意
ページが 100ms 以内にイベントを生成しなかった場合、そのページはアクティブではないと判断されます。
注意
以下の場合、直前のリクエストや DOM 変更から 100ms という基準ではアクティビティを正確に判断できない可能性があります。
- アプリケーションが定期的に、またはクリックのたびに API にリクエストを送信して分析データを収集している場合。
- アプリケーションが「comet」技術(ストリーミングまたはロングポーリング)を使用しており、リクエストが無期限に保持される場合。
このような状況でアクティビティ判断の精度を向上させるには、excludedActivityUrls 設定を指定してこれらのリクエストを除外できます。
