Webサイトパフォーマンス計測の現状の俯瞰
HTML5 Advent Calendarに参加しまして、12月1日担当だったのですが、遅れに遅れてクリスマス当日の掲載となりました。申し訳ございません。
html5jにて、パフォーマンス部の創設を担当することもあり、Webパフォーマンス計測に関することを俯瞰できる記事を書いてみました。これを読んで頂ければ、凡そのWebパフォーマンス計測に関する現在までの流れについて、ご理解頂けると思います。
Webサイトのパフォーマンスを計測する事の意義
Webサイトのパフォーマンス(表示速度)が速い方が良いというのは、殆どの方に同意頂ける事だと思います。日常生活の中でWebサイトやスマートフォンサイトを見るのが一般的な事となり、それ故にWebブラウジングをしていて、いわゆる「重い」サイトにイライラする経験は誰しもあると思います。
競合のサービスや商品を提供しているサイト間で、提供する「価値」に特別に違いが無ければ、「軽い」サイト、「速い」サイトの方にユーザが流れるのは、自然な事です。多くの企業の経営者、マネジメント層が、自社と競合他社との差別化に四苦八苦している今日、Webサイトの高速化はもっと着目されてしかるべきビジネス上の課題です。
具体的な数値としてのパフォーマンスの影響としては、以下のような調査結果があります。
Aberdeen Groupの調査結果
表示速度が1秒遅くなる毎に、
- ページビューが11%低下
- コンバージョン率が7%低下
- 顧客満足度が16%低下
Forrester Researchの調査結果
- Webサイトのパフォーマンスに不満を感じた場合、79%のユーザはそのサイトで二度とショッピングをしない
- 52%のユーザは、Webサイトのパフォーマンスがサイト利用に際して重要な要素だと考えている
- Webサイトでのショッピング中に買い物を中断したユーザの33%は、サイトのパフォーマンスに不満を感じている
- 多くのユーザはページの読み込みにかかる時間として2秒以内を期待しており、40%以上のユーザは4秒以上待てない
Yahoo! のパフォーマンス担当Steve Soudersの調査報告
- MicrosoftのBingでは、2秒のレスポンスタイム低下はユーザあたり4.3%の売上低下を招く
- Googleでは、レスポンスタイムが0.4秒遅くなると、ユーザあたりの検索回数が0.59%減少する
- AOLでは、ユーザが読み込み時間の速いページを経験すると、訪問回数あたりのページビューが50%増加する
- アメリカの価格比較ショッピングサイトShopzillaでは、ページ読み込み時間を7秒から2秒に短縮した結果、売上が7~12%増加
日本の事例
- 某大手家電量販店のサイトで、サイトリニューアル後に、Web配信の遅延が生じて、表示速度が20~50秒かかり、その対処に3日かかった結果、2億5千万円の損失
私が関わった案件の内、いくつかの例
- クレジットカード会社のスマートフォンサイトを、トップページが平均40秒から平均5秒まで高速化することで、カード申込数が30%アップ
- 家電量販店のデスクトップサイトで、トップページが平均10秒を平均3秒まで高速化することで、アクセス数が40%増
- 新聞社のデスクトップサイトで、トップページが平均10秒かかっていたのを、平均3秒まで高速化することで、アクセス数が過去最高に。苦情や問い合わせの数が激減。
Webサイトのパフォーマンス計測の歴史
アメリカにおけるWebサイトのパフォーマンス計測
Webサイトのパフォーマンス計測の歴史は、1995年に遡ります。この年、Keynote Systemsが創業されて、世界で初めてWebサイトの計測サービスを始めました。その後、1999年にWebMetricsが設立されてサービスを開始、2001年にはB2B、B2Cのインターネット調査会社のGomez AdvisorsがGomezを設立して計測サービスを開始します。2009年にはGridataがSiteAlertというサービス名でパフォーマンス計測のサービスを開始しています。
これらの計測サービスは、synthetic monitoring(合成監視)と呼ばれます。あたかも一人のユーザであるように、一定間隔毎にWebブラウザを自動操作して対象サイトにアクセスして、Webページの1ページに含まれるファイル全てのダウンロードの秒数を定常的に計測します。
2010年には、W3C Web Performance Working Groupが創設され、Webサイトのパフォーマンス計測についての測定基準の標準化作業が開始されました。
何故、測定基準の標準化作業が始まったかというと、ダウンロード時間を計測するのでは、実際のユーザが体験するブラウジングの速度と合致しないからなのです。
ユーザ視点からすれば、ダウンロード時間が速いか・遅いかより、速く表示されるかどうか、すぐに使える状態になるかどうかの方が重要ですし、感覚的にもしっくりきます。サイトの開発者からすれば、ダウンロードが遅いとしても、表示を速くさせたり、スクロールダウンしたり、メニューを選んだりと、利用可能な状態に素早くさせる事の方が、ファイル全てのダウンロードを高速化するより、ビジネス上のメリットがあります。こちらの測定基準の詳細については、別の機会に書きたいと思います。
この分野における技術カンファレンスとしては、"Velocity"が2007年からO'Reillyによって開催されていて、今年で6年目を迎えています。徐々にVelocityの規模は拡大し、現在では、アメリカのサンタクララだけでなく、ニューヨーク、ロンドン、北京でも開催されており、3日間に亘る大規模なイベントに成長しました。来年には、新たに開催地としてスペインのバルセロナが加わっています。
日本におけるWebサイトのパフォーマンス計測
日本には、421万社の企業があるそうです。(2006年、中小企業庁)
しかし、パフォーマンス計測を「定常的」に行っている企業は、その内の200社にも及びません。
アクセスログ解析であれば、今ではWebに関係する人々の間では、ごく一般的な事となっています。日本でのアクセスログ解析の普及には、アクセスログ解析ソフトのUrchinが日本に上陸して以来、10年ぐらいかかっています。パフォーマンス計測も、日本で普及するには、もしかしたら、同様に10年ぐらいかかるのかもしれません。
アメリカと較べて、これほどまでにWebサイトのパフォーマンス計測サービスが日本で普及しなかった理由は4つ挙げられます。
- 日本のインターネット環境、インフラが非常に高速であった
- 当時は重いコンテンツの配信をしていなかった
- 海外に対してのコンテンツ配信やSaaSの提供などが、ほぼ皆無
- 統計学、品質管理の必要性に対する認識の欠如
しかし、2005年ぐらいから、特に大規模なアクセスが発生するサイトにおいてWebサイトパフォーマンスが注目されるようになってきました。次の表を見て下さい。
2000年末 | 2001年末 | 2002年末 | 2003年末 | 2004年末 | 2005年末 | 2006年末 | 2007年末 | 2008年末 | 2009年末 | 2010年末 | 2011年末 | 2012年末 | |
ブロードバンド回線※2 | 6.8 | 14.9 | 29.6 | 47.8 | 62.0 | 65.0 | 67.9 | 67.6 | 73.4 | 76.8 | 77.9 | 81.9 | 79.2 |
DSL回線 | 0.3 | 7.9 | 18.7 | 27.2 | 39.2 | 34.2 | 27.7 | 18.9 | 17.3 | 17.1 | 11.7 | 12.9 | 8.9 |
CATV回線 | 6.5 | 6.5 | 9.2 | 15.1 | 15.5 | 16.1 | 12.5 | 16.6 | 17.1 | 18.5 | 13.7 | 15.5 | 15.9 |
光回線(FTTH回線) | - | 0.5 | 1.4 | 5.4 | 6.1 | 14.8 | 27.2 | 31.3 | 39.0 | 41.1 | 52.2 | 52.3 | 50.5 |
第3世代携帯電話回線※3 | - | - | - | - | 1.2 | 1.3 | 1.8 | 2.4 | 4.6 | 3.4 | 2.7 | 7.2 | 8.5 |
固定無線回線(FWA) | - | - | 0.7 | 1.0 | 1.3 | 0.5 | 1.7 | 0.7 | 0.8 | 0.7 | 1.0 | 0.9 | 1.4 |
BWAアクセスサービス | - | - | - | - | - | - | - | - | - | 0.4 | 0.7 | 0.8 | 0.3 |
LTE | - | - | - | - | - | - | - | - | - | - | - | 0.5 | 5.0 |
電話回線(ダイヤルアップ) | 55.4 | 47.2 | 44.9 | 30.2 | 20.4 | 16.4 | 17.5 | 11.4 | 9.4 | 9.0 | 7.5 | 6.7 | 11.6 |
ISDN(常時接続) | 34.0 | 24.6 | 16.8 | 13.9 | 13.3 | 14.8 | 14.9 | 13.7 | 10.0 | 9.3 | 8.3 | 5.6 | 5.8 |
ISDN(非常時接続) | 11.2 | 8.2 | 5.1 | 4.6 | 3.9 | 3.6 | 2.5 | 2.2 | 1.3 | 1.2 | 0.8 | ||
携帯電話回線(第3世代は除く)※3 | 11.5 | 20.9 | 7.4 | 6.6 | 5.8 | 2.7 | 1.5 | 2.0 | 4.5 | 4.4 | 5.5 | 8.8 | 7.5 |
PHS回線※3 | 3.2 | 2.6 | 3.7 | 2.0 | 2.5 | 1.9 | 0.8 | 0.7 | 0.5 | 0.3 | 1.9 | 1.4 |
単位は% ※1
- ※1 複数回答であり、上記以外の選択肢もあるため、各年の合計が100とは一致しないこともある
- ※2 ブロードバンド回線 :光回線(FTTH回線)(2001年から)、DSL回線、ケーブルテレビ回線、固定無線回線(FWA)、第3世代携帯電話回線(2004年から)、BWAアクセスサービス(2009年から)、LTE(2011年から)
- ※3 携帯電話回線及びPHS回線は、パソコンに接続して使う場合のみ、それぞれの端末のみでインターネットに接続する場合は含まない
2005年~2007年の3年間で、光回線の利用者率が、ADSLの利用者率とちょうど入れ替わっているのがわかるでしょう。
ADSLから光回線へと一般のユーザの接続回線が移行し、コンテンツもリッチになり、インターネット経由での動画視聴のような大規模なトラフィックの発生が、日本のIX(Internet Exchange point:複数のインターネットサービスプロバイダや学術ネットワークを相互に接続するインターネット上の相互接続ポイント)を逼迫するようになり、Webサイトの配信遅延が発生するようになったのです。2005~2006年にかけて、「ネットワークインフラただ乗り論争」も勃発しました。
ここで俄に着目を浴びたのが、AkamaiやCDNetworks、LimelightといったCDN(Contents Delivery Network)サービスです。当時、痛烈な批判を浴びた企業は、CDNを使って動画を配信することにより、IXへの負荷を減少させ批判を躱しました。
この時期のCDN利用目的は、「高速化」よりは負荷分散によって「遅延を防ぐ」ことが目的でした。
「ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール」の刊行
Yahoo!のパフォーマンス担当責任者のSteve Sounders氏が2007年に執筆・刊行した「High Performance Web sites」の日本語訳「ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール」が、2008年にオライリー・ジャパンより出版されました。これはWebサイトパフォーマンスについて考察した初めての本であり、日本でも一部のエンジニアの注目を浴びます。
その後、2009年に「Even Faster Web sites」が刊行され、2010年に日本語訳「続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス」がオライリー・ジャパンより出版されました。
現在、Web上にWebサイトの高速化手法として記事になっている殆どは、この2冊の本の内容がベースになっています。
注意頂きたいのは、この本の原書が刊行された2007年より10年以上前から、アメリカの著名な企業のWebサイトの多くで、定常的な計測・監視が行われていたという点です。
Steve Soudersの著書は、日本のエンジニアに対してWebサイトの高速化手法を啓蒙するという点では役立ったものの、計測の重要性の認識については却って低下させてしまう結果を齎しました。
殆どのエンジニアにとって、インターネットは概念は理解していても実態は見えないブラックボックスであり、日々、インターネットを構成しているネットワークやその上でやり取りされるトラフィックの状況が変わっているということはわからないです。従って、Steve Soudersの著書で紹介された高速化手法を適用すれば、サイトの高速化は成されたという誤った認識を普及させてしまいました。
また、FirebugやGoogle PageSpeed、YSlowの普及も、本来の統計学に基づく品質管理の概念の普及の妨げとなってしまいました。
「自分が見て速い」から「他人が見ても速い」とは限らない
何故、FirebugやGoogle PageSpeed、YSlowを使って高速化の指標とする事が問題なのでしょうか? それは、Webサイト制作を担当する人が、時折、これらのツールを使ってパフォーマンスの状態を見て「速い」と判断したとしても、それが全てのユーザにとって、また全ての時間帯において「速い」とは限らないからです。
Webサイトのパフォーマンス管理は、Webサイトの品質管理と言えます。そこで、実際のモノづくり、製造業に当て嵌めてみましょう。
例えば、エンジニアの皆さんの中には、AppleのMacBook ProやMacBook Air、iPhone、iPadがお好きな方は数多くいらっしゃるでしょう。
もし、皆さんが購入されたMacBook Airが手元に届いて、喜びに満ちて「開封の儀」を執り行い、使ってみたら不具合が発生したとしましょう。もちろん、購入した実店舗のApple Storeなり、オンラインショッピングの問い合わせ窓口に交換や修理を依頼しますよね。そこで、こんな対応をされたらどう思いますか?
「こちらの手元にあるMacBook Airは正常に動いているので、お客様のMacBook Airも問題ないはずです。」
きっと、「は? 何を馬鹿な事を言ってるんだ? こちらの手元にあるMacBook Airがおかしいって話をしてるのに、何で、そちらの手元にあるのが正常だから、こっちも正常だって言えるんだ?」と怒りが沸き起こるのではないでしょうか?
しかし、今の日本のエンジニアは、Webのパフォーマンス分析において、FirebugやGoogle PageSpeedなどのツールしか使っていないとしたら、これと同じことをしているのです。
品質管理
インターネットに対する幻想
MacBook Airの話は当然だけど、Webサイトのパフォーマンスについて、それと同じだというのは納得できませんか? もし、納得できないとしたら、それはどうしてでしょう? もしかしたら、以下のように思っているからではないでしょうか?
「ソフトウェアというのは、製造業のモノづくりとは違って、設計やコーディングのバグはあったとしても、製造過程におけるミスというのは発生しない。100%コピーできるんだ。自分の環境で問題が発生していなければ、ユーザの環境で問題が発生するわけがないじゃないか!」
これは本当でしょうか?
ソフトウェアを開発して、CD-ROMやDVD-ROMに焼いて、それを販売したり、ユーザに配布していた頃は、その通りだったでしょう。しかし、インターネット上でWebのコンテンツやWeb ApplicationをSaaSと称して提供する今日において、この認識は正しいでしょうか?
インターネット上において、Webでコンテンツやサービスを提供するという事は、我々は「完成品」ではなく、「半製品」もしくは「部品」を提供しているという認識に改める必要があります。
それは、HTMLやCSS、JavaScript、Flash、画像などの「Webページ」を構成するファイルです。
それらの「パーツ」が、インターネットという名のベルトコンベアを通って、ユーザのPCやタブレット、スマートフォンといった端末へと届き、その上で稼働するWebブラウザによってデータ処理されて「組み立て」られて表示されるのです。
つまり、我々エンジニアは、個々の「部品」については品質の担保をすることが出来ても、ユーザの端末上で仕上がった「完成品」については品質の担保できません。それは何故かというと、インターネットの通信状況を我々はコントロールできないからです。
インターネットは、企業や大学、ISPなどのネットワークの複合体であるという事を思い出して下さい。この世の中に、インターネット全体をリアルタイムで管理している人などいません。BGP(Border Gateway Protocol)によって接続性が保持されているに過ぎません。インターネットで通信するということは、所有者の異なる複数のネットワーク間で、データをバケツリレーしているという事なのです。
またISPによっても、パフォーマンスや、通信状況は異なります。携帯会社の通信速度状況がTVや雑誌、Webで話題になり、マーケティング会社も頻繁にデータを発表しています。携帯網の通信速度状況は携帯キャリアによって異なるのに、どうしてISPの通信速度状況は変わらないと思うのでしょうか?
それは、「見える化」されているかどうかの違いだと思います。携帯網の通信速度については、頻繁に速度データが雑誌やWeb上で発表されています。(計測の仕方に問題がありますが、それは脇においておきます。)しかし、ISPについては、通信速度の状況がマスコミなどによって「見える化」されていません。各ISPは、各々のネットワーク内の状況しか見ていません。そして、現在のネットワーク状況をリアルタイムで公開・発表するということはしていません。
インターネット全体のパフォーマンス状況は、ほんの僅かの限られた人たち、例えば、世界のWebトラフィックの15~30%を配信しているというAkamaiや、世界最大規模の計測拠点を持つKeynote Systemsのような企業のNOC(Network Operation Center)にいる人たちにしかわからない事で、ISPによってパフォーマンスが違うと認識できないとしても、それは仕方の無い事かもしれません。
部品自体は担保できても、ベルトコンベアの動作状況がコントロールできないならば、どうして「完成品」の品質保証ができるでしょうか? もしかしたら、ユーザの端末に届いていない「部品」があるかもしれないのに。
遅延を引き起こすサードパーティコンテンツ
昨今のWebサイトでは、自社ドメインからのコンテンツだけで構成されているという事が珍しくなってしまいました。例えば、多くのサイトでは、アクセス解析ツールとしてGoogle Analyticsを使っていますから、そのJavaScriptは入っています。それ以外であれば、SiteCatalyst、WebTrendsなど。
広告を貼り付けている場合は、広告配信会社のドメイン配下のJavaScriptが入っています。
Facebookの「いいね!」ボタンや、Twitterの「ツイート」ボタン、Google+、はてな、mixi、最近ではLINEでシェアするためのボタンなど、Webページはソーシャルメディア真っ盛りです。
Webサイトを運営していれば、もちろん、自社ドメインの配信について、ちゃんと稼働しているかどうかサーバ監視をされていることでしょう。しかし、自社ドメイン以外のコンテンツ、サードパーティコンテンツについてはどうでしょうか?
有名な企業のコンテンツだから大丈夫!って思って、配信状況は監視していないとしたら、それは大きな間違いです。というのも、現在のWebサイトパフォーマンスの遅延要因は、サードパーティコンテンツが大きな割合を占めているからです。
そして、サードパーティコンテンツの遅延は昼間ではなく、アクセスの集中する夜の21:00~24:00にかけて発生します。その時間帯に、会社でFirebugなどのツールでパフォーマンス計測・分析をされていますか? もしその時間帯に計測していなければ、サードパーティコンテンツの影響を見逃す結果となるでしょう。
自社ドメインから配信していないため、エンジニアにとってはサードパーティコンテンツは、コントロール不可能なコンテンツなのです。
品質管理
従来のソフトウェア開発と異なり、インターネットを経由してコンテンツやサービスを配信するWebサイトの開発は、上記の通り、構成するファイルが100%、ユーザに届くことが保証できないというのはお分かり頂けたと思います。
インストーラーファイルのFTP・HTTPダウンロードであれば、TCPレベルでのパケット保証がありますし、ダウンロード完了後にハッシュ値による同一性チェックをかければ、100%完全コピーされたことを担保でき、端末にインストールしてしまえば、ソフトウェアの稼働上、必要な基本ファイルが欠けるという事はほぼありません。
しかし、Webページの場合は、アクセスの都度、複数の構成ファイルをダウンロードして、ブラウザ上で組み立てるのです。そして、そのダウンロードが適切な時間内で終わること、またダウンロード自体が完全になされる事は保証されないのです。
それは、インターネットを構成するネットワークの仕組み上、またWebの仕組み上、仕方のない事です。
サードパーティコンテンツを組み込んだり、様々なWeb APIを利用してマッシュアップするのであれば、更に混沌として、パフォーマンスと可用性のコントロールが効かなくなります。
自社ドメインのサーバの稼働状況を監視しているだけでは、ユーザに、迅速にコンテンツやサービスを提供しているかどうかを確認することはできません。
それでは、どうすれば、それを確認できるでしょうか?
先程のMacBook Airの喩え話で考えてみましょう。あなたの手元に届いたMacBook Airは、MacBook Airの設計図に基いて生産された、一つの生産物に過ぎません。そして、サポートの人の手元にあるMacBook Airも、同様に一つの生産物です。同じ設計図から生産されたにも関わらず、不具合を持つ生産物が生まれてしまうのは、設計したものを物理的に全く同一に製造するという事は難しいからです。品質にバラつきが出てしまうのです。
これと同様に、あなたの端末上でFirebugなどのツールで確認したパフォーマンス結果は、HTML、CSS、JavaScriptという設計図に基いて、あなたの端末上で「生産」された、その時点における一つの「生産物」の表示性能をチェックしたに過ぎません。その性能が、他の端末上でも、他のISPでも、他の時間帯や曜日においても、同等になるかどうかは話が別なのです。
生産において、「原料の投入量から期待される生産量に対して、実際に得られた製品生産数比率」のことを歩留りと言います。そして、製品生産数は、もちろん、きちんと動作する、期待された性能値を発揮する「良品」を数えます。そうでなければ、「不良品」です。品質のバラつきを抑えるということは、歩留りを良くするという事なのです。
ですから、モノを作る製造業においては、いかに歩留りを向上させるかを課題とした生産工程や生産手法の改善活動(QC活動)が行われます。その活動の中で発見された問題について、設計を変えた方が良い場合もあり、設計図へ反映していきます。このように製造業においては、設計と製造、両方の面から品質の向上を図ります。
翻って、ソフトウェア開発では、品質管理はどのように行われているでしょうか?
現在、ソフトウェア品質のテンプレートとして存在しているのは、能力成熟度モデル統合 (Capability Maturity Model Integration, CMMI)が有名です。しかし、CMMIは、「設計」に焦点を当てており、「製造」に対するものではありません。何故なら、ソフトウェア開発においては、上記に述べたように「製造」のフェーズが存在しなかったからです。
しかし、Webにおいては、「生産」のフェーズが存在します。それも、サーバサイドではなく、ユーザの端末上、クライアントサイドで発生するのです。
長らくソフトウェア業界は、建設業から学び、その各種手法を適用してきました。業界構造は、建設業と全くそっくりです。プロジェクト管理手法は建設業で培われたPMBOKを、見積り手法は積算管理を適用しています。ソフトウェア開発が、その金額と規模において「重厚長大」であったため、建設業のモデルはしっくりと馴染んだのですが、開発の規模や期間等がどんどん小さくなるにつれて、建設業のモデルの適用は限界に達しています。今こそ、製造業のモデルを適用すべき段階だと、私は思います。例えば、ソフトウェア開発においては、アジャイルプロセスへとシフトしており、そのやり方は製造業の商品開発にそっくりですよね。
製造業において品質のチェックをどのようにしているのかを見れば、Webサイトのパフォーマンス管理についてもヒントが得られます。
生産された生産品を全て検査する(全数調査)すれば、もちろん一番良いのかもしれませんが、ロボットで全ての生産品チェックをするにしても、チェックできる項目に限りがあります。人の手を介して全てをチェックするとしたら、莫大な費用と時間がかかってしまいます。そこで、製造業では、ランダムに生産品を抜き出して、品質をチェックします。
実験計画法
戦前、また戦後直後の日本の製造業の生産物の品質は、あまり褒められたものではありませんでした。現在の我々からすると信じられないでしょうが、日本製品は、「安かろう悪かろう」と世界から認知されていました。
1950年、ウィリアム・エドワーズ・デミング博士が、進駐軍の依頼で、日本の国勢調査の計画立案のために来日します。当時の日本科学技術連盟は、数理物理学者としてアメリカ農務省に勤務し、統計アドバイザーとしてアメリカ国勢調査局に勤務、その後ニューヨーク大学経営大学院で統計学の教授を務めたデミング博士に、統計学に基づく品質管理技術を学ぶために講義をお願いしたのです。
デミング博士は、1950年6月から8月の2ヶ月、数百名の技術者、経営者、学者に統計的プロセス制御と品質の概念の講義を行い、これが製造業の間で普及して、今日の高品質製品を作り上げる日本の製造業の土台となりました。
統計学において、計測の仕方は既に定まっています。統計学の大家である、サー・ロナルド・エイルマー・フィッシャー博士が、1920年代に「実験計画法」として確立しています。現在のあらゆる統計調査は、基本的には、この実験計画法に基いて行われます。製造業における品質検査も、この実験計画法を使います。
実験計画法には、以下の3つの原則があります。
- 局所管理化
- 反復
- 無作為化(ランダム化)
Webサイトパフォーマンス計測においては、以下のような適用となります。
- 局所管理化~計測された値に影響を及ぼす変数の数をできるだけ減らす。
端末のスペックの統一、計測端末上で同時に他のアプリケーションを起動しない、ISP毎に同等の帯域回線で計測する。 - 反復~時間帯や曜日、時節によって、Webサイトへのアクセス数は異なり、またインターネットの状況も異なります。従ってパフォーマンスの値は、決して特定の数値に固定はせず、速い場合と遅い場合という「幅」を持ちます。その幅は、殆どが非対称分布となります。反復計測を行い、十分なサンプル数を得られなければ、データの信憑性が担保できなくなります。
パフォーマンス計測値のヒストグラムと非対称分布図(1時間毎の計測で2週間。合計で、780計測点) - 無作為化~例えば、9:00、9:05、9:10というように、きっちりと5分刻みで計測すると、その計測は「パターン」と化してしまい、9:00と9:05の間のパフォーマンス状況は決して知り得ないことになります。5分毎の計測を行いたいのであれば、時刻のきりの良さに基いて計測するのではなく、ランダムに3~7分と幅を持たせて、おおよそ5分間隔となるように計測することで、総和として計測する「時点」の数が増え、データの代表性が担保されます。
この「実験計画法」に基いて、きちんと調査設計された上で計測されたデータは、変数が明確、且つ、限定されているため、信頼性、妥当性、関連性が高く、実際に「使える」データという意味で、Actionable Data(実行可能データ)と呼びます。
何が、Actionable Dataではないかについては、こちらのブログ記事(What data is NOT actionable? An attempt to further define actionable data.)が参考になります。
Real User Monitoring (RUM)
2012年後半から2013年前半にかけて、Webパフォーマンス計測に新たな潮流が生まれました。Real User Monitoring(RUM)です。
RUMは、synthetic monitoringとは異なり、実際の全てのユーザがアクセスした際のパフォーマンス数値を取得・集計します。今、流行している言葉で言うと、データの大きさからBig Dataに属します。
既存のパフォーマンス計測会社も、新規に事業を立ち上げた企業も、競ってRUMのサービスを打ち出している背景には、モダンブラウザがW3CのNavigation Timeを取得できるAPIを実装したことが関係しています。また、データを取得してサーバに送るためのJavaScriptライブラリであるboomerangがBSDライセンスの下、USのYahoo!のExceptional Performanceチームによって開発され、オープンソースで公開されていることも大きな要因です。つまり、お金をかけなくても、簡単にパフォーマンスデータを取得できる環境が整ったので、事業化しやすいわけです。
RUMの問題点
一見、便利で、有用に思えるRUMですが、RUMのデータだけでは、実際には大して役に立ちません。何故かと言うと、計測環境であるユーザ環境が統一されておらず、計測値の正確に見極めることが困難だからです。もっと砕けて言えば、たとえ、ユーザの表示速度の平均が4秒とわかったところで、何が原因で4秒であるかは正確にはわからないという事です。
50mを何秒で走れるかで例えてみましょう。
Aさんは10秒、Bさんは8秒、Cさんは11秒だとします。秒数だけ見れば、Bさんが一番速く8秒です。平均を出すと、(10+8+11) / 3 ≒ 9.6秒です。
しかし、実は、Aさんは自転車で50mを走り、Bさんはバイクで50mを走り、Cさんは自分の脚で50mを走った結果だとしたらどうでしょう? 単純にこの数値を比べられますか? そして、単純に平均して良いのでしょうか? これらの数値から、何が出来るでしょうか?
そう、RUMは、ユーザの端末のCPUやメモリ、SDDやHDDのスペック、回線速度やネットワーク環境、同時起動しているアプリケーションの有無など、計測の環境が統一されていない計測データなのです。
取得できるからと言って、使えるとは限らないのです。
これは、RUMのデータに関わらず、Big Data全般に当てはまる事です。大量のデータ(統計学では、データが大きいと云います)があっても、変数が明確でなければ、正確な分析のしようがありません。データがあって分析するのではなく、目的があって調査の設計を行い、きちんとした手法でデータを得ることが大事なのです。
変数が明確ではない大きなデータを分析するのに、現在の統計学では、明確な解を持ちません。このあたりについては、こちらのページが参考になります。
もう一つの問題点は、データが偏るという点です。JavaScriptを使って、値を取得するわけですから、そのJavaScriptの動作が遅延してしまってデータがサーバに送られる前にページを閉じられてしまっては、計測値を取得できません。
これは、RUMに限らず、JavaScriptを使ったアクセス解析にも当てはまります。
Google Analyticsを使っている方は多いと思いますが、そのJavaScriptの遅延やタイムアウトにより、どれだけデータを取得し損ねているかを知ったら、きっと驚かれることでしょう。
さて、そのようなRUMのデータは、きちんとした基準となる「モノサシ」があれば、使えるようになります。それが、synthetic monitoringの計測データです。
synthetic monitoringで4~6秒で、RUMデータで6~12秒のばらつきであるならば、エンドユーザの環境では、synthetic monitoringの値の1.5~2倍の遅延になるという、およその目安がつきます。(1.5~2倍という幅の中に、端末スペックや、回線などの変数が影響を及ぼしているのでしょう)
もし、ユーザに2秒~3秒でブラウジングできるようにしたいのであれば、synthetic monitoringの値で1.3~1.5秒以内に表示できるようにする必要があります。そして、synthetic monitoringであれば、ピンポイントで、パフォーマンスの遅延要因を見つけ出すことが可能であるため、実際に改善を行うことが「実行可能」なのです。
まとめ
ここまで読んでいただいて、Webパフォーマンス計測の重要性や、どのように計測すべきか、何が問題なのか、理解の一助になれば幸いです。
パフォーマンス計測のような定量調査を行うことで、自分たちが作って納品したサイトの品質が明確にわかるため、計測に対して否定的なSIerや開発会社は少なからずあります。
ユーザ企業であっても、定常的に計測する必要がどこにあるのかを理解頂けない事は多いです。「繁忙期だけ計測すればいいじゃないか」「リニューアルの前後だけ計測すればいいじゃないか」と言われることが多々あります。
Big Dataと騒がれてはいますが、未だに多くの人にとっては、統計学は馴染みのない学問です。しかし、統計学を理解しなければ、品質管理はできません。
多くの人々にとって、Webサイトのパフォーマンスとは、イメージ的に「静的」なもので、例えWebページの内容を変えないとしても、刻一刻と変わりゆくことは、実際に計測し続けなければ認識し難いとは思います。
しかし、今後ますますHTML5が、様々な端末、分野において利用されていく事を考えれば、表示速度や操作可能になる速度というのは、開発・運営上、重要な指標値です。
実際に、私がパフォーマンス改善のコンサルティングを行い、業績が向上したり、アクセス数が向上したりすると、そこでパフォーマンスの重要性を認識されて、目の色が変わる方は多いですが、そこから先、パフォーマンス計測を定常的に行うかどうかは、人によって分かれます。例え、パフォーマンスが向上して業績が向上したとしても、です。それだけ、ソフトウェア業界における品質管理に対する意識は低いのです。
しかし、日本の製造業が品質管理によって、どれだけ世界市場を席捲したかを思い出して下さい。パフォーマンス計測もそうですし、テストの自動化が普及しないのを見るに、日本のソフトウェア開発の現場は、あまりに品質管理に無頓着です。
パフォーマンスを意識して、Webサイトを開発することは決して損にはなりません。それどころか、プラスになることばかりです。
今後も、このブログや、html5jパフォーマンス部を通して、現場で開発されるエンジニアの皆さんにパフォーマンス計測の重要性や、高速化手法ありきの高速化ではなく、計測データ分析に基づく高速化の重要性を啓蒙していきたいと思います。