これらは boomerang を使用できるいくつかの方法です。これはライブラリーが実際に全てのユースケースをサポートしているかの確認に役立ちます。
私たちはユーザーがページを読み込むために要した時間を計測する手段を必要としています。通常これはユーザーがリンクをクリック（またはブラウザーに URL を入力）してからページが使用可能になるまでの時間を指します。
リンクがあなたのコントロールできる領域にあればクリックされた時間を記録するのは簡単ですが、ユーザーがブラウザーに URL を入力して Enter キーを押したときの正確な時間を伝えるのは簡単ではありません。そこで私たちがコントロールできるページ上のリンクのクリックに注力します。
ページが使用可能になる時間が分からないことのうちの一つになります。ほとんどのページではこれは onload イベントが発生した時点となりますが、実際にはページが使用可能となる前に onload イベントが発生する（例えば、多くのコンテンツが JavaScript によって読み込まれている）可能性もあります。また、onload イベントが発生する前にページが使用可能となる（例えば、隠されたリソースがページ下部に埋め込まれた JavaScript によって読み込まれる）場合もあります。これらのどちらのケースにおいても、ページの開発者は自分のページが利用可能になる時のより良いアイデアを持ち、自分のライブラリーにこのイベントを発生させられるようにすべきです。
これを4つのユースケースに切り分けます:
多くのウェブサイトは動的にコンテンツを読み込むことがあります。例えば、スライドショーに使う画像やタブを使ったコンテンツは JavaScript を通して読み込まれます。証券相場では定期的に XHR を使ってバックエンドのウェブサービスから自らリフレッシュする場合がありますし、ウェブメールサービスは JavaScript を使ってサーバーに新しいメッセージを確認したり選択されたメッセージをダウンロードしたりします、などなど。
これら全てのケースでブラウザーはダウンロードが開始されたとき、また完了したときのイベントを発生させることができません。開発者が必要なときに呼び出せるようなメソッドやイベントをライブラリーは公開する必要があります。
使用方法 #2 をご覧ください。
ユーザーは様々なインターネット接続を使ってウェブを参照するため、全てのユーザーの統計学的な数値を表すために複数のユーザーのページの読み込み時間を常に集めることはできません。しかしユーザーの回線帯域幅を知っていることから、似たようなユーザーからデータを集め、ネットワーク接続のタイプごとにユーザーの統計的な数値として使用できます。
使用方法 #3 をご覧ください。
多くのウェブサイトは異なるバックエンドサービスから読み込まれる別々のコンポーネントによって構成されていることがあります。例えば私のホームページには dopplr、upcoming、twitter、delicious、flickr といったウィジェットがあります。今ではページ全体の読み込み時間が重要であり、これこそがユーザーにはページのパフォーマンスとして認識されます。これはページ全体の測定の一部にすぎませんが、便利で各コンポーネントの個別の読み込み時間を測定するためにも有益です。つまりこれはページの読み込み時間を各コンポーネントの読み込み時間に切り分けることを可能にし、ページ内の各コンポーネントの分析を行ないます。
これを行うには開発者がライブラリーを使ってページにタイマーを追加できるようになっている必要があります。これらのタイマーはページ全体の読み込みとともにビーコンを送る必要があります。
使用方法 #4 をご覧ください。
ネットワークの遅延はページのダウンロード時間が大きな要因です。それは TCP 接続を確立し、HTTP リクエストを生成するいくつかのパケットを必要とするため、HTTP の遅延は単純な ping よりも高くなってしまいます。また HTTP リクエストと実際のページのコンテンツに関係のないレスポンスヘッダーがオーバーヘッドに関係します。
ユーザーの HTTP の遅延を測定することはページ全体の並列化されたコンポーネントのダウンロードが与える影響の良い指標を提供してくれます。
使用方法 #3 をご覧ください。
パフォーマンスの解析をしているとき、それは2つ以上のデザインの異なるページのパフォーマンスを比較する A/B テストを行うときに便利です。 これらのページには同じ URL があるかもしれないため、その一連のテストからページを識別しビーコンのデータをもとに必要なときにいくつかの情報が追加されます。
ライブラリーは追加情報を各ページにタグをつける機能を開発者に提供するべきです。
使用方法 #5 をご覧ください。
DNS の遅延は DNS のリクエストを行うためにどれくらい時間がかかるかを教えてくれます。これは Web サーバーや DNS の設定、ユーザーの ISP の DNS サーバーがどのような構成になっているか、など様々な要因によって影響を受ける可能性があります。この遅延の測定で私たちは一つのページ上で安全にルックアップした多くのドメインの目安を得られます。これらは私たちがルックアップできる DNS の数と複数のドメインが私たちにもたらす並列性を交換することになります。HTTP の遅延と DNS の遅延は一緒にユーザーのためにこの点がどこにあるかを私たちに教えてくれます。
使用方法 #8 をご覧ください。
トラフィックが高いサイトの場合、全てのリクエストではなくランダムなサンプルだけ測定した方が便利です。私たちはサーバーサイドでランダムなサンプリングを行うことができ、一部のリクエストに JavaScript の提供だけします。また、私たちはサーバーを簡素化し、クライアントサイドでサンプリングできます。
クライアントサイドのサンプリングはクライアント間で状況を共有しないためサーバーサイドのように正確にはなりませんが、私たちはランダムなサンプルは得ることができます。
TODO #1 ご覧ください。
もしあなたの URL がある場合、それは故意または誤った使い方によって悪用される可能性があります。
例えば、あなたが満足するサイトのデザインを行い、パフォーマンスを測定するために boomerang の JavaScript を埋め込みます。JavaScript はあなたのサーバーにビーコンを送ります。あなたのデザインが本当に好きな誰かがサイトに訪問して、あなたの HTML をコピーして彼らは自分のサーバーにコピーします。彼らはテキストや画像を変えたりしますが、JavaScript はあなたのサーバーにビーコンをまだ送り続けます。あなたは彼らのビーコンを受け取ることになってしまううえに、これだけでもあなたのサーバーの負荷を増やし測定を台無しにしてしまいます。
次に可能性があるのはあなたのビーコンの URL を幼稚なスクリプトが見つけ、不当にあなたのサーバーを大量に叩き始め、何もなければ DoS 攻撃を試してくる場合もあります。
boomerang はこれらの問題から守る必要があります。
使用方法 #7 をご覧ください。
モダンブラウザーはページの読み込みに関する多くのパフォーマンス情報を取得できる Navigation Timing API をサポートしています。NavigationTiming プラグインはこの情報を回収し、ビーコンに追加します。
使用方法 #9 をご覧ください。
最新のソースコードとドキュメントは github.com/SOASTA/boomerang に公開されています。