このテストの速度テストの評価を実際の計測データと比較して検証してみる
testmysite.thinkwithgoogle.com
を公開して、各所で話題になっています。
モバイルフレンドリーかどうかのテストには使えるのですが、スマートフォン向けWebサイトやデスクトップ向けWebサイトとしてのスピードの判定の参考にならないです。
その理由を以下に説明します。
日本のポータルサイトのパフォーマンス計測のデータと見比べてみる
さて、検証用データとして、日本のポータルサイトの計測データと見比べてみましょう。
今回、計測してみたのは、以下の5つのポータルサイトです。
- Yahoo!
- Goo
- Excite
- MSN
- Infoseek
計測条件
- NTTドコモのLTE回線を使用
- 電波強度は非常に良好
- 計測機器を設置して行う定点観測なので、基地局間の接続移動処理（ハンドオーバー）は発生しない
- 計測した場所は、首都圏の住宅街
- 計測頻度は15分に1回
- 計測期間は一週間
- 計測ツールには、Catchpointを使っています。Catchpointは、Googleを始めとして、欧米の企業がWebサイトパフォーマンスの品質管理のために使っているツールです。
計測結果
表示開始時間
表示開始時間とは、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秒ぐらいで表示が開始される」と言えるわけです。
| サイト名 | 平均 | 標準偏差 | IQR | 0% | 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回計測値があって、そこからエラーになったものを除いています。
数値だけを見ると全体像が把握できないので、箱ひげ図で表してみます。
Goo以外のサイトについては、計測全体の75%において、ほぼ安定した秒数で表示できている事が分かります。また、残りの25%については、サイトによって、かなりバラツキが出ています。
MSNは、一番遅い値（100%）が19074ms＝19秒を超えているので、遅い時には、表示開始速度が相当遅いという事になります。
表示完了時間
表示完了時間とは、W3C Navigation TimingのDocument Completeの時間を指しています。
理想の値は2秒ですが、LTE回線の場合は、相当頑張らないと2秒は無理です。ですので、3秒が現実的な目標値になります。
| サイト名 | 平均 | 標準偏差 | IQR | 0% | 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 |
表示完了時間のデータを見ると、サイト毎に相当に数値が違うのが分かります。
これを視覚的に分かりやすくするために、箱ひげ図にしてみました。
一番高速に表示完了を終えているのはMSNだと分かります。しかし、MSNは残りの25%がYahoo!より長く伸びていて、Yahoo!よりバラツキがあるのがわかります。
Mobile Website Speed Testing Toolの結果
Yahoo!
Yahoo!は、以下のような結果になります。
Yahoo!の表示開始の75パーセンタイル値は1.433秒、表示完了の75パーセンタイル値は3.9秒です。スマートフォン向けWebサイトとしては、優秀な方だと思います。それでスコアが64点というのは、どうかなと思うのですが、如何でしょうか？
MSN
遅い時はYahoo!より遅いですが、全体の75%でYahoo!より高速なMSNはどうでしょうか？
MSNの表示開始の75パーセンタイル値は1.321秒、表示完了の75パーセンタイル値は2.814秒です。しかし、スコアは74点です。
Goo
Gooの表示開始の75パーセンタイル値は2.023秒、表示完了の75パーセンタイル値は4.829秒です。しかし、スコアはYahoo!やMSNより高い72点です。
Excite
Exciteの表示開始の75パーセンタイル値は1.539秒、表示完了の75パーセンタイル値は8.629秒です。スコアは46点です。
Infoseek
Infoseekの表示開始の75パーセンタイル値は1.320秒、表示完了の75パーセンタイル値は10.544秒です。Exciteより品質が悪いのですが、スコアはExciteよりも上で53点です。
どうしてこういう結果になるのか?
どうして、実際の計測値と乖離した評価になるのか、二つの理由が考えられます。
一つ目の理由として考えられるは、計測はしているが、海外からの計測だから、というのが考えられます。自分の持っているサイトでテストしてみたのですが、テストのボタンを押すと、海外からのアクセスが来ていました。
このサイト自体は、国内からの配信になっていますが、テストのためのアクセスは海外から来ているため、それで遅延して、この結果になっていると考えられます。
二つ目の理由として考えられるのは、計測はしていなくて、高速化のためのベストプラクティスに準拠しているかどうかだけをチェックしているから、という事です。
ベストプラクティスでは何故駄目なのか?
「ベストプラクティスにどれだけ準拠しているかのチェックでも良いのではないか？」と思われる方もいるかもしれませんが、実際は、それでは高速化されません。
「AによってBになった」という事が分かったからといって、「BになるためにAをする」事が正しいとは証明されないからです。
そもそも、ベストプラクティスとは何でしょうか?
現在のWebサイトパフォーマンス高速化のためのベストプラクティスとは、様々な事象に対する解決策の集大成でしかありません。
もし、その問題となっている事象の原因が異なれば、その解決策では解決はできません。
例えば、画像が遅延の原因だとしましょう。そのための解決策は画像を最適化するというものです。
しかし、本当にそれで解決できるのでしょうか？
今まで、私が分析してきた事例を振り返ってみると、以下のような原因がありました。
- NASやディスクをNFSマウントしている
- NFSマウントは遅延の原因になる。NFSマウント以外の方法で接続してもらって解決。
- WindowsのサーバでNTFSのディスクパーティション容量の8割までファイルを保存していた
- NTFSのパーティションではある一定の割合以上使用まで使用すると遅延する。不要になったファイルを削除してもらって、空き領域を50％まで増やして高速化。
- HTMLを動的に生成するためのディスクと画像配信のためのディスクが一緒
- ディスクI/Oの競合が発生して、HTMLも画像も双方遅くなる。保存するディスクを分けたり、サーバ自体を分けることで高速化。
画像のファイルサイズの大きさを最適化する事は、効果が無いとは言いませんが、根本的な原因を追究しなければ、根本的な解決には至らないのです。
原因も調べずに、やったら良いということでやるのであれば、それは「健康法」と大差ありません。
「健康法」で病気は治るのか?という事を考えてみて下さい。
健康法で対処する事が、病気の原因と合致していれば病気は治癒するでしょう。
しかし、合致していなければ、病気は治癒しないですし、場合によっては病状が悪化して死に至ります。
エンジニアというのは、科学的なアプローチが求められる職業だと思います。
「こうすれば良いって聞いたから、こうしよう」では、高品質なソフトウェアやWebサイトを作り上げることはできません。
計測して、データを分析して、原因を突き止める。
面倒かもしれませんが、地道な調査が、確実な結果を齎します。
このGoogleの「Mobile Website Speed Testing Tool」は、「お手軽なマーケット教育用ツール」程度に捉えておいた方が良いと思います。
参考までに
自分の会社のWebサイトをスマートフォン対応にしてみました。
LTE回線での、かなりぎりぎりまで高速化できていると思います。
表示開始が75パーセンタイル値で1.321秒、表示完了が75パーセンタイル値で1.402秒です。
それでも、スコアは77点でした。
AWSのS3上に置いているので、この秒数なのですが、EC2にして計測してみると、あと100msは高速化できました。「100ms高速化するために、S3の値段からEC2の値段に…」と考えると、まぁ、このままでいいか、と思いました。