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

Webパフォーマンスについて記事を書いています。パフォーマンス管理は、品質管理です。ですから計測データを元に記事を書いてます。一緒に「品質の守護者」になりましょう!

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の値段に…」と考えると、まぁ、このままでいいか、と思いました。