New Relicがページロードタイミングを測定する方法

このドキュメントは、以下について説明します。

Webページの読み込みの仕組み
Browserモニタリングが、リアルユーザーモニター（RUM）とも呼ばれるページロードタイミングを測定する仕組み

ヒント

これは、従来の同期型ページロードタイミングを解説したものです。Browserは、非同期型のページロードタイミングもモニターできます。

ページ読み込みのプロセス

以下に示すのは、大半のウェブページ読み込みにおける主要なステップになります。図表の1～6の数は、その下に続くステップと一致しています。

ページロードタイムライン：ウェブページのロードに含まれるステップ。Browserモニタリングチャートには、このプロセスの次のセグメントが表示されます。ネットワーク、ウェブアプリケーション、DOM処理、ページレンダリング。

ページ読み込みは、ユーザーがハイパーリンクを選択、フォームを提出、またはブラウザへURLを入力すると開始します。これは、初期リクエストまたはナビゲーション開始とも言われます。ユーザーのアクションは、ネットワークをまたいで、Webアプリケーションサーバーにリクエストを送信します。
リクエストはアプリケーションに到達して処理されます。（リクエストの処理が開始されるまで、多少の時間がかかる場合があります。この原因として、リクエストキューイングまたはその他の要因が考えられます。）
アプリケーションが処理を終え、ネットワークをまたいでユーザーのブラウザにHTMLレスポンスを返信します。これは、レスポンススタートまたは最初の1バイトと言われる場合もあります。
（最初のバイトまでの時間）ユーザーのブラウザがHTMLレスポンスの受信を開始し、ドキュメントオブジェクトモデル、またはDOMの処理を開始します。
DOMの読み込みが終了します。この時点をDOMレディと呼びます。DOMを使用して、ユーザーのブラウザがページレンダリングを開始します。
ユーザーのブラウザでページレンダリングが終了し、ウィンドウの読み込みイベントが起動されます。（非同期読み込みを使用するページでは、一部の要素がウィンドウの読み込みイベント後も読み込まれ続ける可能性があります。）

Browserモニタリングにおけるページロードタイムのチャート

Browserモニタリングは、ブラウザ概要ページとページ表示ページで主要なページロードタイミングのセグメントをキャプチャーします。SPAモニタリングを有効にしている場合は、このチャートとSPA特有のチャートの双方にアクセスできます。チャートでは、以下の内容が表示されます。

ネットワーク
Webアプリケーション時間
DOM処理
ページレンダリング
リクエストキューイングなど、その他の該当するセグメント

チャートの色は、ページロードタイミング図表の色と一致します。

one.newrelic.com > All capabilities > Browser >（アプリを選択）> Summary：読み込み時間チャートがSummaryとPage viewsページに表示されます。

ブラウザがこれらの時間を収集する方法は、ブラウザがNavigation Timing Specification APIを使用できるかどうかによって異なります。カスタムページロードタイミングのイベントは、BrowserエージェントAPIで追加できます。

以下に示すのは、ブラウザ読み込み時間のチャートセグメントに含まれるアクティビティの詳細です。

ネットワーク層には、リダイレクトならびにHTMLのリクエストと受け取りにかかった時間が含まれます。サーバー上あるいは統計的アセットに費やした時間は含まれません。

ネットワークの時間測定は、リンクを初めてクリックした時から始まります。ネットワーク時間には、DNSのほか、ご利用サイトでリダイレクトがある場合は複数のルックアップ、TCP（リクエストキュー時間監視を設定済みでない限りファイアウォールを含む）、SSL接続時間が含まれます。

リクエストキューイング監視を設定した場合、ネットワーク時間にはXリクエストヘッダ後に発生するいずれのリクエストキュー時間も含まれません。
リクエストキューイング監視を設定していない場合、ネットワーク時間にはXリクエストヘッダ後に発生するすべてのリクエストキュー時間が含まれます。
Navigation Timing Specification APIは、ネットワーク時間の詳細な内訳を提供します。（古いブラウザの場合、タイマーは「unloadイベント前」に始まります。）
コピー/ペースト手法でデプロイしたアプリケーションの場合、Browserではネットワーク時間のウェブアプリケーションとキュー時間が含まれます。これは、ブラウザが自動インジェクションを通じてBrowserエージェントにアプリケーション値を渡すにあたって、サーバーサイドのエージェントに依存していることが原因です。
このバックエンドの時間をブラウザの観点から見て分析した詳細に関しては、セッショントレースページを参照してください。セッショントレースは、入手可能なすべてのネットワーク関連イベントについてレポートするため、ブラウザがDNSルックアップやその他のネットワークイベントにどのように時間を費やしているのか、ケース毎に確認できます。
重要
リクエストキューイングを設定した場合でも、フロントエンドサーバーの設定がネットワーク時間に影響します。これは、フロントエンドサーバーが実際にリクエストを受け入れて処理するまで、キューイング時間ヘッダは追加されないことが原因です。フロントエンドサーバーの何かしらの設定によって、リクエストがバックログに保留され始め、フロントエンドサーバーが接続を受け入れる際に使用するリスナーソケットに列を作るようになった場合、Browserモニタリングにおけるネットワーク時間が増えることになります。キューイング時間ヘッダは、絶対にこのリスナーソケットのバックログを説明することはできません。

DOM処理は、HTMLをDOMにパースして、同期スクリプトを検索または実行するまでにかかる時間です。この段階でブラウザが画像ダウンロードを開始した場合、ページ読み込みタイミングは画像の読み込み時間をキャプチャーします。

DOM処理とページレンダリング層には、統計的アセットのネットワーク時間も含まれます（ページ読み込み後に明確に検索されていないアセット）。ただし、ページのスクリプトがサーバーまたはコンテンツデリバリーシステム（CDS）の終了後に動的に画像タグを挿入して、画像を読み込んだ場合、ページロードタイミングは画像読み込み時間をキャプチャーできません。

リクエストキューイングは、そのアカウントがBrowserモニタリングとAPMをリンクしている場合に読み込み時間チャートに表示されます。New Relicでは、リクエストキューイングはリクエストが本番環境システムに入ってから、アプリケーションに到達するまでの時間を指します。本番環境インフラの特性次第で、この時間はリクエストが入力する実際のキューを含むか、時間のかかるその他の関数を表す場合があります（負荷バランシングや内部ネットワークレイテンシーなど）。

アプリケーションサーバーリクエストvsブラウザトランザクション

アプリケーションサーバートランザクションの数（1分あたりのリクエストまたはrpm）は、同一のアプリケーションのブラウザトランザクションの数（1分あたりのページまたはppm）よりも大きいことがよくあります。詳細は、トラブルシューティングの手順を参照してください。

外れ値

ご利用のアプリケーションがどれだけ優れたパフォーマンスを示しているとしても、必ず一部の遅いブラウザ、プラットフォーム、そしてネットワークによって総合的な集計レスポンスタイムの表示は遅れます。外れ値による非対称を最小限に留めるため、ページロードタイミングはアプリケーションのブラウザApdex T設定の4.5倍以上のエンドユーザーレスポンスタイムを固定して、Apdex Tの4.5倍または13.5秒のうちどちらか大きい方に縮小します。（ヒストグラムの外れ値は95%でカットオフされます。）

たとえば、ご利用のアプリケーションのエンドユーザーApdex T閾値が8秒の場合、これらのレスポンスタイムは36秒で固定されます。これによって、これらのレスポンスタイムがアプリケーション全体に及ぼす影響を最小限に留めながらも、「挫折した」Apdexスコアを考慮できます。

SPAモニタリングでは、外れ値の扱いが異なります。初期ページ読み込みまたはルート変更の時間が30分に達すると、このイベントは無効データとして扱われ、破棄されます。

次のステップ

以下のドキュメントで、ページロードタイミングに関する詳細をご覧ください。

まだ作成されていない場合は、無料のNew Relicアカウントを以下で作成し、今すぐデータの監視を開始してください。