Webパフォーマンス計測の勘所 2013-07-05

Webパフォーマンス計測の勘所
統計分析⼿手法に基づいた「正しい」計測
©2013 Keynote Systems, Inc.
Keynote Systems, Inc.
Technical Business Representative
⽵竹洞洞陽⼀一郎郎
Yoichiro.Takehora@keynote.com

⾃自⼰己紹介
§  Keynote Systems…Technical Business Representative
§  やってきた事
§  Layer1～7の技術
§  定量化・定性化分析手法（Function Point法、COCOM II）
§  システム最適化
§  Lotus Notes → Windowsのシステム構築 → Unix/Linuxのシステム構築 → メール → Webシステム
→ ユーザビリティ→システム開発見積り・IT不良資産 → 仮想マシン → CDN、Web高速化、ストリー
ミング、RMT問題 → Webコンサルティング（パフォーマンス、UX）
§  配信情報
§  Keynote Systems Japan 公式サイト
（http://www.keynotesystems.jp/）
§  Keynote Webパフォーマンスコミュニティ
（https://www.facebook.com/KeynoteSystemsJapan）
§  Keynote Systems Japan公式Blog
（http://blog.keynotesystems.jp/）
§  各種資料
http://www.slideshare.net/takehora/presentations
2013年 7月 5日 2©2013 Keynote Systems, Inc.

Keynote Systemsについて
•  アメリカ合衆国カリフォルニア州サ
ンマテオに本社を置く
•  1995年年創業、1999年年NASDAQ上場,
2013年年⾮非上場
•  Web、モバイル、ストリーミングの
パフォーマンス計測のサービスを主
とする
•  計測の分野におけるマーケットリーダ
ー
•  顧客数4,000社以上
•  計測拠点275ヵ所
•  計測⽤用コンピュータ7,000台以上

4
New MediaAutomotive
Retail
Financial Services
Technology & Telecom TravelPortals/Media
Business-to-Business
Keynoteをご採⽤用頂いているお客様
©2013 Keynote Systems, Inc. 2013年 7月 5日

あなたの会社のWebサイトが1⽇日1万PVを超
えているなら、今⽇日の話は重要です。

WEBパフォーマンス計測の勘所
統計分析⼿手法に基づく

「進撃の巨⼈人」

「急所」を狙え！

General Rule Book ― 鵜呑みにしない事

「急所」を判別して改善する
§  80:20の法則（パレートの法則）〜～冪乗則
§  全体の数値の大部分は、全体を構成するうちの一部の要素が生み出し
ている
2013年 7月 5日 10©2013 Keynote Systems, Inc..

⾃自社Webシステムの「急所」はどこだ？

統計分析⼿手法でWebサイトの「急所」を探り当てる
§  データの取り⽅方が⼤大事
§  データは、どのように計測すれば良良いのか？
§  統計学で、⼿手法が確⽴立立している

実験計画法
§  1920年年代に、統計学の⼤大家、R・A・フィッシャーが確⽴立立
§  効率率率のよい実験⽅方法をデザインし、結果を適切切に解析す
ることを⽬目的とする統計学の応⽤用分野
§  品質管理理のタグチメソッドの基礎

実験計画法〜～3つの原則
§  3つの原則
§  局所管理化：影響を調べる要因以外のすべての要因を可能な限り一定
にする。
§  反復：実験ごとの偶然のバラツキ（誤差）の影響を除くために同条件で
反復する。
§  無作為化（ランダム化）：以上でも制御できない可能性のある要因の影
響を除き、偏りを小さくするために条件を無作為化する。例えば実験を
行う空間的・時間的順序の影響があるかもしれないから、決まった順序
でなく実験のたびに無作為に順序を決めるなど。

「Big Data」より「Actionable Data」
§  「データを何に使いたいのか」という⽬目的が、データの
取得⽅方法に⼤大きな影響を与える
§  監視したいのか？計測したいのか？
§  要因を固定し、条件を統⼀一する
§  コントロール可能な「主変数」にフォーカスする

コントロール可能な3つの「主変数」
2013年 7月 5日 16
Last
Mile
First
Mile
Middle
Mile
web server
エンドユーザ
NTT
KDDI
エンドユーザ
１次ISP
1. ネットワーク
2. HTML/CSS/JavaScript
3. システム負荷/性能

Webパフォーマンスの「主成分」

ボトルネックを考える
§  「データベース」が常にボトルネックではない
§  インターネット網の不安定さ
§  ⾃自社コンテンツだけを⾒見見てはいけない
§  サードパーティーコンテンツの不安定さ

サードパーティーの影響
パフォーマンスの劣劣化の原因が、全て⾃自社以
外のドメインからの配信
19

Web Content
Web Users
$
50X50X
20X20X
6X 6X
$$
$$$
$$$
$$$
First Mile
Tier 1 ISPs
Local ISPs
Last Mile
Middle Mile
インターネットインフラへの投資⽐比率率率
2013年 7月 5日

データの取り⽅方
2013年 7月 5日 21
Last
Mile
First
Mile
Middle
Mile
web server
エンドユーザ
NTT
KDDI
エンドユーザ
１次ISP
RUM （Real User Monitoring）
Synthesis Monitoring
Systems/Server side Monitoring

3つの計測⽅方法を組み合わせる事で補完し合う
§  Systems/Server Side Monitoringの弱点
§  インターネット網の影響がわからない
§  サードパーティーコンテンツの影響がわからない
§  Synthesis Monitoringの弱点
§  選択された計測拠点の値しかわからない
§  選択された合成アクセスのページ遷移でしか値がわからない
§  Real User Monitoringの弱点
§  変数がわからない
§  計測値が確実に取得できるとは限らないため、データの偏りが生じる

「観察者効果」の問題
§  観察するという⾏行行為が観察される現象に変化を与えてし
まう問題
§  例例えば、電⼦子を⾒見見ようとすると、まず光⼦子がそれと相互
作⽤用しなければならず、その相互作⽤用によって電⼦子の軌
道が変化する
§  エンドユーザを「観察」しようとJavaScriptを⼊入れるこ
とで、そのJavaScript⾃自体がパフォーマンスの遅延など
の変化をもたらす
§  行動解析用ビーコンが表示の遅延をもたらし、離脱率を上げる
§  RUMのJavaScriptが、表示速度の遅延をもたらす
§  広告効果測定ビーコンが、ページ表示の遅延をもたらす

Last
Mile
First
Mile
Middle
Mile
24
2013年 7月 5日
web server
モバイル
シミュレータ
計測Agent
SoftBank
Gateway
docomo
Gateway
NTT
3G/4G回線
インターネット回線
モバイル（スマートフォンサイト）の計測

制約の多いモバイルネットワーク
§  電波⼲干渉という問題
§  ユーザがそこに多く居るからと言って、電波塔（基地局）は増やせない
§  基地局を乱立するとどうなるか? – “Dirty WiFi”と同じ状況に
§  電波の「谷間」～基地局と基地局の中間点
§  「繋がる」事と「通信できる」事は、違う
§  アンテナの表示が5本中5本立った! → 電波強度が十分というだけ
§  携帯基地局は、混雑するとネットワークを守るためにパケットを意図的
にドロップする
§  レイテンシの問題
§  モバイルネットワークのレイテンシは100～200ms

郊外の基地局配置
⾊色の違い＝チャネルのグループの
違い。
NTTドコモの場合、 800MHz帯を使
い、 15MHzの幅がある。
それを12.5KHz幅で区切切ることで、
15MHz/12.5KHz = 1200チャネルを
持つ。
もし7つのグルーピングを作るとす
ると、各基地局は 1200/7≒170チャ
ネルとなる。

ソフトバンクの「マイクロセル化」

携帯網のパケットドロップ率率率の影響
§  無線基地局のパケットドロップ率率率が20%、1パケット1KBの場合
1.  全部で100KBのデータを送信する場合
§  失敗回数の期待値＝{100×(1-0.8)}÷0.8=25
§  失敗回数の分散={100×(1-0.8)}÷0.8^2 =31.25
§  失敗回数の標準偏差は、31.25の平方根、約6となります。
§  2σの考え方だと、
下値＝失敗回数の期待値－2×失敗回数の分散の平方根
上値＝失敗回数の期待値＋2×失敗回数の分散の平方根
§  2σ（シグマ）の範囲を計算すると、(25－2×6, 25+2×6)=(13, 37)
95%の確率で13～37回の失敗（パケットドロップ）が発生します。
2.  全部で1,000KBのデータを送信する場合
§  失敗回数の期待値＝{1,000×(1-0.8)}÷0.8=250
§  失敗回数の分散={1,000×(1-0.8)}÷0.8^2 =312.5
§  失敗回数の標準偏差は、312.5の平方根、約18となります。
§  2σ（シグマ）の範囲を計算すると、(250－2×18, 250+2×18)=(214, 286)
95%の確率で214～286回の失敗（パケットドロップ）が発生します。

歩留留り（客観的データ）でサイトの品質を診る
§  Webサイトの普及によって、ソフ
トウェア開発に、「⽣生産」のフェ
ーズができた。
§  今まで、ソフトウェア産業に「
⽣生産」はなかった。
§  半製品や部品である各種ファイ
ルを、インターネットという「ベ
ルトコンベア」に載せて、ユーザ
の端末上で組み⽴立立てる。
§  エンドユーザサイドでの「歩留留り
」を監視しなければ、⾃自社のサー
ビスが確実に届いているかはわか
らない。

スマートフォンサイトのSSLの問題点
Googleアナリティクスのビー
コンが遅い。
広告測定ビーコンが遅延の要因に
サイズの⼩小さな画像の多⽤用。
これをCSSスプライトにする
ことで、10秒⾼高速化すること
が可能に。
HTMLのページ⽣生成で、ディ
スクアクセスが遅い
フォーム⼊入⼒力力チェック⽤用Ajax通
信が発⽣生。スマートフォンサ
イトでは致命傷
SSLが遅延の要因に
31

Mobile E-Commerce Top20 – SoftBank – May29th – June19th

Mobile E-Commerce Top20 – DoCoMo – May29th – June19th

Amazon Japan
某社約6倍約10倍
2013年年4⽉月15⽇日 11:11:29
2013年年4⽉月15⽇日 11:05:26

Amazon Japanの場合

Amazonのパフォーマンス正規分布図
2013年年4⽉月1⽇日〜～15⽇日

某社の場合

某社のパフォーマンス正規分布図
2013年年4⽉月1⽇日〜～15⽇日
ここに原因が
⾒見見つけられる

モバイル回線品質改善 – DoCoMo VS
SoftBank

モバイルを
「知っている」サイトと「知らない」サイトの違い

ちょっと改善しただけで、アクセス数30%増
41

Amazonの徹底したデータドリブン主義
§  「ミーティングではデータを重視し、
データに基づいて発⾔言することを求
める。そして、データが⽰示すどんな細
かな兆候も⾒見見逃さない。ベゾス⾃自らが
顧客のフィードバックに⽬目を通してい
ることもよくあるという。」
― 東洋経済ONLINE
http://toyokeizai.net/articles/-/13212
§  御社は、ミーティングで使う「データ
」をお持ちですか？

何故、Amazonは速さにこだわるのか？
§  Amazonでは、1秒速くなる毎に、10%売上が向上する
から。

Webパフォーマンスと訪問者数
Internet Explorer、Firefoxの場合

Webパフォーマンスと訪問者数
iPhone、Androidの場合

Webパフォーマンスとページビュー数

Webパフォーマンスと直帰率率率

Webパフォーマンスとコンバージョンレート

相関図を作ることで、現在の収益への影響の主変数が
コンテンツ要因かパフォーマンス要因かがわかる。
パフォーマンス
コンバージョン

結果に影響を及ぼす変数を考える
表⽰示速度度の定量量評価無しでは、
PV、CV、直帰率率率は正しく評価できない

ライリーの⼩小売引⼒力力の法則(W.F.Reilly, 1929)
P=α＊A/D^2
P=購⼊入確率率率、α＝係数、A＝魅⼒力力、D＝距離離（サイト速度度）
購⼊入確率率率は、⼈人⼝口ないし品揃えに⽐比例例し、距離離（サイト速度度）の⼆二乗に
反⽐比例例する

ログ解析しかやっていないサイトは危ない
§  せっかくコンテンツを新しく
しても、
§  マーケティングキャンペーン
をやっても、
§  新商品を売り出しても、
§  パフォーマンスで⾜足が引っ張
られていた場合、正しくそれ
らの影響を評価できない。
§  商売をしているなら、ちゃん
とパフォーマンスは計測しま
しょう。

彼を知り⼰己を知れば百戦危うからず
（孫⼦子の兵法）
↓
データを持っていない
↓
競合についても、⾃自社についても、知らなさ過ぎる
↓
負けるに決まってる

お問い合わせ
§  各サービス詳細資料料については、Slideshareよりダウン
ロード頂けます。
§  http://www.slideshare.net/takehora/presentations
§  ⽇日本語Webサイトにサービス概要を掲載しております。
§  http://www.keynotesystems.jp/
§  Facebookファンページで最新情報をご覧頂けます。
§  https://www.facebook.com/KeynoteSystemsJapan
§  またブログでも記事を配信しています。
§  http://blog.keynotesystems.jp/
§  価格については、営業窓⼝口までお問い合わせ下さい。
§  （和泉：maki.izumi@keynotesystems.jp）
2013年 7月 5日 56

参考資料料
お時間があるときにでも⾒見見ておいてください

数学（統計学）の重要性
データを「正しく」分析すれば、
未来が予測できる

太っているのか？痩せているのか？
60Kg
⾝身⻑⾧長がわからなければ、太っているのか痩せているのかは、
わからない

⾒見見るべき数値は⾜足りているのか？
§  訪問者数、ページビュー数、直帰率率率、コンバージョン率率率
の数値だけで⼗十分なのか？
↓
⾝身⻑⾧長を知らずに体重を眺めるようなもの
§  今期の売上の理理由は？
§  マーケティングキャンペーンの影響？
§  時期？
§  コンテンツの改善の影響？
§  新商品の影響？
§  価格改定の影響？
§  ユーザーインターフェース改変の影響？

Webパフォーマンスの影響
88%
11%
7%
2倍
16%
1秒速くなる毎のブランドイメージアップ
1秒速くなる毎のCVの向上
1秒速くなる毎のPVの向上
1秒遅くなる毎の顧客満⾜足度度低下率率率
継続的な計測による顧客満⾜足度度向上

スピード = 価値
「今や、250msという速度度が、Webにおける競争⼒力力の強みとなる特別な数字に近い。」 Harry Shum, Microsoft
売上向上
n  10%の売上向上
(1秒⾼高速化される毎に)
(表⽰示速度度が6秒から1.2秒に
⾼高速化することによって)
(2秒⾼高速化される毎に)
n  最速で表⽰示された場合は50%
以上のPV増加
(最遅表⽰示された場合と⽐比較)
n  9%以上のトラフィック増加
(400ms向上される毎に)
⽣生産性向上

n  2%の⽣生産性向上
(2.7秒までアプリケーション
を⾼高速化した場合)
n  エラーが減少、エンジニアリ
ングサイクルが加速、データ
の統⼀一性の向上

Performance Best Practice
§  JavaScriptをHTMLの最後に記述する
§  CSSをHTMLの最初に記述する
§  Keep aliveを使う。Keep aliveの対象数からはみ出るコ
ンテンツがないようにする
§  HTMLファイル以外はキャッシュを効かせる
§  MIMEが”text/*”か”*javascript*”のものについては圧縮配
信する
§  CSSを1枚にまとめる
§  JavaScriptを1枚にまとめる

W3C Web Mobile Best Practice
http://www.w3.org/TR/mobile-bp/
§  Auto refreshを使わない
§  レイアウトのためにTableを使わない
§  キャッシュを使う
§  フレームを使わない
§  テキストフリーにしない（input type=“text”)
§  画像のサイズを明⽰示する（height, width）
§  画像のALTを明⽰示する
§  ポップアップを使わない
§  ページタイトルを明⽰示する
§  Tableの中にTableを定義しない

Webパフォーマンス計測の勘所 2013-07-05

More Related Content

Similar to Webパフォーマンス計測の勘所 2013-07-05

More from Yoichiro Takehora

Webパフォーマンス計測の勘所 2013-07-05