ケーススタディ2:ビートップス
ケーススタディ2:ビートップス
テレビ通販・テレビショッピングサイトであるビートップスのトップページ(www.b-tops.com)は、ページ総容量が平均1.1MB、HTTPリクエスト数130(※測定時点の数値)の、今回計測した3サイトの中で最も容量が大きなページである。
初めに、バックボーンテスト※1の結果から得られた、応答時間の平均値(4時間ごと)を示した折れ線グラフを確認していこう。
- 平均応答時間:2.001秒
- 最小応答時間:1.137秒
- 可用性:100%
- 標準偏差:1.94秒
バックボーンテストの測定期間中、ほとんどの時間帯で約2秒の応答時間と安定(平均応答時間:2.001秒)しているものの、5秒前後の急な増加を数回記録している。この結果が何の影響によるものか、サーバー監視やアクセス解析との併用で調査を行うべきだといえる。
続いて、ラストマイルテスト※2でユーザーが実際に体験している応答時間を測定したのが次のグラフだ。バックボーンテストに比べて、さまざまなユーザー環境の違いが反映されたデータになっている。
接続回線 | 平均応答時間 | 可用性 | エラー数 | テスト回数 |
---|---|---|---|---|
ダイアルアップ接続 | 50.765秒 | 32.14% | 19 | 28回 |
低速ブロードバンド接続 | 36.715秒 | 90.53% | 9 | 95回 |
高速ブロードバンド接続 | 8.401秒 | 98.96% | 2 | 193回 |
512kbps以下の中低速回線では応答時間が急激に増加していることが確認できる。さらにダイアルアップ接続(56kbps以下)では、可用性が32.14%に激減、これは28テスト中19テストにおいて2分以内にページ表示が正常に行われなかったことを示している。
通信フェーズ | ダイアルアップ接続 | 低速ブロードバンド接続 | 高速ブロードバンド接続 |
---|---|---|---|
応答時間 | 50.765秒 | 36.715秒 | 8.401秒 |
DNS Time | 0.853秒 | 0.747秒 | 0.296秒 |
Connect Time | 1.858秒 | 1.748秒 | 0.265秒 |
1st Byte Time | 41.365秒 | 24.541秒 | 8.153秒 |
Content Time | 61.584秒 | 45.892秒 | 7.030秒 |
通信フェーズごとの数値を確認すると、特に回線速度が遅い場合には応答時間に占める1st Byte TimeとContent Timeの比率が高く、オブジェクトの容量とHTTPリクエスト数が影響していることが想定できる。
ビートップスへのプロのパフォーマンス改善ポイント
バックボーンテストの結果から代表的なデータを1つ選び、ウォータフォールグラフにしてさらに深い分析を行った。
JavaScriptの記述場所によるダウンロードの効率化
グラフから、Google Analyticsへのデータ送信が、ページの読み込み開始直後に行われているのが確認できる(7行目)。HTTP Keep Aliveを使用していても、JavaScriptの読み込み後にキューに入力されたオブジェクトは、そのJavaScriptが実行されるまではダウンロードが中断されるため、JavaScriptはできるだけソースの下のほうに記述するのが望ましい。また、パフォーマンスの観点からだけでなく、ページ表示が完了する遥か前にGoogle Analyticsへのデータ送信が行われると、ページビュー数の集計に影響が及ぶ可能性も考えられる(Google Analyticsのトラッキングコードは、ページの</body>タグ直前への設置が推奨されている)。
ホスト追加による並列ダウンロード数の増加
すべての画像が1つのホスト(125.29.37.197)からダウンロードされている。HTTP Keep Aliveを使用することで同時に2ファイルを並列ダウンロードできるが、さらにホストを追加することで3ファイル以上の並列ダウンロードが可能になる。ホストへの接続時間(DNS TimeとConnection Time)を差し引いても全体的なパフォーマンス向上が達成できるかもしれない。
CSSスプライトやイメージマップを活用したHTTPリクエストの削減、画像を除くオブジェクトファイルのgzip圧縮など、ケーススタディ1で述べた内容は説明を割愛しているので、そちらも参照してほしい。
ソーシャルもやってます!