Upload
hiroshi-kawada
View
42.915
Download
4
Embed Size (px)
DESCRIPTION
第51回HTML5とか勉強会の講演資料です。
Citation preview
ブラウザのパフォーマンスを限界まで高める HTMLコーディングの考え方
HTML5とか勉強会 Oct, 24th 2014
川田 寛 (furoshiki) NTTコムウェア株式会社 Mobile & Web Developer, Microsoft MVP(IE) html5jエンタープライズ部 & パフォーマンス部 日本Cordovaユーザ会
Twitter : @kawada_hiroshi
Software Design(技術評論社) 2014年5〜7月号 連載:Web標準技術で行う、Webアプリのパフォーマンス改善
HTML5 experts.jp(NTTコミュニケーションズ) Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測
Agenda
3. 近のWeb標準の動向
1. 戦略の立て方
2. 改善の方法
Agenda
3. 近のWeb標準の動向
1. 戦略の立て方
2. 改善の方法
Webを取り巻く環境は酷くなった!?• •
コンシューマーのメインコンピューター → スマートデバイス&無線へ
Wifiという辛い現実ナビゲーション・・・
Androidという辛い現実ランタイム ・・・
(画面遷移)
(アニメーション)
コンシューマーのメインコンピューター → スマートデバイス&無線へ
Webを取り巻く環境は酷くなった!?• •
ネットワーク環境の悪化ナビゲーション・・・
ハードウェア環境の悪化ランタイム ・・・
(画面遷移)
(アニメーション)
コンシューマーのメインコンピューター → スマートデバイス&無線へ
Webを取り巻く環境は酷くなった!?• •
パフォーマンスを考えて モノを作ることが重要になった
ナビゲーション・・・
ランタイム ・・・
(画面遷移)
(アニメーション)
コンシューマーのメインコンピューター → スマートデバイス&無線へ
ネットワーク環境の悪化
ハードウェア環境の悪化
Webを取り巻く環境は酷くなった!?• •
ナビゲーション・・・(画面遷移)
↑今日はこちらのお話をします
コンシューマーのメインコンピューター → スマートデバイス&無線へ
ネットワーク環境の悪化
Webを取り巻く環境は酷くなった!?• •
パフォーマンスの戦略を立てる上で とてもとても重要なこと
それは・・・
頑張り過ぎないこと。
職人魂が犯す罪は重いのですユーザの 待ち時間
エンジニアの 改善作業時間
職人魂が犯す罪は重いのですユーザの 待ち時間
エンジニアの 改善作業時間
ユーザ の満足
エンジニアが幸せになれる程度の時間
職人魂が犯す罪は重いのですユーザの 待ち時間
エンジニアの幸せが危険に曝される時間
過剰 気味 エンジニアの
改善作業時間
職人魂が犯す罪は重いのですユーザの 待ち時間
エンジニアの生活が崩壊した廃人コース
職人 の世界
エンジニアの 改善作業時間
職人魂が犯す罪は重いのですユーザの 待ち時間 パフォーマンス改善は果てがない
一から十まで全部を求められない
エンジニアの 改善作業時間
エンジニアの生活が崩壊した廃人コース
職人 の世界
職人魂が犯す罪は重いのですユーザの 待ち時間 時間をかけるほど
得られる効果が小さくなる
エンジニアの 改善作業時間
どれぐらい頑張るかを あらかじめ決める
ポイント
どれぐらい頑張ったらいい?
例)
どれぐらい頑張ったらいい?
出来る限り速くなるまで例)
どれぐらい頑張ったらいい?
出来る限り速くなるまで✕例)
だいたい1秒ぐらい
どれぐらい頑張ったらいい?
出来る限り速くなるまで✕
△
例)
だいたい1秒ぐらい
平均1秒以下になるように
どれぐらい頑張ったらいい?
出来る限り速くなるまで✕だいたい1秒ぐらい△
平均1秒以下になるように△
全て1秒以下!
例)
どれぐらい頑張ったらいい?
出来る限り速くなるまで✕だいたい1秒ぐらい△
平均1秒以下になるように△
全て1秒以下! はやめておいて
例)
どれぐらい頑張ったらいい?
出来る限り速くなるまで✕だいたい1秒ぐらい△
平均1秒以下になるように△
90パーセンタイルで1秒以下になるように• • • • • • •
◯
例)
パーセンタイル?
分位数
レアケースを取り除くということ• • • •
参考:HTML5 NIGHT 08. Web × パフォーマンス技術 http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625
参考:HTML5 NIGHT 08. Web × パフォーマンス技術 http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625
このあたりは 過剰に反応しない!
参考:HTML5 NIGHT 08. Web × パフォーマンス技術 http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625
まずは ここを見よ!
参考:HTML5 NIGHT 08. Web × パフォーマンス技術 http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625
まずは ここを見よ!
これこそが、パーセンタイル!
「パーセンタイル」とは?例えば、100件の表示タイムのサンプルがあった場合
「パーセンタイル」とは?
下から90番目のタイム(=90パーセンタイル)
例えば、100件の表示タイムのサンプルがあった場合
「パーセンタイル」とは?
下から80番目のタイム(=80パーセンタイル)
例えば、100件の表示タイムのサンプルがあった場合
「パーセンタイル」とは?
下から20番目のタイム(=20パーセンタイル)
例えば、100件の表示タイムのサンプルがあった場合
ボトルネックを探す
時間がかかっている箇所を探りブレークダウンしていく
参考:HTML5 NIGHT 08. Web × パフォーマンス技術 http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625
←※注:これが真因ではありません!
ウォーターフォール図
「特徴」を探ろう!
おやっ、何かがおかしい!?例えば、100件の表示タイムのサンプルがあった場合
なんか上位5%の「遅い」が いつも同じ値なんだけど・・・
例えば、100件の表示タイムのサンプルがあった場合
おやっ、何かがおかしい!?
例)
参考:HTML5 NIGHT 08. Web × パフォーマンス技術 http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625
タイムアウト待ってる処理がある・・・
※注:これが真因ではありませんが。。。
おやっ、何かがおかしい!?
いやいや、 こんなに速いわけが無いでしょ?
例えば、100件の表示タイムのサンプルがあった場合
うぉっ、何かがおかしい!?
例)
参考:HTML5 NIGHT 08. Web × パフォーマンス技術 http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625
お!?なんか エラーが!?
※注:これが真因ではありませんが。。。
うぉっ、何かがおかしい!?
パフォーマンス改善の 戦略を決める上で必要になる情報
・何秒かかったか?ボトルネックはどこか? ・どんなエラーが出ていたのか?ログは?
Agenda
3. 近のWeb標準の動向
1. 戦略の立て方
2. 改善の方法
何をもって速いと考えるか?
Google I/O 2014にてPaul Lewis氏
https://www.google.com/events/io/schedule/session/c8300366-03ed-e311-903f-00155d5066d7
<重要な3つのポイント
https://www.google.com/events/io/schedule/session/c8300366-03ed-e311-903f-00155d5066d7
<重要な3つのポイント
最初のレンダリングが開始される時間
ブラウザはいつ レンダリングを開始するのか?
ハイパーリンクをクリック!
DNS Server
名前解決開始
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server名前解決完了
Web ServerTCP Connection
接続完了
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
Web Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
Program
Web Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
Program
リダイレクトです・・・
DNS Server
名前解決開始DNS
ServerDNS ServerDNS ServerDNS Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server名前解決完了
Web ServerTCP Connection
接続完了
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
Web Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
Program
Webページある!
Web Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
ProgramBuffer
Web Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
ProgramBufferBuffer
Web Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
ProgramBufferBufferDOM
Web Server
DNS Server
DNS ServerDNS ServerDNS ServerDNS Server
ProgramBufferBufferDOM
Initial Renderingの開始
バッファサイズデフォルトでやっている場合は
バッファサイズ
nginx … 0x1ff8 Byte (約8KB)
デフォルトでやっている場合は
バッファサイズ
nginx … 0x1ff8 Byte (約8KB)
デフォルトでやっている場合は
apache … 0x2000 Byte (8KB)
バッファサイズ
nginx … 0x1ff8 Byte (約8KB)
デフォルトでやっている場合は
gws … 0x8000 Byte (32KB)→シェア低
apache … 0x2000 Byte (8KB)
バッファサイズ
nginx … 0x1ff8 Byte (約8KB)
デフォルトでやっている場合は
gws … 0x8000 Byte (32KB)→シェア低
apache … 0x2000 Byte (8KB)
JSP他 … 0x2000 Byte (8KB)つまり
HTMLドキュメント(HTTPヘッダの一部を含む)
の 初の約8KBがサーバ上で生成され ブラウザ側にそれが転送完了した瞬間 ブラウザは 初のレンダリングを開始する
・・・と、HTMLコーディングする人はそう考えたらいいと思う。
DevツールのTimelineタブだとHTMLドキュメントの処理過程は こんな感じに見える
DevツールのTimelineタブだとHTMLドキュメントの処理過程は こんな感じに見える
実サーバにHTTPリクエスト送信
DevツールのTimelineタブだとHTMLドキュメントの処理過程は こんな感じに見える
実サーバにHTTPリクエスト送信実サーバからHTTPレスポンス応答
※8KB貯めてから送っているのに、結局Receive DataとHTML Parseが 4KB単位で処理されてしまうところがなかなか面白いポイント!(ヒント:MTU)
DevツールのTimelineタブだとHTMLドキュメントの処理過程は こんな感じに見える
実サーバにHTTPリクエスト送信実サーバからHTTPレスポンス応答
HTMLドキュメントを4KBずつ貰う
※8KB貯めてから送っているのに、結局Receive DataとHTML Parseが 4KB単位で処理されてしまうところがなかなか面白いポイント!(ヒント:MTU)
DevツールのTimelineタブだとHTMLドキュメントの処理過程は こんな感じに見える
実サーバにHTTPリクエスト送信実サーバからHTTPレスポンス応答
HTMLドキュメントを4KBずつ貰う
HTMLドキュメントを4KBずつパース
※8KB貯めてから送っているのに、結局Receive DataとHTML Parseが 4KB単位で処理されてしまうところがなかなか面白いポイント!(ヒント:MTU)
DevツールのTimelineタブだとHTMLドキュメントの処理過程は こんな感じに見える
実サーバにHTTPリクエスト送信実サーバからHTTPレスポンス応答
HTMLドキュメントを4KBずつ貰う
HTMLドキュメントを4KBずつパース
レイアウト処理(CPU使って頑張る)
※8KB貯めてから送っているのに、結局Receive DataとHTML Parseが 4KB単位で処理されてしまうところがなかなか面白いポイント!(ヒント:MTU)
DevツールのTimelineタブだとHTMLドキュメントの処理過程は こんな感じに見える
実サーバにHTTPリクエスト送信実サーバからHTTPレスポンス応答
HTMLドキュメントを4KBずつ貰う
HTMLドキュメントを4KBずつパース
レイアウト処理(CPU使って頑張る)
ペイント処理(GPU使って頑張る)
対策に必要なこと・DNSの 適化 → TTLの見直し 等 ・リダイレクトの 適化 → Desktop/Mobileの切り替え処理の見直し、リライト 等 ・TCP/SSLの接続の 適化 → アクセラレータの導入、ローバランサー 等 ・ファーストバイトダウンロードの 適化 → HTMLファイル8KB分を先に送る
などなど
https://www.google.com/events/io/schedule/session/c8300366-03ed-e311-903f-00155d5066d7
<重要な3つのポイント
https://www.google.com/events/io/schedule/session/c8300366-03ed-e311-903f-00155d5066d7
<重要な3つのポイント
https://www.google.com/events/io/schedule/session/c8300366-03ed-e311-903f-00155d5066d7
<重要な3つのポイント
見た目が完成している状態(スクリプト実行は含まない)
・ユーザが一番関心を持つ。(=UXに一番影響を与える。)・「Speed Index」の元データとしても活用される
「Speed Index」って何?
・Webページの速さを図る指標は難しい。 ・unloadイベントからloadイベントが発火する までの間を計測しているようじゃ、価値が無い。 ・Webページが表示される過程も評価すべきだ!
「Speed Index」って何?「見た目の完成までの時間(Visual Complete)」と「その過程(Progressive Rendering)」を、指標化したもの。
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
「Speed Index」って何?要は、ページが完成する時間が同じでも、真っ白な状態が長いのは良くないでしょ!?
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
SpeedIndexを高めるには どうすれば良いのか?
・小さいサイズのものは読み込まない。(Concat 他) ・無駄は削る。(Minify 他)
CSSの 適化
JavaScriptの 適化・小さいサイズのものは読み込まない。(Concat 他) ・無駄は削る。(Minify 他)
画像ファイルの 適化・画像の無駄を落とす。(optimize、JPG化、CSS Sprite 他) ・スクリーンサイズに合わせてファイルを変える。(Responsive Image 他)
ファイルサイズ減らす/通信オーバヘッド減らすとかは かなり直感的な対策だけど、十分ではない
・できる限り処理を多重化し・完成までの時間を極力短く
より全体から対策するなら、こっちを見るべき
Critical Rendering Pathレンダリング完了の 短パスを調整
https://developers.google.com/web/fundamentals/performance/critical-rendering-path/
・過程が見えるよう優先付けする
ネットワークは限られている
HTTP/1.1は典型的な「M/M/6モデル」。同時6本の接続数を大限に活かして、
リソースを読み込もう。
キューの 中で待機
まだ 待機
利用中
利用中
利用中
ネットワークは限られている
HTTP/1.1は典型的な「M/M/6モデル」。同時6本の接続数を大限に活かして、
リソースを読み込もう。(→ドメインを分けるという逃げ道も)
だから、楽しい!!
キューの 中で待機
まだ 待機
利用中
利用中
利用中
ネットワークは限られている
HTTP/1.1は典型的な「M/M/6モデル」。同時6本の接続数を大限に活かして、
リソースを読み込もう。
HTTP2.0やSPDYは、また別のモデルになるのですが…
JS/CSSはHTMLパースを阻害する
hoge.js
hoge.jshoge.jshoge.js
パースが 停止!
…
JSの読み込み と実行
JS/CSSはHTMLパースを阻害する
hoge.js
hoge.jshoge.jshoge.js
パースが 停止!
…
JSの読み込み と実行
いくらネットワーク側をチューニングしても、ブロッキングリソースの調整をしなければ意味が無い!
JS/CSSはHTMLパースを阻害する
hoge.js
hoge.jshoge.jshoge.js
パースが 停止!
…
JSの読み込み と実行
いくらネットワーク側をチューニングしても、ブロッキングリソースの調整をしなければ意味が無い!
Critical Rendering Pathを短くしたいなら、実はCSSはインライン化した方が良かったり…
もっとつきつめるとレイアウト処理を(ry
もっとつきつめるとレイアウト処理を(ry
もう、やめときます。
ご興味のある方は、どうぞhttps://developers.google.com/speed/pagespeed/
ちなみに
IE9+には裏ワザがあって Visually Completeの取得はなんとかなる!?
http://msdn.microsoft.com/en-us/library/ie/ff974719(v=vs.85).aspx
https://www.google.com/events/io/schedule/session/c8300366-03ed-e311-903f-00155d5066d7
<重要な3つのポイント
https://www.google.com/events/io/schedule/session/c8300366-03ed-e311-903f-00155d5066d7
<重要な3つのポイント
全ての読み込みが完了
※ここはそんなに関心が無い・・・
Load完了後にできることはあるInitial Rendering経過時間
Load完了後にできることはあるInitial Rendering経過時間
Visually Complete
Load完了後にできることはあるInitial Rendering経過時間
Visually Complete
Load Complete
Load完了後にできることはあるInitial Rendering経過時間
Visually Complete
Load Complete
他のWebページのリソースを読み込む
Agenda
3. 近のWeb標準の動向
1. 戦略の立て方
2. 改善の方法
Web Performance Working Group
The mission of the Web Performance Working Group, part of the Rich Web Client Activity, is to provide methods to measure aspects of application performance of user agent features and APIs.
- Webアプリケーションのパフォーマンスに関する、Webの機能を標準化しているW3C内のワーキング・グループ
- 2010年(IE9あたり)の時に結成 - 凄く、凄く、地味だけど、見たことある機能はあるはず
- もうずっと、おわるおわる詐欺
ここで議論しています[email protected]
Webがリッチ化した今 サーバサイドのログじゃ物足りない
リアルなブラウザから パフォーマンスの情報を取得しよう
色んなログをJS上で取得する
パフォーマンス(速度の面)を ミリ秒単位で取得する
Web Timing
色んなログをJS上で取得する
Navigation Timing
Resource Timing
ナビゲー ション全体
リソース 単体
Web Timing
色んなログをJS上で取得する
Navigation Timing
Resource Timing
ナビゲー ション全体
リソース 単体
色んなログをJS上で取得するスピードをロギングするWeb標準 例外をロギングするWeb標準
Navigation Timing Navigation Timing 2
Resource Timing Resource Timing 2
User Timing
ナビゲー ション全体
リソース 単体
任意の ポイント
Navigation Error Logging
Resource Error Logging
Error Logging
※赤字は「W3C勧告」になったもの
timing.unloadEventEnd - timing.unloadEventStart
timing.domContentLoadedEventEnd - timing.domContentLoadedEventStart
timing.loadEventEnd - timing.loadEventStarttiming.redirectEnd - timing.redirectStart
timing.domainLookupStart - timing.fetchStart
timing.domainLookupEnd - timing.domainLookupStart
timing.connectEnd - timing.connectStarttiming.requestStart - timing.connectEnd
timing.responseStart - timing.requestStarttiming.responseEnd - timing.responseStart
timing.domInteractive - timing.domLoading
timing.domComplete - timing.domInteractive
var timing = ( window.performance || {} ).timing;
http://perf.html5j.org/
timing.unloadEventEnd - timing.unloadEventStart
timing.domContentLoadedEventEnd - timing.domContentLoadedEventStart
timing.loadEventEnd - timing.loadEventStarttiming.redirectEnd - timing.redirectStart
timing.domainLookupStart - timing.fetchStart
timing.domainLookupEnd - timing.domainLookupStart
timing.connectEnd - timing.connectStarttiming.requestStart - timing.connectEnd
timing.responseStart - timing.requestStarttiming.responseEnd - timing.responseStart
timing.domInteractive - timing.domLoading
timing.domComplete - timing.domInteractive
var timing = ( window.performance || {} ).timing;
スピードの取得値の粒度を高めるためのWeb標準とか・・・
※赤字は「W3C勧告」になったもの
High Resolution Time High Resolution Time level 2
その取得値を監視サーバに送るための専用のAPIとか・・・
Beacon JSONのフォーマットとか・・・
HTTP Archive format
そんな処理を埋め込むための仕様とか・・・
JavaScript Preflight Injection
取得した値をサーバへ送信!
ブラウザのパフォーマンス改善の 限界を引き上げよう!!
如何にして限界を引き上げるのか?Page Visibility → Page Visibility 2
ブラウザの非アクティブを検知して ポーリング等の処理負荷を減らす
如何にして限界を引き上げるのか?Timing control for script-based animations
ディスプレイのリフレッシュレートに合わせて スクリーン内の描画内容を変えられるようにする
如何にして限界を引き上げるのか?Resource Priorities Resource Hints Prefetch/Prerender
リソース(JS/CSS/画像ファイル等)のネットワーク優先順位を 明示することでCritical Rendering Pathの改善を支援
これは、もういいかなEfficient Script Yielding
コンテキストスイッチを明示的に発生させる
近あった議論や事件のうち 私が面白いと思ったものを
いくつかご紹介
Navigation Error Logging:クラッシュ/フリーズした時のスタックトレースが送れるようになる(かもしれない)。http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0041.html
First Screen Paint In Advance:外部リソース(JS/CSS等)の読み込みを一切行なわずに、HTMLドキュメント上の情報のみを使って先にLayout/Paint処理が行えるようになる(かもしれない)。http://lists.w3.org/Archives/Public/public-web-perf/2014Jun/0005.html
Navigatio Timing:SpeedIndexがそのままJavaScript APIから取得できるようになる(かもしれない)。http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0053.html
あんまり乗り気じゃない感じ…
Smoothness Timing:JSに限らず、CSS等も含めたアニメーションのパフォーマンスも計測できるようになる(かもしれない)。https://rawgit.com/GoogleChrome/websmoothness/master/spec/index.html
iOSでもやっとNavigation Timingを サポートし始めたと思ったら、なんてこったい!…
iOSでもやっとNavigation Timingを サポートし始めたと思ったら、なんてこったい!…
iOSでもやっとNavigation Timingを サポートし始めたと思ったら、やめてしまった。
第1位.iOSでもやっとNavigation Timingを サポートし始めたと思ったら、なんてこったい!
あまりのショックで 次の日とか会社休みたくなりました。
閑話休題
モバイルWebをもっともっと楽しみたいあなたへhttps://atnd.org/events/57562
日本Cordovaユーザ会立ち上げました!! 遊びに来てくださいね
Thank You!@kawada_hiroshi