HTML5 NIGHT 08. Web × パフォーマンス技術

31
HTML5 NIGHT 08. Web × パフォーマンス技術」 パフォーマンス部 部長 竹洞 陽一郎 201465

Transcript of HTML5 NIGHT 08. Web × パフォーマンス技術

HTML5 NIGHT「08. Web ×パフォーマンス技術」

パフォーマンス部部長

竹洞陽一郎

2014年6月5日

html5j パフォーマンス部サイト

計測条件•対象ブラウザ

• IE 9.0 (GPU Accelerator On)

• Firefox 14.0.1 (SPDY On)

• Chrome 31.0.1650.63 (SPDY On)

•計測ISP• NTT

• KDDI

•計測間隔• 15分に1回、しかし、間隔はランダム化されているので、きっかり15分ではない。

散布図― Scatter Plot (6/7 〜 6/14)

パフォーマンス平均(6/7〜6/14)

可用性平均(6/7 〜 6/14)

IEでのエラー

統計データ要約平均 標準偏差 IQR 0% 25% 50% 75% 100%サンプル数

Chrome 1.695211 1.575961 0.367 0.966 1.204 1.3445 1.571 31.532 1148

Firefox 1.970859 1.613145 0.60525 0.011 1.44575 1.6415 2.051 42.229 932

InternetExplorer 1.651217 1.259629 0.5125 0.949 1.18125 1.371 1.69375 23.071 1338

Firefoxユーザーは、25%の確率で、ページのダウンロードに、2秒以上かかる

箱ひげ図― Boxplot chart

IE9 (SPDYなし)

Firefox14.0.1(SPDYあり)

Chrome31.0.1650.63(SPDYあり)

Object Trending - IE Facebook

Twitter

Google+Facebook

IEで遅い(19.075秒)事例 DNS Lookup18秒

緑の線はFirst Paint、赤い線はTime to Interactive

Object Trending - Firefox Facebook

Facebook

Firefoxで遅い(42.491秒)事例

FacebookFirst Byte Download

41.8秒

緑の線はFirst Paint、赤い線はTime to Interactive

Object Trending - ChromeTwitter

Hatena

Chromeで遅い(33.444秒)事例

緑の線はFirst Paint、赤い線はTime to Interactive

はてなFirst Byte Download

30.6秒

Connection View - IE

Total number of resources: 32Total number of domains: 17Total number of IP addresses: 14Total number of connections: 24

余分なコネクション数=コネクション数-ドメイン数24-17=7

Connection View - Firefox

Total number of resources: 45Total number of domains: 22Total number of IP addresses: 18Total number of connections: 30

余分なコネクション数=コネクション数-ドメイン数30-22=8

Connection View - Chrome

Total number of resources: 33Total number of domains: 17Total number of IP addresses: 15Total number of connections: 20

余分なコネクション数=コネクション数-ドメイン数20-17=3

スループット、ドメイン数、IP数、コネクション数の違い

Firefox

Chrome

Internet Explorer

帯域はそれほど使っていない• デスクトップブラウザであっても、実質、250KB/秒(2Mbps)ぐらいしか使っていない。

• TCP/IP 3way handshakeの影響

• TCP Slow Startの影響

•云わば、通信の「Context Switch」のオーバーヘッド

SNSのボタンを張り付けると…• あっという間に、ドメイン数が増える

• ドメイン数が増えると、SPDYの利点が失われる

• HTTP2.0の仕様策定について、最近、SPDY反対派が増え始める

IEでのドメイン増加数~16

• Facebook – 6 domains• www.facebook.com

• www.facebook.com

• connect.facebook.net

• s-static.ak.facebook.com

• static.ak.facebook.com

• static.ak.fbcdn.net

• Twitter – 3 domains• twitter.com

• cdn.api.twitter.com

• platform.twitter.com

• Google+ – 4 domains• accounts.google.com

• apis.google.com

• oauth.googleusercontent.com

• ssl.gstatic.com

• はてな – 3 domains• b.st-hatena.com

• cdn-ak.b.st-hatena.com

• cdn.api.b.hatena.ne.jp

赤字は、HTTPSでの配信

Firefoxでのドメイン増加数~21• Facebook – 7 domains

• www.facebook.com• www.facebook.com• connect.facebook.net• s-static.ak.facebook.com• static.ak.facebook.com• static.ak.fbcdn.net• fbstatic-a.akamaihd.net

• Twitter – 3 domains• twitter.com• cdn.api.twitter.com• platform.twitter.com

• Google+ – 5 domains• accounts.google.com• apis.google.com• oauth.googleusercontent.com• ssl.gstatic.com• clients1.google.com

• はてな – 3 domains• b.st-hatena.com• cdn-ak.b.st-hatena.com• cdn.api.b.hatena.ne.jp

• その他 – 3 domains• evsecure-ocsp.verisign.com• gtglobal-ocsp.geotrust.com• ocsp.digicert.com

赤字は、HTTPSでの配信

Chromeでのドメイン増加数~16• Facebook – 6 domains

• www.facebook.com

• www.facebook.com

• connect.facebook.net

• s-static.ak.facebook.com

• static.ak.facebook.com

• fbstatic-a.akamaihd.net

• Twitter – 3 domains• twitter.com

• cdn.api.twitter.com

• platform.twitter.com

• Google+ – 4 domains• accounts.google.com

• apis.google.com

• oauth.googleusercontent.com

• ssl.gstatic.com

• はてな – 3 domains• b.st-hatena.com

• cdn-ak.b.st-hatena.com

• cdn.api.b.hatena.ne.jp

赤字は、HTTPSでの配信

コンサルタント第二の法則一見どう見えようとも、それは常に人の問題である。

― G. M. ワインバーグ

「技術」ではなく、「人」の問題•実際は、技術的には解決可能であっても、人の問題で解決できない事の方が多い。• パフォーマンス部のサイトでは、わざとSNSのボタンを貼って、3rd Party Contentsの影響を計測。

•皆さんのサイトから、SNSのボタンを外せるのか?• 人の意思決定が絡む問題

•技術的にしろ、ビジネス的にしろ「制約」があるからこそ、人は考える。• 日本のWebパフォーマンスの遅延の問題の原因

• 日本のインターネット環境を過信した幻想が生み出した「通信速度の制約の無い世界」

• 「見える化しない慣習」

データを取得し、現実と向き合おう。

制約がどこにあるか、その存在を知ろう。

制約があるからこそ、知恵が必要。

ヴィルトの法則

ソフトウェアは、ハードウェアが高速化するより

急速に低速化する

Daivid Mayの法則

ソフトウェアの効率は18か月で半減し、

ムーアの法則を相殺する

エンジニアの使命

•ハードウェアの進化、通信環境の進化を当てにして、パフォーマンス上の制約が将来消えるなどと思ってはいけない。

•我々が、ハードウェアの進化を相殺してどうする?

•我々は、制約のある世界で知恵を絞るからこそ、知識労働者としてのエンジニアなのだ。

ご静聴ありがとうございました。