1.
ウェブに関わる人なら知っておきたい
パフォーマンスの基礎とこれから
by ふろしき
2015.03.20GREE MiniTechTalk

2.
エンジニアをやっています川田です。Webのパフォーマンス関連のことで、いろいろと活動しています
ウェブエンジニア
・Software Design(技術評論社)
2014年5-7月号
「Web標準技術ではじめる
Webパフォーマンス改善」 他
・html5j パフォーマンス部
・日本Cordovaユーザー会
・Microsoft MVP (Internet Explorer)
・W3C Web-perf WG 他
ふろしき (川田 寛)
Published Community
4年前、とある開発プロジェクトで
フロントエンドの性能劣化にかなり苦しめられ
以来、Webのパフォーマンス技術を追っています

3.
2.パフォーマンスの計測
3.パフォーマンスの改善
4. 最後に
アジェンダ
ギクッ
Webパフォーマンスの計測とちょっとした統計学、改善手法、最近の標準化の動向の話をします
1.ウェブの仕組み

4.
パフォーマンスは企画段階から検討が必要で、運用時にも仕込みが必要です。しかし、今日はそんな話はしません
お話しないこと
1. 多重化と設計(見積もり)みたいなこと
2. 負荷テストとその手法みたいなこと
3. キャパシティプランニング(運用)みたいなこと
お伝えしたい人
・Webインフラエンジニア
・Webアプリ開発者
・フロントエンドエンジニア
・技術的なことに興味があるWebデザイナ
今日は、Web標準なお話をします!!!

5.
1. ウェブの仕組み

6.
インターネットはなぜ遅いのか？
インターネットは、信頼性や効率を犠牲に、拡張性の高さを優先した、”IP”という技術を利用しています
R
R
R
R
R
クライアント
(ブラウザ)
サーバ
(Webサーバ)
健全な
ネットワーク
悪い
ネットワーク
新品な
ネットワーク
オンボロな
ネットワーク
赤ん坊
ツギハギな
ネットワーク
おーい、おまえら…
ちゃんとパケット
送ってくれよ(怒)
まだ？
捨てられたパケット
ポイッ
ばぶー
来ないね
もう限界や…
知ッテイル
モウ少シマテ
偽物なら
あるで？
ここ
ほんと暇だな

7.
インターネットはなぜ遅いのか？
IPのデメリットを埋める仕組み”TCP”は、信頼性を上げるために”ack”と呼ばれるパケットを返答します
クライアント サーバ
ネットワークA
R
ネットワークB
TCPデータ
TCPデータ
ack
ack
TCPデータ
TCPデータ
きたぞー
送ったぞー

8.
TCPデータ
インターネットはなぜ遅いのか？
クライアント サーバ
ネットワークA
R R R
ネットワークB ネットワークC ネットワークD
2点間の距離が遠い場合は、ackの応答に時間がかかり、ネットワークリソースを十分に活かしきれません
TCPデータ
TCPデータ
TCPデータ
使い切れていない
ネットワークリソース
ack
ack
ack
ack
きたぞー
送ったぞー

9.
インターネットはなぜ遅いのか？
海外にアクセスしようものなら、ackの応答時間(Round Trip Time)に10倍以上もの差が出ることもしばしば
US カリフォルニア州
166ミリ秒15ミリ秒
yahoo.co.jp
さくら
インターネット
RTT= RTT=
大阪
東京
KDDI
Softbank
Telecom
yahoo.com
海底ケーブル
(恐らくJapan-US経由)
R
R
R
R
R
R
R
R
R
R
R
R
R
R R
R
R
R
R
R
R
R
R
R
35ミリ秒
100ミリ秒
6ミリ秒 6ミリ秒
6ミリ秒 3ミリ秒
一定タイミングごと(一様乱数で少しズラした)にtracerouteを実行し、1週間分のRTTの平均値。
※各ノードについて、L2トンネリングは配慮しないものとする。
25ミリ秒

10.
インターネットはなぜ遅いのか？
今回、海底の光ケーブルは、2,100kmを
約100ミリ秒でRound Tripしていたが…
真空での光の速さが約30万km/秒なのに対して、今回の海底ケーブルは4.2万km/秒。もはや、人類は限界なのです
真空空間の光は、約30,0000kmを
100ミリ秒で進む。つまり…
１ 7：
通信技術が革新しても桁は上がらない時代
上位レイヤーは無駄を排除する努力をすべきだ!!

11.
TCPデータ
インターネットはなぜ遅いのか？
クライアント サーバ
ネットワークA
R R R
ネットワークB ネットワークC ネットワークD
RTの問題を緩和しようと、輻輳制御の煩雑化を犠牲に、ウィンドウサイズや遅延ackなどいろいろ改善を進めましたが
TCPデータ
TCPデータ
TCPデータ
ack
ack
ack
まとめて
送ったぞー
全部
きたぞー
ウィンドウ
サイズ
TCPデータ
もう次
いくからな？
つかおい!
待てって…
TCPデータ
TCPデータ

12.
インターネットはなぜ遅いのか？
クライアント サーバ
ネットワークA
R R R
ネットワークB ネットワークC ネットワークD
TCP接続開始時はいまのところ、RTTがそのままクリティカルパスとなり改善されていません
いいよー
TCP接続
するよ？
じゃ
開始して!
syn
syn
syn
syn
ack
ack
ack
ack
ack
ack
ack
ack
TCPデータ
TCPデータ
※注:APPENDIX-1も参考のこと

13.
ウェブはなぜ遅いのか？
Webページの表示には、名前解決にSSL証明書取得など、様々なRT的処理がクリティカルパスになっていますが
公開鍵証明書
名前解決
リダイレクト
HTMLファイル本体
ブラウザ
CA
DNS
リダイレクトサーバ
HTTPサーバ

14.
ウェブはなぜ遅いのか？
多くはチェーンが可能であり、実態としては2つ以上のサーバが関わることも少なくありません
公開鍵証明書
名前解決
リダイレクト
HTMLファイル本体
ブラウザ
CAチェーン
DNSのチェーン
リダイレクトサーバのチェーン
HTTPサーバ

15.
ウェブはなぜ遅いのか？
ブラウザ
アドネットワーク など
CDN など
JS/CSS
画像ファイル
広告関連
リソース
ソーシャル など
ソーシャル
ボタン
HTMLの解釈と描画の段階に入ると、色んなサーバにあの非効率なサーバ接続処理を大量に開始するのですが

16.
ウェブはなぜ遅いのか？
ブラウザ
アドネットワーク など
CDN など
当然、リソースの全てに、SSLや名前解決、リダイレクトが絡むわけで
JS/CSS
画像ファイル
広告関連
リソース
ソーシャル など
ソーシャル
ボタン

17.
ウェブはなぜ遅いのか？
ブラウザ
アドネットワーク など
CDN など
さらにチェーンできるとなると、潜在的には相当な数のサーバ接続が関わっているわけです
JS/CSS
画像ファイル
広告関連
リソース
ソーシャル など
ソーシャル
ボタン

18.
ウェブはなぜ遅いのか？
どれぐらいのサーバ接続があるのか？サーバとの接続だけでも40オーバーが普通なので、100超えは割とよくあること
http://www.atmarkit.co.jp/
82本 44本
＠ITのトップページ Qiitaの記事
http://qiita.com/nhiroki/
items/eb16b802101153352bba
First Viewアクセスで特徴的なWebページを3つほどご紹介 (2015年3月18日現在)
Pixivのイラストページ
http://www.pixiv.net/member_illust.php?
mode=medium&illust_id=49316209
108本
2回目のアクセス
17本
2回目のアクセス
11本
2回目のアクセス
127本

19.
モバイルはなぜ遅いのか？
さらに、モバイルにおいては帯域の小ささがWebの様々な手続きを全体的に遅くし
通信リソース小さいモバイル(3G回線)において、
最初の600msは手出しできない遅延
有線と比較すると圧倒的なリソース不足、帯域が小さい
HTTP+TCP+IP

20.
モバイルはなぜ遅いのか？
あげく、通信は全機能の中で2番目にバッテリー消費が大きいため、通常は節電のために非アクティブ化されます
Power On
モバイルの場合、ネットワークインタフェースは普段OFFになる!
接続前にONにしなくてはいけない…
※ここで言うネットワーク・インタフェースは
Push Notificationで利用されるものとは別のもの!!
OMG :(
HTTP+TCP+IPレイヤー物理レイヤー

21.
これでは遅くなって当然!!
Webのパフォーマンスは悪くなる宿命にあるわけですが

22.
これでは遅くなって当然!!なのに…なのに!!
そんなこと、利用者からしてみれば、知ったこっちゃありません

23.
2. パフォーマンスの計測

24.
どういう状態を遅いというのか？
平均は約700ミリ秒？？
…言うほど、遅くないように見えるけど?
計測するのはいいのですが、ほんの数件だけでは特徴がさっぱり見えません
・１回目：534ミリ秒
・２回目：812ミリ秒
・３回目：742ミリ秒
さっそく、計測してみた
？？

25.
どういう状態を遅いというのか？
では10件程度でしょうか？これでもまだ、全体が見えません
10PVほど収集。
件数(件)
読込時間(ミリ秒)
10回やると平均800ミリ秒超えた？
けど、そんなに遅い？
本当にこんな分布？
？？

26.
どういう状態を遅いというのか？
1,000PVほど収集すると…
ん？これ、よく見たら対数正規分布…
多くの値を使うと状況は変わります。Webの速さが、対数正規分布っぽいということに気がつきませんか？
件数(件)
読込時間(ミリ秒)

27.
どういう状態を遅いというのか？
この分布だと少数の異常値が含まれる…
先ほどの図では見えませんでしたが、対数正規分布の場合は、少数の異常な値が交じることになります
Webページ表示時間の順位(位)
読込時間(ミリ秒)
少数の異常値速すぎ。恐らく何かエラーがある
異常に遅すぎ。恐らく何かエラーがある

28.
どういう状態を遅いというのか？
平均値で評価するとσ(信頼性)の大きさやμ(遅さ)が見えません。ここはパーセンタイルで評価するのが一般的です
Webページ表示時間の順位(位)
50パーセンタイル → 832ミリ秒
70パーセンタイル → 1,310ミリ秒
90パーセンタイル → 3,428ミリ秒
(※50%のアクセスが832ミリ秒以下になる)
(※70%のアクセスが1,310ミリ秒以下になる)
(※90%のアクセスが3,428ミリ秒以下になる)
30パーセンタイル → 531ミリ秒
(※30%のアクセスが531ミリ秒以下になる)
パーセンタイルで遅さを評価。こ、これはッ!!!!!
30回に1度は10秒超え!?
50回に1度は30秒超え!?これが原因?
読込時間(ミリ秒)

29.
？？
…普通に速くね？
9割が3秒台だし!!
ただ、考えてみて下さい

30.
このグラフの軸
こいつらは一体、ナニモノ？
…グラフで使っていた軸、本当に大丈夫ですか？

31.
欲しい情報(母集団)に含まれる値を”標本”を呼びますが、それの質が低いと母集団は推測できません
↓この人はなぜ、遅いと感じたのか？
標本がなければ推測できない
仮説1) 100回に1度のとても悪いタイミングにあたり、
その瞬間だけは確かに遅かった。
仮説2) アクセス数が多くてサーバ負荷が高いため、
その時間帯は常に全ユーザが読み込みが遅かった。
仮説3) CSSの読み込みが遅く描画をブロックするため、
常に遅く描画された。
特定の時間に
偏りのあるサンプルは
使い物にならない
HTML読込時間は
使いものにならない

32.
サーバサイド・モニタリング
確実に値が取れる、環境の制約を受けにくい
ブラウザ上のイベントが見えない
トータルの速さ、JSの実行結果を含めた計測ができる
値をドロップすることがある、環境の差異が大きい
良
悪
良
悪
質の高い標本を得る手段は増えています。最近では、サーバサイドだけでなく、クライアント上でも計測ができます
サーバ上でHTTPリクエストなどをモニタリングして計測。
ブラウザ上で様々な処理をモニタリングして計測。
リアルユーザ・モニタリング
標本がなければ推測できない

33.
リアルエンドユーザによる計測
シミュレーションによる計測
実際のユーザの置かれている状況を丸裸にできる
標本として正しいのか見極めが難しい値がある
ブラウザの機能にないところまで計測できる
単位時間あたりのPV数など、得られない値がある
良
悪
良
悪
データに乗っているノイズから解放してくれる、シミュレーションによる計測からも目が話せません
実際に運用しているサーバやユーザのブラウザ上で計測。
ブラウザの動きをシミュレートして運用中のサーバにアクセスし計測。
標本がなければ推測できない

34.
サービスがゴマンとあるわけですが、私はオープンソースの人なのでよくわかりません！オススメ、教えてください
私が知っている範囲(知人レベル)で有償系：
無料系：
オープンソース系 Make the Web Faster
PageSpeed Insights modern.ie
Site Scan
→モバイル系
@massieさんのところが
もいちょっとしたら…多分
→Webサイト系
@takehoraさんが
代理店で販売
Yahoo! Boomerang
→恐らく停滞
→よく目にする…
標本がなければ推測できない

35.
よくわからないけど
対策のきっかけが欲しい!!
何から始めたらいいのかわからないようでしたら、まずは手頃なサイトスキャンに検査を委ねてみましょう
→ とりあえずのサイトスキャン
modern.ie
Site Scan
①
②

36.
Web制作者、アプリ開発者向け
制約こそあるがMicrosoftらしい親切さがある
特徴
1. 検査項目がかなり豊富
2. 日本語対応、説明が親切
3. MS製品と相性がいい
4. モバイルとデスクトップは
同じWebページが前提
modern.ie Site Scan
計測とかよくわからない！そういう人は、とりあえずこのサービスに頼ってみてください

37.
Webpagetest
アプリ開発者、インフラエンジニア向け
オープンソースでGoogleのアイデアが入っている
特徴
1. 指標値がかなり豊富
2. 自前のサーバで使える
3. OSS系ブラウザが使える
ガッチガチに数値と睨めっこしたいひとは、このOSS製品がかなりオススメです
4. モバイルとデスクトップは
別々に対応してOK

38.
ブラウザ上でのパフォーマンス計測は
Web標準の力を必要としている!!
何から始めたらいいのかわからないようでしたら、まずは手頃なサイトスキャンに検査を委ねてみましょう本章の最後に、ブラウザのパフォーマンス計測で得られる値、指標値の標準化について説明します

39.
ブラウザごとに値の意味が違っていたら、役に立たない!
ブラウザ上での計測
Webは、サーバ環境の統一はできてもブラウザはバラバラ。標本用途には、標準化された値が必要なケースがあります
Web標準として、計測方法や値の意味を定義

40.
ブラウザ上での計測
例えば、Webページ読み込み時に発生する様々な事象がいつ起きたのか？これはもう標準で定義されています
ハイパーリンクのクリック。
ナビゲーションの手続き開始。
ビュー内が白くなり、
DOMの読み込みを開始。
全てのコンテンツの読み込みが完了し、
JSイベントを実行。
Navigation Start
DOM Loading
Load Event Start
ex.
1427014713416
1427014719823
+ 6,407 ms
1427014803940
+ 84,117 ms

41.
ブラウザ上での計測
JavaScript API
開発者ツール
Web標準
”開発者ツール”と”JavaScritp API”の2箇所から、その値を確認することができます
その場で
確認したい!!
どこかに
蓄積したい!!
デバッグ用途
分析用途

42.
旧時代的かつもっとも実用的な仕様：
Navigation Timing
2010年、IE9に実装すべくかなりの早さで仕様を固めたのがNavigation Timingです。実用的ですが、まもなく消えます
ブラウザ上での計測
Webページ遷移時のパフォーマンス
計測方法と値の定義
JavaScript APIの仕様
W3C勧告で安定しているけど
数年後には人々の記憶から失われることになる

43.
ちなみに、雑誌でもWebでも、日本語の詳しい解説はだいたい私が頑張りました。…か、買ってくださいね(汗)
ブラウザ上での計測
仕様の詳しい説明はこちら↓ Webだとこちら↓
https://html5experts.jp/furoshiki/6242/
旧時代的かつもっとも実用的な仕様：
Navigation Timing

44.
これからのパフォーマンス計測の標準と言えば：
Performance Timelineと…
次世代は、Performance Timelineという仕組みを通じて、様々な計測値が高精度で取得できるようになります
ブラウザ上での計測
＋Navigation Timing 2
＋Resource Timing
＋Frame Timing
＋User Timing
＋Server Timing
計測対象とその仕様 精度に関する仕様
＋High Resolution
Time
＋High Resolution
Time 2
※注:APPENDIX-2も参考のこと

45.
ここは以前まで
Navigation Timing
だった!!
ブラウザ上での計測
Chrome 41では、ちゃんとお引っ越し済みなので
少しだけ遊べる状態。
ちなみに、Chromeは41から体験できるようになりました
仕様はほとんど
固まってないけど(汗)

46.
目玉の一つがネットワークの状態の可視化で、今もなお更に詳細化しようと検討しています
ブラウザ上での計測
1. ネットワーク周りの計測が強化された!!
ブラウザ
チェーンされたサーバたち
↑これができるように、今まさに検討中
計測
計測
計測
計測
計測
Server Timing

47.
この仕様が発展すると、TCPのおかげで海底ケーブルをいっぱい往復するパケットたちを、妄想して楽しめるわけです
ブラウザ上での計測
1. ネットワーク周りの計測が強化された!! ↓ここを往復してる!!
Server Timing

48.
画像ファイルやCSS/JSの読み込みも、計測値を拾えるようになりました。つい最近、実用フェーズに入ってます
ブラウザ上での計測
2. HTMLファイル以外のリソースのパフォーマンスを可視化
昨年末、ようやくFirefoxが
35で実装したので
これで使い物になりそう!!
ブラウザ
JS/CSS
画像ファイル
広告関連
リソース
ソーシャル
ボタン
計測
計測
計測
Resource Timing

49.
画面遷移だけでなく、アニメーション的な振る舞いに対して、フレームレートを計測できるようにする予定です
ブラウザ上での計測
3. アニメーション/フレームレートも可視化する!(これから)
Frame Timing

50.
また、速さの計測だけでなく、エラーもロギングして取得できるようにする予定です
ブラウザ上での計測
4. エラーも探れるようにする!(これから)
少数の異常値速すぎ。恐らく何かエラーがある
異常に遅すぎ。恐らく何かエラーがある
Network Error Logging

51.
巨大なファイルのアップロードやダウンロードも、ユースケースに含めていく方針です
ブラウザ上での計測
5. 巨大ファイルのダウン/アップロードも計測する!(これから)
ブラウザ サーバ
ZIP
動画 画像
Resource Timing

52.
Power On
モバイル固有の問題にだって、対応していく予定です
ブラウザ上での計測
6. モバイルをしっかりと捉える!(これから)
ネットワーク
インタフェースの
活性化の時間も可視化
Navigation Timing 2

53.
ブラウザ上での計測
http://www.w3.org/wiki/Web_Performance/Publications

54.
3. パフォーマンスの改善

55.
HTTP1.x

56.
HTTP1.xの時代、通信効率を上げることについて、TCP接続がネックになっていました
HTTP1.xのインフラ戦略
通信時間を短縮したい!!
・TCP接続のオーバヘッドを減らす → KeepAlive
・接続後の通信量を減らす → gzip
・既にロードしたことある場合は読み込まない → Expires
通信効率を上げたい!!
・JS/CSSファイル数を減らす → Concat
・画像ファイル数を減らす → CSS Sprite
・ファイル読込の並列性を上げる → ドメインシャーディング

57.
TCP接続を減らそうとしつつも、一方では増やして並列性を高めようとする矛盾
ブラウザ サーバ
HTTP1.xのインフラ戦略
並列性が足りないから増やすぞ!!
オーバヘッド減らすためにまとめるぞ!!
ファイル数分、TCP接続や!!
▼
▼
▼
どうなる!?

58.
SPDY?

59.
HTTP/2

60.
HTTP/2になると、接続数はもちろん減ります。時代の流れからして、必然の傾向です
ブラウザ サーバ
HTTP/2のインフラ戦略
並列性が足りないから増やすぞ!!
オーバヘッド減らすためにまとめるぞ!!
ファイル数分、TCP接続や!!
▼
▼
▼
オーバヘッドを減らすためにまとめるぞ!!

61.
通信周りに対する問題は、HTTP/2の登場である程度解決してくれるらしいです。らしい？何が言いたいかと言うと
通信時間を短縮したい!!
・TCP接続のオーバヘッドを減らす → HTTP/2 !?
・接続後の通信量を減らす → HTTP/2 !?
・既にロードしたことある場合は読み込まない → HTTP/2 !?
通信効率を上げたい!!
・JS/CSSファイル数を減らす → HTTP/2 !?
・画像ファイル数を減らす → HTTP/2 !?
・ファイル読込の並列性を上げる → HTTP/2 !?
HTTP/2世代のインフラ戦略
…ええ、怖いですよ。

62.
定石が変わってしまったので、1.xのインフラを2にそのまま移すのいうのは難しく、何も考えなかったら悪化します
HTTP/2世代のインフラ戦略
HTTP1.xインフラ≠HTTP/2インフラ
えっ、今SPDY/3!?
あ、はい。頑張って下さい…

63.
もうやることなくなるの？
アプリ開発者はやることはもうなくなったのでしょうか？いえ、それがまだ残っています

64.
アプリの特性に合わせた、パフォーマンスの改善技術というのが作られています
インフラ
アプリ
ビジネス
HTTP/2という
汎用的な
手段で解決
HTML5による
アプリ特化な
手段で解決
やること
まだ
あります。

65.
画面を描画する過程、読み込むファイルの中の作りにまで踏み込んで見えるのは、アプリ開発者だけです
HTML5世代のアプリケーション戦略
Navigation Start
Unload
First Paint
DOMContentLoaded
Above to fold(ATF)
Loaded
→ クリック or サブミット
→ 画面を白くする
→ 描画を開始する
→ DOMの読み込みを完了する
→ 最初に見えるスクリーン内の描画を完了する
HTML
JS/CSSJS/CSSJS/CSS
ImageImageImage

66.
First Viewの最適化
・Resource Priorities
ファイル(リソース)の読み込み優先度の制御
・Resource Hints
別ページで使われるファイルやページ全体を先読み
Repeat Viewの最適化
・Service Worker
オンライン時の振る舞い・キャッシュの細かい制御
作りを把握した上で、アプローチする方法も日々生み出されています
HTML5世代のアプリケーション戦略

67.
ATFの最適化
・CSS/JSのインライン化
CSS/JSをHTML内に展開しておく
モバイルでのGPU活用
・CSS3 Animation
GPUを有効活用してスムーズな動きを作る
通信量の最適化
・画像ファイルの変換、Webフォントのサブセット化
インフラ化しようと思えばできるか…
そして相変わらず、泥臭い方法が残っていて、それもWeb標準側でカバーしようとはしています
HTML5世代のアプリケーション戦略

68.
4. 最後に

69.
・HTTP1.x系からHTTP/2への移る時期、つらい。
クラウドの普及で若干圧されがちだった、
インフラエンジニアが再び脚光を浴びる！？
・モバイルだと、Webがユースケースに合わない、つらい。
オフライン強化、リッチアプリ風の作りが要求されたり、
市場価値を取り戻すまでしばらく耐える時期かも！？
・Googleがモバイル中心主義になりつつあり、
Web標準側もモバイル特化の改善に舵を切っている感じ。
※Microsoftは、モバイルとデスクトップをくっつけたい派っぽい。
一言だけコメント
インフラ屋さんもアプリ屋さんも、しんどい時期が続きそうですね

70.
・Google - Ilya Grigorik一派
→実装最速
・Microsoft - Tobin Titus一派
→実装速度は2番手ぐらい。かなり速い方。
・Mozilla
→少し後ろを走りつつも追っている。
・Apple
→ ＼(^o^)／
肝心のアダプションについて
しかも残念なことに、Appleは全くもってパフォーマンス系の機能をサポートしてくれません

71.
モバイル…無理なのか!?

72.
ところが…

73.
喜ぶ人々。

74.
・Google - Ilya Grigorik一派
→実装最速
・Microsoft - Tobin Titus一派
→実装速度は2番手ぐらい。かなり速い方。
・Mozilla
→少し後ろを走りつつも追っている。
・Apple - Ryosuke Niwa一派!?
→ 2015年は本気出す…!?
2015年も
パフォーマンスの技術はもっと良くなる!!
肝心のアダプションについて
これからAppleもパフォーマンス系の機能に力を入れてくれそうで、2015年もますます発展が期待できそうです

75.
Thank You!!
@kawada_hiroshi
速いは楽しい!!

76.
APPENDIX-1
TCP Fast Open(TFO)
→
クライアント サーバ
…こんなの、私の知っているTCPじゃない
けど、なんかわくわくする!!
syn + HttpRequest
ack + HttpResponse
TCPデータ

77.
APPENDIX-2
Performance Timelineと他の仕様との関係
JavaScript APIの仕様
Performance
Navigation
Timing 2
Resource
Timing
Frame
Timing
User
Timing
+ getEntries()
+ getEntriesByType()
+ getEntriesByName()
Performance
Entry
+ name
+ entryType
+ startTime
+ duration
Written by
UML 2.5 Class Diagram
Performance Timeline
<<interface>>
http://www.w3.org/TR/
performance-timeline/
https://w3c.github.io/navigation-
timing/
https://w3c.github.io/resource-
timing/
https://w3c.github.io/user-
timing/
https://w3c.github.io/frame-
timing/
Webページ読込時間の計測
リソース読込時間の計測
リフレッシュレートの計測
任意時点の計測
<<interface>>
Server
Timing https://w3c.github.io/server-
timing/
サーバ接続時間の計測
1
0..*
implements

78.
Navigation Timing→Performance Timeline
JavaScript記述方法の変化
APPENDIX-3
performance && performance.timing && (function() {
var timing = performance.timing;
var loadTime = timing.loadEventEnd - timing.navigationStart;
console.log( loadTime );
})();
performance && performance.getEntriesByType && (function() {
var timing = performance.getEntriesByType(“navigation”)[0];
if( timing ) {
var loadTime = timing.loadEventEnd - timing.navigationStart;
console.log( loadTime );
}
})();
▼ Navigation Timing
▼ Navigation Timing 2

79.
1. High Performance Browser Networking - Ilya Grigorik (O’Reilly Media)
http://chimera.labs.oreilly.com/books/1230000000545
2. Mobile Analysis in PageSpeed Insights (Google Developers)
https://developers.google.com/speed/docs/insights/mobile
3. Kokusai Cable Ship Co.,Ltd
http://www.k-kcs.co.jp/english/topic_unity.html
4. WebPagetest.org
http://www.webpagetest.org/
5. modern.IE Site Scan
http://modern.ie/ja-jp/
6. W3C WEB PERFORMANCE WORKING GROUP
http://www.w3.org/2010/webperf/
7. Evaluating network performance
https://developer.chrome.com/devtools/docs/network
8. Hello HTTP/2, Goodbye SPDY
http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html
9. rniwa from Apple just joined the Web Performance WG
https://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0055.html
Reference