ブラウザのパフォーマンスを限界まで高める htmlコーディングの考え方

ブラウザのパフォーマンスを限界まで高める 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. 改善の方法

Webを取り巻く環境は酷くなった！？• •

コンシューマーのメインコンピューター → スマートデバイス＆無線へ

Wifiという辛い現実ナビゲーション・・・

Androidという辛い現実ランタイム　　・・・

(画面遷移)

(アニメーション)



ネットワーク環境の悪化ナビゲーション・・・

ハードウェア環境の悪化ランタイム　　・・・

(画面遷移)




パフォーマンスを考えてモノを作ることが重要になった

ナビゲーション・・・

ランタイム　　・・・

(画面遷移)



ネットワーク環境の悪化

ハードウェア環境の悪化


ナビゲーション・・・(画面遷移)

↑今日はこちらのお話をします


ネットワーク環境の悪化


パフォーマンスの戦略を立てる上でとてもとても重要なこと

それは・・・

頑張り過ぎないこと。

職人魂が犯す罪は重いのですユーザの待ち時間

エンジニアの改善作業時間



ユーザの満足

エンジニアが幸せになれる程度の時間


エンジニアの幸せが危険に曝される時間

過剰気味エンジニアの

改善作業時間


エンジニアの生活が崩壊した廃人コース

職人の世界


職人魂が犯す罪は重いのですユーザの待ち時間パフォーマンス改善は果てがない

一から十まで全部を求められない


エンジニアの生活が崩壊した廃人コース

職人の世界

職人魂が犯す罪は重いのですユーザの待ち時間時間をかけるほど

得られる効果が小さくなる


どれぐらい頑張るかをあらかじめ決める

ポイント

どれぐらい頑張ったらいい？

例）


出来る限り速くなるまで例）


出来る限り速くなるまで✕例）

だいたい1秒ぐらい


出来る限り速くなるまで✕

△

例）

だいたい1秒ぐらい

平均1秒以下になるように


出来る限り速くなるまで✕だいたい1秒ぐらい△

平均1秒以下になるように△

全て1秒以下！

例）




全て1秒以下！はやめておいて

例）




90パーセンタイルで1秒以下になるように• • • • • • •

◯

例）

パーセンタイル？

分位数

レアケースを取り除くということ• • • •

参考：HTML5 NIGHT 08. Web × パフォーマンス技術 http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625

http://www.slideshare.net/takehora/html5-day-lt-2014-0614-35865625


このあたりは過剰に反応しない！



まずはここを見よ！



まずはここを見よ！

これこそが、パーセンタイル！


「パーセンタイル」とは？例えば、100件の表示タイムのサンプルがあった場合

「パーセンタイル」とは？

下から90番目のタイム(=90パーセンタイル)

例えば、100件の表示タイムのサンプルがあった場合

ボトルネックを探す

時間がかかっている箇所を探りブレークダウンしていく


←※注：これが真因ではありません！

ウォーターフォール図


「特徴」を探ろう！

おやっ、何かがおかしい！？例えば、100件の表示タイムのサンプルがあった場合

なんか上位5%の「遅い」がいつも同じ値なんだけど・・・


おやっ、何かがおかしい！？

例）


タイムアウト待ってる処理がある・・・

※注：これが真因ではありませんが。。。

おやっ、何かがおかしい！？


いやいや、こんなに速いわけが無いでしょ？


うぉっ、何かがおかしい！？

例）


お！？なんかエラーが！？

※注：これが真因ではありませんが。。。

うぉっ、何かがおかしい！？


パフォーマンス改善の戦略を決める上で必要になる情報

・何秒かかったか？ボトルネックはどこか？・どんなエラーが出ていたのか？ログは？

Agenda



2. 改善の方法

何をもって速いと考えるか？

Google I/O 2014にてPaul Lewis氏

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


Web Server

DNS Server


Program

Web Server

DNS Server


Program

リダイレクトです・・・

DNS Server

名前解決開始DNS

ServerDNS ServerDNS ServerDNS Server

DNS Server


DNS Server

DNS ServerDNS ServerDNS ServerDNS Server名前解決完了

Web ServerTCP Connection

接続完了

DNS Server


Web Server

DNS Server


Program

Webページある！

Web Server

DNS Server


ProgramBuffer

Web Server

DNS Server


ProgramBufferBuffer

Web Server

DNS Server


ProgramBufferBufferDOM

Web Server

DNS Server


ProgramBufferBufferDOM

Initial Renderingの開始

バッファサイズデフォルトでやっている場合は

バッファサイズ

nginx … 0x1ff8 Byte (約8KB)

デフォルトでやっている場合は




apache … 0x2000 Byte (8KB)




gws … 0x8000 Byte (32KB)→シェア低





gws … 0x8000 Byte (32KB)→シェア低


JSP他 … 0x2000 Byte (8KB)つまり

HTMLドキュメント(HTTPヘッダの一部を含む)

の初の約8KBがサーバ上で生成されブラウザ側にそれが転送完了した瞬間ブラウザは初のレンダリングを開始する

・・・と、HTMLコーディングする人はそう考えたらいいと思う。

DevツールのTimelineタブだとHTMLドキュメントの処理過程はこんな感じに見える


実サーバにHTTPリクエスト送信


実サーバにHTTPリクエスト送信実サーバからHTTPレスポンス応答

※8KB貯めてから送っているのに、結局Receive DataとHTML Parseが 4KB単位で処理されてしまうところがなかなか面白いポイント！(ヒント：MTU)



HTMLドキュメントを4KBずつ貰う





HTMLドキュメントを4KBずつパース






レイアウト処理(CPU使って頑張る)






レイアウト処理(CPU使って頑張る)

ペイント処理(GPU使って頑張る)

対策に必要なこと・DNSの適化　→ TTLの見直し等・リダイレクトの適化　→ Desktop/Mobileの切り替え処理の見直し、リライト等・TCP/SSLの接続の適化　→ アクセラレータの導入、ローバランサー　等・ファーストバイトダウンロードの適化　→ HTMLファイル8KB分を先に送る

などなど



見た目が完成している状態(スクリプト実行は含まない)

・ユーザが一番関心を持つ。(=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本の接続数を大限に活かして、

リソースを読み込もう。

キューの中で待機

まだ待機

利用中

利用中

利用中



リソースを読み込もう。(→ドメインを分けるという逃げ道も)

だから、楽しい！！

キューの中で待機

まだ待機

利用中

利用中

利用中



リソースを読み込もう。

HTTP2.0やSPDYは、また別のモデルになるのですが…

JS/CSSはHTMLパースを阻害する

hoge.js

hoge.jshoge.jshoge.js

パースが停止！

…

JSの読み込みと実行


hoge.js



…


いくらネットワーク側をチューニングしても、ブロッキングリソースの調整をしなければ意味が無い！


hoge.js



…


いくらネットワーク側をチューニングしても、ブロッキングリソースの調整をしなければ意味が無い！

Critical Rendering Pathを短くしたいなら、実はCSSはインライン化した方が良かったり…

もっとつきつめるとレイアウト処理を(ry

もっとつきつめるとレイアウト処理を(ry

もう、やめときます。

ご興味のある方は、どうぞhttps://developers.google.com/speed/pagespeed/

https://developers.google.com/speed/pagespeed/

ちなみに

IE9+には裏ワザがあって Visually Completeの取得はなんとかなる！？

http://msdn.microsoft.com/en-us/library/ie/ff974719(v=vs.85).aspx



全ての読み込みが完了

※ここはそんなに関心が無い・・・

Load完了後にできることはあるInitial Rendering経過時間


Visually Complete


Visually Complete

Load Complete


Visually Complete

Load Complete

他のWebページのリソースを読み込む

Agenda



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]

mailto:[email protected]

Webがリッチ化した今サーバサイドのログじゃ物足りない

リアルなブラウザからパフォーマンスの情報を取得しよう

色んなログをJS上で取得する

パフォーマンス(速度の面)をミリ秒単位で取得する

Web Timing


Navigation Timing

Resource Timing

ナビゲーション全体

リソース単体

Web Timing


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

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

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

あんまり乗り気じゃない感じ…

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

https://rawgit.com/GoogleChrome/websmoothness/master/spec/index.html

iOSでもやっとNavigation Timingをサポートし始めたと思ったら、なんてこったい！…

iOSでもやっとNavigation Timingをサポートし始めたと思ったら、やめてしまった。

第１位.iOSでもやっとNavigation Timingをサポートし始めたと思ったら、なんてこったい！

あまりのショックで次の日とか会社休みたくなりました。

閑話休題

モバイルWebをもっともっと楽しみたいあなたへhttps://atnd.org/events/57562

日本Cordovaユーザ会立ち上げました!! 遊びに来てくださいね

Thank You!@kawada_hiroshi

ブラウザのパフォーマンスを限界まで高める htmlコーディングの考え方

Technology