私たちはユーザーがリソースにリクエストを始めてから、そのリソースがユーザーにとって完全に有効になるまでの時間を往復(round trip)時間として定義します。私たちが測定できるものは HTML ページのリソースでなおかつ、私たちがコントロールできるページ上からのクリックまたは画面遷移によってリクエストされたリソースに限ります。
往復時間はしたがって、リンクをユーザーがクリックしてからユーザーによってページが参照されるまでの時間となります。多くの場合、これは前のページの onbeforeunload イベントが発生してから現在のページの onload イベントが発生するまでを測定すれば問題ありません。いくつかのケースでは違うかもしれませんが、私たちはこれらのイベントを開発者が決められるようにします。
どのように測定するか。
window.onbeforeunload
イベントに関数をアタッチする。
この関数で時間(ms)を取得し、現在のページの URL と一緒にセッション Cookie に保存します。
window.onload
イベントに関数をアタッチする。
この関数で時間(ms)を取得し、前のページの onbeforeunload イベントハンドラーで保存された Cookie を探します。もし Cookie が見つからずブラウザーが WebTiming API を実装しているか検証します。もし WebTiming API を実装していればそこからのデータを使うようにします。どちらも見つからなければそこで終了します [1] 。
もし Cookie が見つかった場合、Cookie の中に保存された URL と現在のページの document.referrer
を検証します。もしこのふたつが違った場合、ユーザーが二つのページの間で三つ目のページに訪れたかもしれないため測定は失敗し、そこで終了します [2] 。
もしここまで実行できていれば、Cookie から時間を取り出して Cookie を削除します。二つの時間の差を測定し、これがページの往復(Round trip)時間となります。
帯域幅と遅延はサーバー上の固定サイズの画像のダウンロードとそれらをダウンロードするためにかかった時間によって測定します。次のようにして実行します:
最初に 32 byte の GIF を10回続けてダウンロードします。これを遅延の測定に使用します。
1回目の測定結果は TCP のハンドシェイク(3パケット)と TCP のスロースタート(4パケット以上)を消費するため破棄します。他の全ての画像のリクエストは TCP の2パケット(リクエストの1パケットとレスポンスの1パケット)を消費します。これはブラウザーからサーバーへの HTTP リクエストにどれくらい時間がかかっているかの良い目安になります。
それが済むと平均値を計算し、9回のダウンロードによって得られた標準偏差と標準誤差は95%信頼できる値となります。これがビーコンによってサーバーから返ってきた遅延の値になります。
次はタイムアウトが発生するまで画像のサイズを大きくしていきダウンロードします。
できるだけ早く帯域幅の範囲で画像のサイズを絞り込みます。詳しいことは boomerang.js のコメントをご覧ください。
画像のタイムアウトを1.2秒から1.5秒の間に設定します。もしタイムアウトした場合、それより大きい画像のダウンロードをやめて、その時点で最も大きい画像のダウンロードを4回以上試します [3] 。ダウンロードした最も大きい画像3つから帯域幅を計算します。 それよりも前にタイムアウトしない限りこれによって7つの結果が得られるはずです [4] 。中間値を計算し、これらの値から得られた標準偏差と標準誤差がビーコンによってサーバーから帰ってきた帯域幅になります。
最新のソースコードとドキュメントは github.com/SOASTA/boomerang に公開されています。
BW.nruns
パラメーターを使って設定できます。boomerang の詳しい設定は Howto #6 をご覧ください。