サイトの速度

Stopwatch | By wwarby Flickr!

こんにちわ、あなたの@t32k、ごきげんいかがでしょう。みなさんはスマホWebアプリ作っていて、自分の作ったものは速いのか遅いのか気になりませんかね？僕は木に泣くりまくりすてぃです。

そうゆうわけなもんで、表示速度とか計測してみようって話になるじゃないですかー、まさかストップウォッチで計測しないとは思うんですけどー、一応どのようにスピードを計測、そのアプリの性能を評価すればよいのか一緒に考えてみましょう。

僕が昔、ゴメス・コンサルティング（現：コンピュウェア モーニングスター） のセミナーに行ってきた時の話ですが、ここの会社はサイトパフォーマンスの計測サービスを提供していて、計測で重要なのは『定期的かつ継続的かつ同手法にてパフォーマンス測定』と言っておられました。

サービスリリース時はスモールスタートなのでアプリもコンパクトですからスピードは速めかもしれません。しかし月日がたつにつれて、多くの機能が実装され、それに伴いサイトのスピードが落ちてはなんの意味もありません。計測した日がたまたま速かったのかもしれませんし、たまたま遅かったのかもしれませんので、定期的かつ継続的にかつ計測する必要性があります。また、1回目と2回目の測定条件（環境）が違ったりしては参考になりません。ましてや数ms単位でしのぎを削る我々にとってこの辺はシビアでかつ正確であってほしいわけです。

ですから、ストップウォッチや計測コードを毎回差し込むといった人間の手による対応ではコストが高すぎますし不正確な計測しか出来ません。そこですべてを自動化し計測する必要性があります。

すべてを自動化ってそんなことできるの？

大抵のサイトに実装されているであろうGoogle アナリティクスを使えば可能です。

上記Google アナリティクスのレポートから『平均表示時間』等を確認できます。『平均表示時間』と書いてありますが、英語メニューでは『Avg. Page Load Time』ですので、『平均読み込み時間』が適切かと思われます（ラベリングおかしい（●｀ε´●））

平均表示時間 - ページの読み込みにかかった平均時間（秒）

ga:avgPageLoadTime = (ga:pageLoadTime / ga:pageLoadSample) * 0.001 平均表示時間（秒）= ページの読み込みの合算値 (ミリ秒）÷ サンプル数 × 0.001

Site Speed - Dimensions & Metrics Reference 

と言った計算式で算出されております。これであればサイトの全ページを計測でき、なおかつ平均なので、ある程度ならした数値を得ることができます（外れ値は別途カスタムレポートとかで除外することもできます）し、パフォーマンス改善もPVの多いとこから対応したほうが効率的だということが理解できるでしょう。

[追記]　コメントに指摘されたように、値にばらつきがあるような場合（凹凸形状な分布）だとやはり、中央値を確認すべきなので、[分布]タブをクリックすれば、どの値の範囲に多いのか確認できます。

またディレクトリごとで読み込み時間の違いを確認したり、端末ごとでの読み込み時間を確認するといったことも可能でしょう。

さて、この読み込み時間ってのはどこから取ってきてるのかと言いますと、Navigation Timingという仕様を実装しているブラウザからです。ユーザーがページ遷移するとネットワークの接続、サーバーレスポンス、ブラウザ読み込みにかかった時間が自動的にブラウザに記録され、その情報をGAがサーバーに送ってるといった感じです。

これまでというか、一昔前まではそうゆうことを計測しようと思うと上記のようなコードを挿入して計測していた気がします。これをページの読み込み時間と定義してしまうのは、いささか問題があります。Aのページの読み込みを考えれば、当然Bとなど他のページから遷移したと想定され、Bのページのリンクを押してから、Aのベージの読み込み完了までが本来の意味での（体感的な）読み込み時間と考えるべきでしょう。つまり、上記のコードではネットワークやサーバーのやり取りの部分が考慮されてないことを意味します。またそもそもJavaScriptでの時間計測は不正確ということも懸念されます。

より体感に近い読み込み時間を考慮すれば上図のような流れを計測すべきです。このような計測をJavaScriptだけで行おうとするとやや複雑な処理を記述しなければなりません。そんなめんどくさいことしなくても計測できるようになったのが、Navigation timingです。

もう一度、GAのレポート（[コンテンツ] > [サイトの速度] > [ページ速度]）を見てみると、『平均表示時間』の以外にも様々な指標が確認できるでしょう。

  1. 平均リダイレクト時間（ページを読み込む前にリダイレクトにかかった平均時間。リダイレクトがなければ0になる）
  2. ドメインの平均ルックアップ時間（ページのDNS名前解決にかかった平均時間）
  3. サーバーの平均接続時間（サーバーとのTCPコネクション確立に要した平均時間）
  4. サーバーの平均応答時間（サーバーがユーザーリクエストに応答するまでの時間。ユーザーの所在地からサイトのサーバーにアクセスするネットワークの通信時間も含まれる）
  5. ページの平均ダウンロード時間（ ページ（のみ）のダウンロードにかかった時間）
[エクスプローラ]タブの[技術]にはネットワークとサーバーに関する指標がレポーティングされています。『平均表示時間』の大半がこの部分で占められていれば、フロントエンドエンジニアではなくサーバーサイドエンジニアに文句を言いましょう。

  1. 平均ドキュメントインタラクティブ時間（ドキュメントがパースされるのにかかった平均時間。このときDOMは完全に読み込まれてはいないが、ユーザー操作可能な状態。またユーザーの所在地からサイトのサーバーにアクセスするネットワークの通信時間も含まれる）
  2. 平均ドキュメントコンテンツ読み込み時間（ドキュメントがパースされDOMContentLoadedを実行するのにかかった平均時間。このときDOMは読み込まれているがCSSや画像などのリソースが読み込みが完了しているわけではない）
[エクスプローラ]タブの[DOM速度]にはドキュメント解析に関する指標がレポーティングされています。『平均表示時間』の大半がこの部分で占められていればDOMが複雑すぎるのでしょう。コーダーに文句を言いましょう。

平均ドキュメントインタラクティブ時間と平均ドキュメントコンテンツ読み込み時間はほぼ同義って思っていいでしょう（ここで差が出るケースがわからない）。

とりあえずこれらのレポートは特に手間を要することなくGAスニペットが挿入されていれば、サイトユーザーの1%のサンプリングレートで記録されるので、ほっといてもデータ溜まっていきます。1%じゃサイトの規模的に足りないって方は_setSiteSpeedSampleRate()を使えばサンプルレートを調整できます。

 

対応しているブラウザは？

さて、 このNavigation Timingに対応したブラウザってどんなもんなんでしょう。ヘルプには下記のように書いてありました。

サイトの速度のトラッキングは、HTML5 Navigation Timing インターフェース対応のブラウザか、Google ツールバーがインストールされたブラウザからの訪問に対してのみ行われます。該当する主なブラウザには、Chrome、Firefox 7 以降、Internet Explorer 9 以降、Android 4.0 以降のブラウザと、Google ツールバーがインストールされた Internet Explorer の以前のバージョンなどがあります。
ほうほう、Navigation Timingに対応してなくても、PCだとGoogleツールバー入れてたらいいんだね。って、俺の知りたいのはスマホだ、iOSだ！ということで。

Can I use…で見てみると、iOS全滅じゃん！Desktop Safariでさえ対応してないと見ると、Appleさんは対応する気がないんでしょうかね…(´・ω・`)

とはいえ、Android4.0以降がバージョン別シェア半数を超えたとかニュースで言っておりましたし、今後のモバイルの主流になっていくの当然であり、十分な量のデータサンプルを収集することも難なくできるでしょう。

 また、Android4.0以降であればパフォーマンスの観点からいってもiOSとひけをとりません（むしろ4.0のほうがいいくらい）なので、Android4.0で集められたGAレポートのデータを暫定的にiOSでもこのくらいの読み込み時間かなーと考えといても良いかなと個人的には考えています。

もうちょっと詳しく…

もうちょっと細かく、Navigation Timingの仕様を見てみましょう。上図は仕様書にも書いて有るNavigation Timingの概要です。なんかいっぱいタイミングがあってごちゃごちゃします。まぁこのように細かく分けることでどこがボトルネックか突き止めることができるってもんです。とはいえ覚えきれないので、もっと大雑把に考えたのが下図。

ブラウザー、ネットワーク、サーバーの登場人物は3人です。『読み込み時間』とひとくくりに言っても3つのカテゴリーに分けて考えることができます。つまり問題を整理して対応策を考えることできます。

さらに、ブラウザー、ネットワーク、サーバーで色分けし、先ほどのGAレポートの項目とNavigation Timingの項目を照らし合わせたのが下の図。

やっべーわかりやっしーちょーわかりやっしー。

とこのように、Google アナリティクスの『サイトの速度』を利用すれば、公正でかつ正確なサイトのパフォーマンス評価をすることが可能です。また、それに対する策も考えやすいといったように開発者にやさしい機能となっていますので、みなさんじゃんじゃん使ってみてください。

最後に地域が日本で、ブラウザーがAndroidのスマホ用のサイトの速度カスタムレポート作っときました。

最後にGAの『サイトの速度』レポートはできて日が浅く（そもそもNavigation Timing自体仕様が勧告でない）、データが集まりにくかったりかゆいところに手がとどかなかったりするのは致し方無いかないう印象です。もし、お金払ってでももっと正確なデータが欲しいという方は、Keynote Systemsのような有料の計測サービスを利用するのもひとつの手段かと思います。

参考