読者です 読者をやめる 読者になる 読者になる

Webサイトパフォーマンスについて

Webサイトのパフォーマンス計測について記事を書いています。パフォーマンス管理は、品質管理です。ですから、これをやっておけば大丈夫みたいなBest Practiceで済む世界ではないです。定常計測や、計測データの分析の正しいやり方の認知が普及することを目的としています。内容は、ハードコアかも。

「HTTP vs HTTPS Test」(www.httpvshttps.com) の主張を検証する

HTTP vs HTTPS(www.httpvshttps.com)

実はこの記事は、2014年12月に書いておいたものです。計測データを新しくして、修正してあります。

海外でも日本でも、このHTTP vs HTTPS Testが公開された当初は、テストとしてどうなの?という、「適正さ」が問題視されたので、「まぁ、いいか」、と思って公開しなかったのです。

しかし、以下の記事で、SSLの高速化の証拠として挙げていたので、「技術の会社なんだから、ちゃんと調べてから、エビデンスとして使えよ…」と、呆れ返る想いで、ちゃんと公開しておこうと思いました。

web-tan.forum.impressrd.jp

このサイトが、太文字で書いて以下のように主張しています。

Encrypted Websites Protect Our Privacy and are Significantly Faster
(暗号化されたWebサイトは、我々のプライバシーを守り、且つ、有意により速い)

しかし、注釈が付いていて、このように書いてあります。

Only full, end-end encryption ensures complete privacy. Cloudflare and MaxCDN SSL encryption services compromise privacy by using interceptive middle proxy servers. HTTPS means "Secure HTTP". Plaintext HTTP/1.1 is compared against encrypted SPDY HTTPS on a non-caching, nginx server with a direct, non-proxied connection. HTTP/2 provides similar same benefits, and this server only supports SPDY.
(完全にエンド・トゥ・エンドの暗号化が、完全なプラバシーを確実にします。CloudflareとMaxCDNのSSL暗号化サービスは、通信の間に入るプロキシサーバを使っているため、プライバシーを危うくします。HTTPSは、「Secure HTTPS」を意味します。プレーンテキストのHTTP1.1と、暗号化されたSPDY HTTPSで、キャッシュせず、プロキシを経由せず、直接nginxサーバに接続して比較しました。HTTP2は同じような効用を齎し、このサーバはSPDYのみをサポートしています。)

エンド・トゥ・エンドのHTTPSによる暗号化がプライバシーを確実にするというのは、その通りだと思います。

しかし、速くするというのは、本当でしょうか?

そこで、実際にSPDYのパフォーマンス検証を、このサイトを計測してやってみることにしました。

計測条件

  • ダラスの各ISP光回線を使用
    • Cogent
    • GTT
    • Level3
    • Telx
  • 計測ブラウザはChrome
  • 計測頻度は15分に1回
  • 計測期間は1日
  • 計測ツールには、Catchpointを使っています。Catchpointは、GoogleMicrosoftを始めとして、欧米の企業がWebサイトパフォーマンスの品質管理のために使っているツールです。

    f:id:takehora:20160614110855p:plain

 このサイトのサーバは、アメリカのテキサス州ダラスに設置してあると、ページの下部に書いています。物理的な距離が遠い場所から計測すると、レイテンシの影響や、途中経路のパケットドロップの影響がノイズとして計測値に影響します。

今回は、HTTPとHTTP/2、どっちが高速かを調べるのが目的なので、レイテンシやパケットドロップは変数として入れたくないので、ダラスで計測して、これらの変数に影響されないようにします。

通常、私は一週間ぐらい計測するのですが、一日の計測データで、十分に有意な差が出たので、一週間計測する必要は無いです。

Catchpointの計測設定では、HTTP/2を有効にするかどうかを明示的に設定できるようになっています。

f:id:takehora:20160623111434p:plain

Chromeの計測では、ここがデフォルトでチェックが入っていて有効になっています。

今回、HTTPの接続では、ここのチェックを外して、明示的に無効化してあります。

このサイトの結果表示の問題点

このページで表示される秒数には、罠があるのです。

経時方法の問題点

このページに表示される経過時間ですが、以下のようにコーディングされています。

26行目


if (!window.supportsLatestHTTPS) {
	document.getElementsByTagName('html')[0].className+= ' unsupported-browser';
} 	var start = Date.now();
var elapsedMs;

415行目


function setElapsedTimeDisplay() {
	elapsedMs = (Date.now()-start);
	timeEl.firstChild.data = (elapsedMs/1000).toFixed(3)+' s';
}

これは、イベント処理を計測するには良いのかもしれませんが、パフォーマンスの計測には不適切です。
このコーディングは、以下のMozillaのドキュメントにも記載があります。

developer.mozilla.org

そして以下のような注記が添えられています。

注記: Web Performance API の High Resolution Time 機能をサポートするブラウザでは window.performance.now で、Date.nowよりも高信頼かつ高精度な経過時間の測定が可能です。

takehora.hatenadiary.jp

上の記事で、度量衡の統一の重要性を説明しましたが、計測方法が適切でなければ、その値は信用に値しないのです。

サードパーティコンテンツの「ノイズ」の問題

このwww.httpvs.https.comのコンテンツは、

のボタンが付いています。

このような自分のドメイン以外のコンテンツを「サードパーティーコンテンツ」と呼びます。

HTTPで17ホスト、HTTPSで13ホストと接続しています。

このサードパーティコンテンツが、パフォーマンスに多大な影響を及ぼしているのです。

f:id:takehora:20160623090257p:plain

HTTPでの接続。サードパーティの影響。fonts.gstatic.comのダウンロードの後、www.google-analytics.comがダウンロードを止めている。

純粋にHTTPとHTTPSの通信のデータを比較したいのであれば、このような、計測対象にノイズが入るようなページを作ってはいけません。

そこで、計測データからサードパーティの分を取り除いて、www.httpvshttps.comのダウンロード時間だけを比較してみます。

計測結果

散布図

 Catchpointの計測データの分析ツールには、ホスト単位でデータを表示する機能があります。

f:id:takehora:20160623101325p:plain

これで、ホスト(サーバ)単位でのパフォーマンスの比較概要を確認することができます。

そして、これで見たいホストのパフォーマンスデータだけを表示させる事が可能です。この機能を使い、www.httpvshttps.comからのダウンロードについてのみ、散布図を作成します。

f:id:takehora:20160623101633p:plain

青いのがHTTPでの接続、緑がHTTPSでの接続です。

明らかに、HTTPの方が高速であるのが分かります。もう一度書いておきますが、これはサーバが設置してあるダラスでの計測データです。

Catchpointの計測は、計測毎に、同時にtracerouteを実行することが可能で、ネットワークの要因がないかどうかを確認する事も可能です。

f:id:takehora:20160623101929p:plain

この散布図を、ISPによって層別で表示してみます。

Cogent

f:id:takehora:20160623102215p:plain

GTT

f:id:takehora:20160623102301p:plain

Level3

f:id:takehora:20160623102330p:plain

Telx

f:id:takehora:20160623102406p:plain

いずれのISPにおいても、HTTPの方が、HTTPSより高速にダウンロードを完了しています。

ヒストグラム

ヒストグラムで見てみても、有意差があるのが明確に分かります。

Cogent

f:id:takehora:20160623102708p:plain

GTT

f:id:takehora:20160623102740p:plain

Level3

f:id:takehora:20160623102851p:plain

Telx

f:id:takehora:20160623102932p:plain

ウォーターフォール

何故、HTTPの方がHTTPSより高速なのかは、ウォーターフォール図を確認すれば一目瞭然です。

HTTPの場合

 

f:id:takehora:20160623103714p:plain

HTTPSの場合

f:id:takehora:20160623105805p:plain

HTTPSの場合は、このダウンロードのオーバーヘッドが下のコンテンツほど大きくなっていきます。

 

f:id:takehora:20160623110349p:plain

更に下のダウンロードは、こんな感じです。

f:id:takehora:20160623110516p:plain

灰色は処理のブロック、橙色が待機時間、かすかに出ている緑はHTTP Getの送信時間です。

確かに、HTTP/2は、一気に並列でダウンロードの要求を出せるんですが、実態はこんなものです。

ちょっと余談

Googleは凄い会社だし、Goolgeの事は私も好きですけど、エンジニアとしては「人の仕事を信用しない」というスタンスが大事だと思っています。

ポジティブな意味で疑ってかかる事が、技術の分野を伸ばすという意味で大事だと思うのです。Googleだからと鵜呑みにするのではなく、自分で検証するまでは、信じない。自分で検証してみて、そこで事実がその通りだと判明すれば、納得の度合いが違うじゃないですか。

誰かがこう言ってるから、そうなんだと信じるのは、「盲信」です。それでは、エンジニアとは呼べないと思うのです。

その意味においては、私の検証結果をそのまま鵜呑みにせずに、是非、「疑わしい」と思って、皆さんも検証してみて下さい。それで同じ結果が出たら、「あぁ、確かに、HTTP/2って遅いじゃないか」って、腹に落ちて理解できると思います。

それで、検証してみて、「いや、HTTP/2は速いじゃないか!こういうデータが出たよ!」というのがあれば、是非ご連絡下さい。

でもね、その検証は、ちゃんと統計学的に正しいやり方でお願いします。
データの取り方の原則は、近代統計学の父である、R・A・フィッシャーが「実験計画法」として確立してるわけですから。
何か、手元のブラウザで計測して、5回計測したら、こうだったとか、それ、証拠にならないですからね…データの信頼性は、観測値の数も重要だし、取得の仕方も大事なんですよ。

もう一つ、大事な話が、こういうのは私の能力が高いわけじゃなくて、道具のおかげで分かるって事です。

計測機器とか計測システムとか。

実験計画法に基づいた、統計的品質管理の観点で信頼できるデータを取得できる計測サービス。それを使えば、誰でも、この程度、分かる話です。

皆さん、上司が理解してくれない、予算が取れないとかあって、ブラウザに付属の無料ツールだったり、安いものを使うわけですけど、安いもの全てが悪いとは言わないですが、それでも「安かろう、悪かろう」なんですよ。計測機器とか計測サービスって。

Google自体もそうですし、他の有名な欧米の企業が、Synthetic Monitoring(合成計測)のサービスに数千万円から数億円かけるのは、ちゃんと、それでリターンが得られるからなんです。

(だからって、皆さんに、数千万円を使って、このサービスを買ってくれと言ってるわけじゃないです。このサービスは、月額10万円の料金からで使えます。興味がある人は、私に連絡を下さい。まぁ、金額は相談に乗ります…)

表示速度を高速化するほどに、配信状況を監視するほどに、儲かるからなんですよ。

でも、そのデータの正確性に問題があったら、全ての分析は、ゴミな結果になるんです。だから、正確性の高いツールを高いお金を払って使ってるわけです。

それって、今に始まった話じゃなくて、日本の製造業なら、どこもやってる話で、モノづくりにおいて、タンジブル(触れられる)な製造業、インタンジブル(触れられない)なソフトウェアと違いはありますが、製造業からモノづくりの手法について学べる事は多々あります。

ソフトウェア開発の手法だって、重厚長大な建設業のウォーターフォール型から、軽量短小の家電製品の開発プロセスにそっくりのアジャイルへと移っているじゃないですか。

開発手法だけじゃなくて、品質検査手法も、製造業に学びましょう。

そして、適切な、正確な値が測れる計測サービスを使いましょう。
正確なモノサシがあるから、ちゃんとした品質のものがつくれるんです。
そうしないと、いつまで経っても、日本のWebサイトは、世界的に遅いままだと思います。

世界と比較して、遅くて、重くて、コード品質も低いWebサイトをつくってるのに、「越境ECだ!」とか「東京オリンピックでインバウンド需要だ!」とか言ってるのって、なんか、夢見てるなぁ~、海外からは遅すぎて見れないのになぁ…って、思うんですよ。

それで、CDNを入れさえすれば良いと思ったりするわけでしょ?あのねぇ、CDNベンダーは、チェックされない限りは、そりゃいい事だけ言いますわ。
私も、元Akamaiだから、まぁ、自分も色々ね、ありましたよ…ここじゃ書かないけど。

だから、欧米の企業は、CDNを入れたら、必ず、オリジン直接と、CDN経由とで、どれだけパフォーマンスがアクセラレートしてるかチェックするんですよ。24時間365日。

「CDNベンダーを信頼してるんで大丈夫です」とかのたまう人がよくいらっしゃるんですが、正直、かわいそうにと思います。面と向かって言わないけど。

ベンダーとは、常に緊張状態を維持しないとダメですよ…

 

Googleも計測してるなら、何で、HTTP/2を推してるんだ?」という疑問をお持ちの方もいらっしゃるでしょうが、Googleだって一枚岩じゃないですからね。巨大組織ですし。その背景事情は、部外者なんで、私は知らないです。

Googleの「Mobile Website Speed Testing Tool」の速度テストは参考にならない

このテストの速度テストの評価を実際の計測データと比較して検証してみる

Google

testmysite.thinkwithgoogle.com

を公開して、各所で話題になっています。

バイルフレンドリーかどうかのテストには使えるのですが、スマートフォン向けWebサイトやデスクトップ向けWebサイトとしてのスピードの判定の参考にならないです。

その理由を以下に説明します。

日本のポータルサイトのパフォーマンス計測のデータと見比べてみる

さて、検証用データとして、日本のポータルサイトの計測データと見比べてみましょう。

今回、計測してみたのは、以下の5つのポータルサイトです。

  • Yahoo!
  • Goo
  • Excite
  • MSN
  • Infoseek

計測条件

  • NTTドコモLTE回線を使用
  • 電波強度は非常に良好
  • 計測機器を設置して行う定点観測なので、基地局間の接続移動処理(ハンドオーバー)は発生しない
  • 計測した場所は、首都圏の住宅街
  • 計測頻度は15分に1回
  • 計測期間は一週間
  • 計測ツールには、Catchpointを使っています。Catchpointは、Googleを始めとして、欧米の企業がWebサイトパフォーマンスの品質管理のために使っているツールです。

    f:id:takehora:20160614110855p:plain

計測結果

f:id:takehora:20160613201404p:plain

表示開始時間

表示開始時間とは、Webブラウザ上に最初の1ピクセルが表示された時間を指します。今のところ、W3C Web Performance Working Groupのメトリックスには入っていません。

理想の値は0.5秒です。しかし、スマートフォン向けWebサイトの場合、LTEのネットワークのレイテンシが50ms前後あるので、0.5秒で表示するのは困難で、1.5秒以内の表示が現実的な目標値となります。

以下の表ですが、75%の値に注目して下さい。

パフォーマンスのデータは、ヒストグラムを作ってみると、シンメトリック(左右対称)なベルカーブを描きません。

(ホスト単位や時間別での層別分析すると、シンメトリックになりますが、それは別の機会に書きます。)

グラフを作成すると、非正規分布となるため、パーセンタイル値を見て、品質を判断します。

例えば、Yahoo!の75%の値は、1433.75msです。
これは、全ての観測値を速いものから順に並べていったときに、75%の位置にある値が1433.75ms=1.4秒強だったという事を意味しています。

「75%の確率で、1.4秒ぐらいで表示が開始される」と言えるわけです。

サイト名平均標準偏差IQR0%25%50%75%100%観測値の数
Excite 1493.130 470.6876 212.00 1132 1327.00 1423.0 1539.00 7263 185
Goo 1813.138 743.8366 625.25 800 1397.75 1563.5 2023.00 4581 160
Infoseek 1271.915 289.8854 192.00 898 1128.50 1210.0 1320.50 3109 199
MSN 1376.255 1273.0804 124.25 939 1196.75 1290.0 1321.00 19074 200
Yahoo! 1406.410 209.4751 119.00 1007 1314.75 1394.5 1433.75 3521 200

観測値の数がサイトによって違いますが、それぞれ200回計測値があって、そこからエラーになったものを除いています。

数値だけを見ると全体像が把握できないので、箱ひげ図で表してみます。f:id:takehora:20160613161548p:plain

Goo以外のサイトについては、計測全体の75%において、ほぼ安定した秒数で表示できている事が分かります。また、残りの25%については、サイトによって、かなりバラツキが出ています。

MSNは、一番遅い値(100%)が19074ms=19秒を超えているので、遅い時には、表示開始速度が相当遅いという事になります。

表示完了時間

表示完了時間とは、W3C Navigation TimingのDocument Completeの時間を指しています。

理想の値は2秒ですが、LTE回線の場合は、相当頑張らないと2秒は無理です。ですので、3秒が現実的な目標値になります。

サイト名平均標準偏差IQR0%25%50%75%100%観測値の数
Excite 8420.686 928.8594 641.0 5465 7988.00 8295.0 8629.00 15185 185
Goo 4259.519 1572.7272 1659.0 2281 3170.00 3815.0 4829.00 12011 160
Infoseek 10155.171 1844.9912 1106.5 7465 9437.50 10113.0 10544.00 29349 199
MSN 2790.175 1197.2390 269.0 1937 2545.75 2677.5 2814.75 18910 200
Yahoo! 3818.530 924.6546 317.0 2956 3583.00 3747.0 3900.00 15813 200

表示完了時間のデータを見ると、サイト毎に相当に数値が違うのが分かります。

これを視覚的に分かりやすくするために、箱ひげ図にしてみました。

f:id:takehora:20160613174605p:plain

一番高速に表示完了を終えているのはMSNだと分かります。しかし、MSNは残りの25%がYahoo!より長く伸びていて、Yahoo!よりバラツキがあるのがわかります。

Mobile Website Speed Testing Toolの結果

Yahoo!

Yahoo!は、以下のような結果になります。

f:id:takehora:20160613175330p:plain

Yahoo!の表示開始の75パーセンタイル値は1.433秒、表示完了の75パーセンタイル値は3.9秒です。スマートフォン向けWebサイトとしては、優秀な方だと思います。それでスコアが64点というのは、どうかなと思うのですが、如何でしょうか?

MSN

遅い時はYahoo!より遅いですが、全体の75%でYahoo!より高速なMSNはどうでしょうか?

f:id:takehora:20160613175900p:plain

MSNの表示開始の75パーセンタイル値は1.321秒、表示完了の75パーセンタイル値は2.814秒です。しかし、スコアは74点です。

Goo

f:id:takehora:20160613191022p:plain

Gooの表示開始の75パーセンタイル値は2.023秒、表示完了の75パーセンタイル値は4.829秒です。しかし、スコアはYahoo!やMSNより高い72点です。

Excite

f:id:takehora:20160613191255p:plain

Exciteの表示開始の75パーセンタイル値は1.539秒、表示完了の75パーセンタイル値は8.629秒です。スコアは46点です。

Infoseek

f:id:takehora:20160613191525p:plain

Infoseekの表示開始の75パーセンタイル値は1.320秒、表示完了の75パーセンタイル値は10.544秒です。Exciteより品質が悪いのですが、スコアはExciteよりも上で53点です。

どうしてこういう結果になるのか?

どうして、実際の計測値と乖離した評価になるのか、二つの理由が考えられます。

一つ目の理由として考えられるは、計測はしているが、海外からの計測だから、というのが考えられます。自分の持っているサイトでテストしてみたのですが、テストのボタンを押すと、海外からのアクセスが来ていました。

このサイト自体は、国内からの配信になっていますが、テストのためのアクセスは海外から来ているため、それで遅延して、この結果になっていると考えられます。

二つ目の理由として考えられるのは、計測はしていなくて、高速化のためのベストプラクティスに準拠しているかどうかだけをチェックしているから、という事です。

ベストプラクティスでは何故駄目なのか?

 「ベストプラクティスにどれだけ準拠しているかのチェックでも良いのではないか?」と思われる方もいるかもしれませんが、実際は、それでは高速化されません。

「AによってBになった」という事が分かったからといって、「BになるためにAをする」事が正しいとは証明されないからです。

そもそも、ベストプラクティスとは何でしょうか?

現在のWebサイトパフォーマンス高速化のためのベストプラクティスとは、様々な事象に対する解決策の集大成でしかありません。

f:id:takehora:20160613194039p:plain

もし、その問題となっている事象の原因が異なれば、その解決策では解決はできません。

例えば、画像が遅延の原因だとしましょう。そのための解決策は画像を最適化するというものです。

しかし、本当にそれで解決できるのでしょうか?

今まで、私が分析してきた事例を振り返ってみると、以下のような原因がありました。

NASやディスクをNFSマウントしている
NFSマウントは遅延の原因になる。NFSマウント以外の方法で接続してもらって解決。
WindowsのサーバでNTFSのディスクパーティション容量の8割までファイルを保存していた
NTFSのパーティションではある一定の割合以上使用まで使用すると遅延する。不要になったファイルを削除してもらって、空き領域を50%まで増やして高速化。
HTMLを動的に生成するためのディスクと画像配信のためのディスクが一緒
ディスクI/Oの競合が発生して、HTMLも画像も双方遅くなる。保存するディスクを分けたり、サーバ自体を分けることで高速化。

画像のファイルサイズの大きさを最適化する事は、効果が無いとは言いませんが、根本的な原因を追究しなければ、根本的な解決には至らないのです。

f:id:takehora:20160613193934p:plain

原因も調べずに、やったら良いということでやるのであれば、それは「健康法」と大差ありません。
「健康法」で病気は治るのか?という事を考えてみて下さい。
健康法で対処する事が、病気の原因と合致していれば病気は治癒するでしょう。
しかし、合致していなければ、病気は治癒しないですし、場合によっては病状が悪化して死に至ります。

エンジニアというのは、科学的なアプローチが求められる職業だと思います。

「こうすれば良いって聞いたから、こうしよう」では、高品質なソフトウェアやWebサイトを作り上げることはできません。

計測して、データを分析して、原因を突き止める。
面倒かもしれませんが、地道な調査が、確実な結果を齎します。

このGoogleの「Mobile Website Speed Testing Tool」は、「お手軽なマーケット教育用ツール」程度に捉えておいた方が良いと思います。

参考までに

自分の会社のWebサイトをスマートフォン対応にしてみました。

LTE回線での、かなりぎりぎりまで高速化できていると思います。

f:id:takehora:20160613201914p:plain

表示開始が75パーセンタイル値で1.321秒、表示完了が75パーセンタイル値で1.402秒です。

f:id:takehora:20160613202017p:plain

それでも、スコアは77点でした。

AWSのS3上に置いているので、この秒数なのですが、EC2にして計測してみると、あと100msは高速化できました。「100ms高速化するために、S3の値段からEC2の値段に…」と考えると、まぁ、このままでいいか、と思いました。