ロリポップさんで、HTTP/1.1とHTTP/2の比較サイトを立ち上げられていたので、計測して比較しました。
計測対象サイト
計測条件
- 日本の帯域保証型(100Mbps)光回線を使用 NTT KDDI
- 計測ブラウザ … Chrome53
- 計測頻度 … 15分に1回
- 計測期間 … 4月12日～5月9日の29日間
- 計測ツール … Catchpoint
Catchpointを知らない方のために説明しますと、CatchpointはWebサイトのパフォーマンスを24時間365日定常監視・計測するためのサービスを提供している企業です。
Googleの品質保証担当Vice PresidentだったMedhi Daoudiが2010年に立ち上げた企業で、現在、Google、Microsoftなどのテクノロジー企業、AkamaiやFastly、MaxCDNなどのCDN各社、Verizonなどの通信企業など、数多くの企業が利用しているサービスです。
ちょっと宣伝させて頂くと、現在、日本については私の会社Spelldataで販売しております。
計測結果
ダウンロード時間
| サイト | 平均 | 最小 | 25パーセンタイル | 50パーセンタイル | 75パーセンタイル | 最大値 | n |
|---|---|---|---|---|---|---|---|
| https://http1-1-contents.com | 1,495.50 | 1,034 | 1,340 | 1,399 | 1,492 | 7,200 | 2,550 |
| https://http2-contents.com | 1,370.08 | 783 | 1,224 | 1,310 | 1,389 | 19,688 | 2,551 |
| サイト | 平均 | 最小 | 25パーセンタイル | 50パーセンタイル | 75パーセンタイル | 最大値 | n |
|---|---|---|---|---|---|---|---|
| https://http1-1-contents.com | 1,727.34 | 413 | 1,537 | 1,638 | 1,765 | 5,439 | 2,541 |
| https://http2-contents.com | 1,700.41 | 293 | 1,534 | 1,657 | 1,785 | 9,375 | 2,548 |
まずは、ダウンロード時間です。 まず、ダウンロード時間の定義ですが、HTTP/1.1もしくはHTTP/2の通信が途絶えてから2秒経過したところでダウンロードの完了と見做し、2秒マイナスした値となります。
商用計測サービスでは一般的なダウンロード時間の検出方法です。
グラフは、1日毎の75パーセンタイル値で生成しています。 何故、75パーセンタイルなのでしょうか？
表の最大値を見て下さい。 75パーセンタイル値に比べて最大値（100パーセンタイル）は、極端に遅延しています。 インターネットの中では、日々、様々な状況が発生しています。この影響によって遅延が生じます。 また、この計測対象自体は複数のホスト(Third Party)からファイルを取得しているため、それぞれのThird Partyの負荷状況によってパフォーマンスが遅延します。 結果として、全体の25%ぐらいは、どうしても、全体の他の値より遅延した集合となるのです。
これを考慮せずに平均してしまうと、表の平均値のように、最小と最大の情報が消えてしまい、実際の分布の把握が難しくなってしまいます。
平均値は、分布が左右対称の場合には一つの目安として有効ですが、このような非対称型の分布では平均値は役に立たないので注意が必要です。 統計学では、よく「平均値の罠」と言います。
さて、このデータを見ると、KDDIにおいては、HTTP/2の方が高速であり、NTTにおいてはHTTP/1.1の方が勝っているようです。 しかし、その勝り具合というのも微妙です。 累積分布関数でグラフにします。
このグラフは、横軸がパーセンタイル値、縦軸がダウンロード時間（ミリ秒）です。 このグラフで、何パーセントの確率で、何秒でダウンロードが終わるのかが、計測値のデータを元に判別できます。
これを見ると、大して差は無いのだと分かります。
層別に分析する
これらのダウンロード時間は、対象ページを構成する複数のホストからのファイルの配信のダウンロード時間の合算値になっています。 従って、これをホスト単位で見る必要があります。
- ajax.googleapis.com
- cdnjs.cloudflare.com
- http1-1-contents.comもしくはhttp2-contens.com
- lolipop.jp
統計学では、このようにある特徴によって、いくつかのグループに分けることを「層別化」と言います。 品質のばらつきを分析する観点では「分散の分解」とも言います。
KDDIの分析
まずは、KDDIのデータを分析してみましょう。
これを15分単位での最大値でグラフ化すると、こうなります。
すると一気にグラフの様相が変わりましたね。 1日単位のグラフは全体の傾向を調べるために、15分単位での最大値はパフォーマンスのサージ(突発的な遅延や負荷)の発生度合いを 見るために使います。
これだと、視覚に惑わされてしまうため、100ms単位の区間のダウンロード時間で棒グラフにしてみます。
このように見ると、http1-1-contents.com本体のHTTP/1.1の配信は、最頻値が200～300msであることが分かります。
次にHTTP/2です。
http-2-contents.com本体のHTTP/2の配信は、最頻値が600～700ms、最速でも400～500msであることが分かります。 分布もHTTP/1.1よりなだらかな山を形成しており、配信品質のばらつきが大きいことを示しています。
NTTの分析
次に、NTTのデータを分析してみましょう。
KDDIと違い、CloudFlareの配信が、NTTでは遅いことが分かります。 これが、KDDIよりも遅延している原因だったのです。
http-1-1-contents.com本体のHTTP/1.1の配信は、KDDIと同様に200～300msが最頻値であることが分かります。
次にHTTP/2です。
http-2-contents.com本体のHTTP/2の配信は、最頻値が900～1,000ms、400～500msでの配信は2,541回のデータ中、12回しか観測されていません。 KDDIよりも更にHTTP/2の方が遅いことを示しています。
表示に関する指標 ― Render StartとDocument Complete
ダウンロードについては、HTTP/1.1の方が遥かにHTTP/2より速い事が分かりました。
しかし、重要なのは、表示速度です。 そこで、表示速度に関する指標である、Render StartとDocument Completeの値を見ていきます。
Render Start
Render Startについては、KDDIでもNTTでもHTTP/1.1の方が速いことが分かります。
これを累積分布関数のグラフにします。
このグラフを見ても、若干HTTP/2の方が表示開始が遅いのが分かりますが、顕著な差ではないです。
Document Complete
Document Completeについては、HTTP/2の方がHTTP/1.1より僅かながらも速いことが分かります。
しかし、これも累積分布関数を見れば、大した差ではないと分かります。 KDDIでは差が出ていますが、NTTではほぼ同じです。
結論
HTTP/1.1とHTTP/2の表示速度には、この検証サイトを計測した結果、有意差は無いです。
注意点
ご自身で検証される場合
もし、皆さんが、Chromeの開発者ツールなどで確認されるのであれば、以下の点に注意して下さい。
- 必ずシークレットウィンドウで行う … 拡張機能などの影響を排除するためです。
- 必ず一回読み込むごとに、シークレットウィンドウを立ち上げ直す … シークレットウィンドウであっても、キャシュが効いてしまい、リロードすると速い値が出ます。