ブラウザ拡張機能の指標

ウェブページの読み込みプロセスは、主に以下のステップに分けられます。

1. ブラウザは、ネットワークリクエストを実行する前に、ローカルでリクエストを処理し、例えばローカルにキャッシュされたデータを確認します。
2. リソースがローカルに存在しない場合は、ネットワーク経由で要求されます。
3. サーバーはリクエストを受信し、処理します。
4. ページ構造を構築するために必要なデータは、ネットワークを介してサーバーからブラウザに転送されます。
5. ページを表示するために必要な追加リソースが取得され、最終的にユーザーのブラウザにページが表示されます。

続いて、上記で述べた各項目について、より詳細に説明していきます。まず、ページ、ヒット数、プロトコル、リソースといった一般的な構成要素を定義します。

ページURL

ページURLとは、HTMLファイルの解析をトリガーし、その解析結果がクライアントのブラウザ上でレンダリングされるURLのことです。

W3CタイムナビゲーションAPIの観点から言えば、ブラウザがページを要求すると、新しいナビゲーション計算がトリガーされます。

API呼び出しURL

API呼び出しURLとは、ブラウザに代わってターゲットサーバーへのAPI呼び出しをトリガーするURLのことです。これは、ターゲットサーバーから受信するデータ／コンテンツの種類に基づいて、ページURLとは異なります。通常、API呼び出しURLはXMLまたはJSON形式でデータを返しますが、ページURLはCSS、JavaScript、画像などのウェブリソースを返します。

ページの読み込みとリクエスト

ブラウザがウェブページおよび関連するウェブリソース（JavaScript、画像、スタイルシートなど）を要求すると、これらのリソースが存在するさまざまなサーバーにHTTPリクエストを送信します。ウェブ上のリソースへの呼び出しは、行われたウェブ要求の種類（ウェブ上のリソースまたはAPI呼び出し）に応じて、「ページロード」または「リクエスト」と呼ばれます。

Netskope DEM プラットフォームは、次の 3 種類のページ読み込みを区別します。

• 「ナビゲーション」ページの読み込みは、最初のウェブページリクエストをトリガーするものです。
• 「リソース」ページの読み込みは、「ナビゲーション」ページの読み込み自体を除き、すべての種類のリソースに対するクエリをトリガーします。
• 「リクエスト」ページの読み込みは、「リソース」ページの読み込みカテゴリのサブパートです。これには、xmlhttprequest、fetch、beacon というイニシエータタイプによって開始されたリクエストのみが含まれます。この種のヒットは、「シングルページアプリケーション」の文脈において非常に重要です。

MIMEタイプ

MIMEはMultipurpose Internet Mail Extensionsの略です。「MIMEタイプ」は、実際に読み込まれるリソースの種類を識別するものです。上記の例に関して言えば、ファイル style.css が読み込まれるため、MIME タイプは「css」となります。

この情報はブラウザによって提供されるものではありません。Netskopeは、ファイル名を対応するMIMEタイプにマッピングするための独自のヒューリスティックを構築しました。

処理時間

ウェブページの読み込みプロセスは、主に以下のステップに分けられます。

1. ブラウザは、ネットワークリクエストを実行する前に、ローカルでリクエストを処理し、たとえばローカルにキャッシュされたデータを確認します。
2. リソースがローカルに利用できない場合は、ネットワーク上で要求されます。
3. サーバーはリクエストを受信して処理します
4. 要求されたデータは、ネットワークを介してサーバーからブラウザに転送されます。
5. ウェブページはユーザーのブラウザ上でレンダリングされています

このプロセス全体が完了するまでにかかる時間は、読み込み時間という指標に相当します。ナビゲーションタイミングにはウェブページ構造が準備完了するまでのすべてのステップが含まれ、リソースタイミングにはページを構成するすべてのリソースの取得が含まれているため、“Loading Time = Navigation + Resources”。

W3Cの時間ナビゲーションAPIの観点から、リソース時間はブラウザがHTMLファイル全体を解析しDOM(domContentLoadedEventStart)を完成させてから、ウェブページ全体がユーザーの画面上で完全にレンダリングされるまでの時間(domComplete)として定義されます。

domContentLoadedEventStartポイントに到達すると、DOM の準備が整います。しかし、これは次のステップが単に画面上のすべての要素をレンダリング／描画することだけを意味するわけではありません。一部のリソース（画像、非同期JavaScript、動画など）は、リクエストして読み込む必要がある場合があります。追加リソースの要求と取得という一連のプロセスは、このリソースフェーズに含まれます。

つまり、リソースは、ページレンダリングツリーの計算、対応するレイアウト、要素の描画、および（場合によっては新しいネットワークリクエストを介して）残りのリソースを要求するなど、並行して発生するさまざまなプロセスを表します。

読み込み時間

「読み込み時間」指標は、長年使用されているページ読み込み時間（PLT）に対応しています。 これは、ウェブサービスのパフォーマンスを測定する主要なパフォーマンス指標として、今でも時折考えられている。これは、ウェブページが完全に読み込まれるまでに必要な時間を表します。

ウェブページの読み込みに含まれる主な段階を以下に示します。

1. ユーザーがウェブページのリンクをクリックするか、有効なURLを入力すると、ブラウザはキャッシュにURLがない場合は解決（DNSリクエスト）を行い、サーバーとのTCP/TLSセッションを確立するなど、さまざまな手順を実行します。
2. サーバーはリクエストを受信して処理します
3. サーバーは要求されたデータをユーザーのブラウザに送信する
4. ブラウザはHTMLコードを解析し、必要に応じて追加のリソース（CSS、JSなど）を要求します。
5. ウェブページを構成するすべての要素が完全に読み込まれました。ブラウザは画面上のページのレンダリングを開始できます。

ご覧のとおり、読み込み時間は、ユーザーのリクエスト時刻からウェブページが完全に読み込まれ、画面に表示されるまでの時間を計測したものです。この時点で、ブラウザのスピナーが停止します。

一連の出来事のより詳細な図を以下に示します。

当社の指標計算は、W3CのタイムナビゲーションAPIに基づいています。

ロード時間メトリック値の計算は、loadEventEnd - startTime に対応します。

これは、ブラウザによるウェブページのリクエスト（startTime）から、すべてのコンポーネントが完全にロードされた時点（loadEventEnd）までの時間を計算します。

Redirect

HTTPリダイレクトは、ウェブサービスのパフォーマンスに影響を与える可能性があります。したがって、監視することが重要です。

HTTPセッション（http://www.netskope.com）を例にとってみましょう。対応する安全なHTTPSセッション（https://www.netskope.com）にリダイレクトします。時間的な観点から見ると、下の図から、最初のHTTP接続がHTTPS接続のリダイレクト時間内に完全に含まれていることがわかります。つまり、初期のHTTPセッションメトリクス（ DNS 、 TCP 、サーバー、転送）はそのままでは利用できないということです。それらがパフォーマンスに及ぼす潜在的な影響は、対応するセキュア接続のリダイレクト時間に含まれています。最初のHTTP接続は報告されません。

ブラウザがリダイレクトを実行するのにかかる時間は、Netskopeのリダイレクト指標に対応します。以下に示す W3C タイムナビゲーション API ビューに示すように、リダイレクト時間 = fetchStart – startTime となります。

Wait

ウェブページの読み込みプロセスは、主に以下のステップに分けられます。

1. ブラウザは、ネットワークリクエストを実行する前に、ローカルでリクエストを処理し、たとえばローカルにキャッシュされたデータを確認します。
2. リソースがローカルに利用できない場合は、ネットワーク上で要求されます。
3. サーバーはリクエストを受信して処理します
4. 要求されたデータは、ネットワークを介してサーバーからブラウザに転送されます。
5. ウェブページはユーザーのブラウザ上でレンダリングされています

Netskopeの待機時間指標は、最初のステップの一部です。ブラウザがリソースを取得する必要がある場合、ネットワーク上でリクエストを開始する前に、2つの基本的なチェックを実行します。

1. ブラウザは、リソースがローカルのキャッシュに存在するかどうかを確認します。
2. リソースがローカルに存在しない場合、ブラウザはリソースの取得が許可されているかどうかを確認します。

第2段階の所要時間は主に以下の要因によって決まります。

• HTTP プロトコルを使う:
  たとえば、HTTP/1.1 では、 ほとんどのブラウザは、同じホスト名/ドメインに対して同時に6つ以上のTCPセッションを確立することはできません。ブラウザがこの制限に達すると、新しい空きスロットが出るまで待機する必要があります。
• 優先度の高いリクエスト:
  ブラウザは、レンダリングをブロックするJSまたはCSSが取得および実行されるまで待機してから、他の操作に進むことができます。
• ディスクキャッシュに領域を割り当てています:
  ディスクキャッシュ領域を割り当てる短い処理中は、ブラウザは他のタスクを実行できません。

ブラウザがこれらの基本的なチェックを実行するのにかかる時間は、Netskopeの待機時間（Wait ）指標に相当します。以下に示す W3C Time Navigation API ビューに示すように、待機時間 = domainLookupStart - fetchStart です。

ネットワークとプロキシの設定

ウェブページの読み込みプロセスは、主に以下のステップに分けられます。

1. ブラウザは、ネットワークリクエストを実行する前に、ローカルでリクエストを処理し、たとえばローカルにキャッシュされたデータを確認します。
2. リソースがローカルに利用できない場合は、ネットワーク上で要求されます。
3. サーバーはリクエストを受信して処理します
4. 要求されたデータは、ネットワークを介してサーバーからブラウザに転送されます。
5. ウェブページはユーザーのブラウザ上でレンダリングされています

以下に示す W3C タイムナビゲーション API ビューに示すように、ネットワーク部分には FQDN (完全修飾ドメイン名) 解決プロセスと TCP/TLS セッション確立が含まれるため、「 Network Setup =  DNS time  +  Connection Time  +  TLS time 」となります。

ネットワークセットアップ時間は、誘導トラフィックとバイパストラフィックの両方について、指標として存在します。どちらのシナリオでも、ブラウザインスタンスはTCPセッションを確立し、TLSをネゴシエートする必要があります。Netskopeにトラフィックをルーティングする場合の違いは、 Netskopeが最初にNetskopeプロキシサービスへの接続を確立し、プロキシサービスが関連するすべての処理を適用した後、ブラウザのターゲットアプリケーションへの接続を確立することです。 そのため、その後、プロキシセットアップ時間メトリック（ Netskopeプロキシサービスとターゲットウェブアプリケーション間のTCP接続時間とSSLネゴシエーション時間を表す）が表示されます。 バイパスされたトラフィックの場合、ネットワークセットアップ時間は、アプリケーションターゲットへのDNS、TCP接続、およびSSLネゴシエーションのセットアップ時間を直接表すため、プロキシセットアップ時間は存在しません。

サーバー応答時間

ウェブページの読み込みプロセスは、主に以下のステップに分けられます。

1. ブラウザは、ネットワークリクエストを実行する前に、ローカルでリクエストを処理し、たとえばローカルにキャッシュされたデータを確認します。
2. リソースがローカルに利用できない場合は、ネットワーク上で要求されます。
3. サーバーはリクエストを受信して処理します
4. 要求されたデータは、ネットワークを介してサーバーからブラウザに転送されます。
5. ウェブページはユーザーのブラウザ上でレンダリングされています

以下のW3CタイムナビゲーションAPIビューに示すように、サーバー時間 = responseStart - requestStartです。これは、一般的にTTFB（Time To First Byte：最初のバイトに到達するまでの時間）と呼ばれるものと同等です。クライアントがサーバーにウェブリクエストを送信すると、サーバーメトリックは、サーバーが最初のパケット（応答ステータスコードを含む）をクライアントに送り返すのにかかる時間に対応します。

これはサーバーのパフォーマンスに直接関係するため、非常に重要なパフォーマンス指標です！

データ転送

ウェブページの読み込みプロセスは、主に以下のステップに分けられます。

1. ブラウザは、ネットワークリクエストを実行する前に、ローカルでリクエストを処理し、たとえばローカルにキャッシュされたデータを確認します。
2. リソースがローカルに利用できない場合は、ネットワーク上で要求されます。
3. サーバーはリクエストを受信して処理します
4. 要求されたデータは、ネットワークを介してサーバーからブラウザに転送されます。
5. ウェブページはユーザーのブラウザ上でレンダリングされています

Netskope Transferメトリックは、第4ステップに相当します。ブラウザがサーバーからリソースを取得する際、転送時間は、サーバーがリクエストを処理した後（サーバーがステータスコード200をブラウザに返送した後）、リソースをブラウザに送り返すまでの時間に対応します。この指標は、ロードするリソースのサイズとネットワークの状態（遅延やパケット損失）に直接影響されます。

以下に示す W3C タイムナビゲーション API ビューに示すように、転送時間 = responseEnd - responseStart となります。

Errors

ブラウザがウェブページおよび関連するウェブリソース（JavaScript、画像、スタイルシートなど）を要求すると、これらのリソースが存在するさまざまなサーバーにHTTPリクエストを送信します。ウェブリソースへのリクエストは、「ページロード」または「リクエスト」と呼ばれます。 HTMLページには複数のファイルが含まれる可能性があるため、ページビューごとに「ページ読み込み」または「リクエスト」が複数回発生する可能性があります。

ブラウザは「ページ読み込み」または「リクエスト」が行われるたびに、サーバーにHTTPリクエストを送信し、サーバーはHTTPレスポンスを返します。HTTPレスポンスヘッダーにはステータスコードが含まれており、これはHTTPリクエストが正常に完了したかどうかを示します。回答は5つのカテゴリーに分類されます。

1. 情報提供に関する回答（100～199）
2. 有効な回答数（200～299件）
3. リダイレクト（300～399番）
4. クライアントエラー（400～499）
5. サーバーエラー（500～599）

ご覧のとおり、ステータスコードが400未満の場合はすべて、リクエストが成功したことを示しています。発生する可能性のある主なクライアントエラーは以下のとおりです。

ステータスコード	デスクリプション
400 – 不正なリクエスト	構文が無効だったため、サーバーはリクエストを理解できませんでした。
401 – 不正アクセス	HTTP標準では「unauthorized」と規定されているが、意味的にはこのレスポンスは「unauthenticated」を意味する。つまり、クライアントは要求された応答を受け取るために、自身を認証する必要がある。
403 – 禁止	クライアントはコンテンツへのアクセス権を持っていません。つまり、認証されていないため、サーバーは要求されたリソースの提供を拒否しています。401エラーとは異なり、クライアントの身元はサーバーに認識されている。
404 – 見つかりません	サーバーは要求されたリソースを見つけることができません

よく発生する可能性のあるサーバー エラーは次のとおりです。

ステータスコード	デスクリプション
500 – 内部サーバーエラー	サーバーは対処方法がわからない状況に遭遇しました
502不正なゲートウェイ	このエラー応答は、サーバーがリクエストを処理するために必要な応答を取得するゲートウェイとして機能している際に、無効な応答を受け取ったことを意味します。
503 – サービス利用不可	サーバーはリクエストを処理する準備ができていません。一般的な原因としては、サーバーがメンテナンスのために停止しているか、過負荷になっていることが考えられます。
504 – ゲートウェイタイムアウト	このエラー応答は、サーバーがゲートウェイとして機能している際に、時間内に応答を受信できない場合に発生します。
505 – HTTPバージョンがサポートされていません	リクエスト内の HTTP バージョン はサーバーでサポートされていません。

Netskopeによって報告されたエラーのある「ページ読み込み」または「リクエスト」の数は、HTTPレスポンスステータスコードが399を超えるすべてのHTTPリクエスト、およびサーバーがクライアントに全く応答せずに失敗したすべてのリソース取得プロセスに対応します。

CORS

CORSとは、サーバーが自身のサーバー以外のサーバーからのリソースの読み込みをブラウザに許可させる仕組みです。

「CORSがパフォーマンス監視に与える影響とは」という記事で詳しく説明されているように、CORSはW3CタイムナビゲーションAPIのメトリクスの報告方法に大きな影響を与えます。

クロスオリジンリソースを要求する場合、上記の図に示されているすべてのメトリックのうち、以下の属性のみが正しく報告されます。

• startTime
• fetchStart
• responseEnd
• duration

さらに、リダイレクトされたクロスオリジンリソースのstartTimeは、最終的なリソースのみを反映したものになります。つまり、startTimeはredirectStartではなくfetchStartになります。これは、リダイレクトが発生した時刻がリソースのタイミングから隠蔽されることを意味します。

前述のとおり、CORSによって生じる制限にもかかわらず、リソースの取得にかかる全体の時間を計算することは可能です。

具体的には、これはアプリケーション全体のパフォーマンスに大きな影響を与えるリソースを容易に特定できることを意味します。