ウェブパフォーマンスの基礎とこれから
•
627 j'aime•111,683 vues
ウェブパフォーマンスの基礎と今後の動向について、Web標準周りを中心に解説しています。GREEのMini Tech Talkで発表時の資料です。
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à ウェブパフォーマンスの基礎とこれから
Similaire à ウェブパフォーマンスの基礎とこれから (20)
Dernier
ウェブパフォーマンスの基礎とこれから
- 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. ウェブの仕組み
- 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ミリ秒
- 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も参考のこと
- 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本
- 20. モバイルはなぜ遅いのか？ あげく、通信は全機能の中で2番目にバッテリー消費が大きいため、通常は節電のために非アクティブ化されます Power On モバイルの場合、ネットワークインタフェースは普段OFFになる! 接続前にONにしなくてはいけない… ※ここで言うネットワーク・インタフェースは Push Notificationで利用されるものとは別のもの!! OMG :( HTTP+TCP+IPレイヤー物理レイヤー
- 27. 2. パフォーマンスの計測
- 32. どういう状態を遅いというのか？ 平均値で評価するとσ(信頼性)の大きさやμ(遅さ)が見えません。ここはパーセンタイルで評価するのが一般的です 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秒超え!?これが原因? 読込時間(ミリ秒)
- 35. 欲しい情報(母集団)に含まれる値を”標本”を呼びますが、それの質が低いと母集団は推測できません ↓この人はなぜ、遅いと感じたのか？ 標本がなければ推測できない 仮説1) 100回に1度のとても悪いタイミングにあたり、 その瞬間だけは確かに遅かった。 仮説2) アクセス数が多くてサーバ負荷が高いため、 その時間帯は常に全ユーザが読み込みが遅かった。 仮説3) CSSの読み込みが遅く描画をブロックするため、 常に遅く描画された。 特定の時間に 偏りのあるサンプルは 使い物にならない HTML読込時間は 使いものにならない
- 38. サービスがゴマンとあるわけですが、私はオープンソースの人なのでよくわかりません！オススメ、教えてください 私が知っている範囲(知人レベル)で有償系： 無料系： オープンソース系 Make the Web Faster PageSpeed Insights modern.ie Site Scan →モバイル系 @massieさんのところが もいちょっとしたら…多分 →Webサイト系 @takehoraさんが 代理店で販売 Yahoo! Boomerang →恐らく停滞 →よく目にする… 標本がなければ推測できない
- 40. Web制作者、アプリ開発者向け 制約こそあるがMicrosoftらしい親切さがある 特徴 1. 検査項目がかなり豊富 2. 日本語対応、説明が親切 3. MS製品と相性がいい 4. モバイルとデスクトップは 同じWebページが前提 modern.ie Site Scan 計測とかよくわからない！そういう人は、とりあえずこのサービスに頼ってみてください
- 41. Webpagetest アプリ開発者、インフラエンジニア向け オープンソースでGoogleのアイデアが入っている 特徴 1. 指標値がかなり豊富 2. 自前のサーバで使える 3. OSS系ブラウザが使える ガッチガチに数値と睨めっこしたいひとは、このOSS製品がかなりオススメです 4. モバイルとデスクトップは 別々に対応してOK
- 44. ブラウザ上での計測 例えば、Webページ読み込み時に発生する様々な事象がいつ起きたのか？これはもう標準で定義されています ハイパーリンクのクリック。 ナビゲーションの手続き開始。 ビュー内が白くなり、 DOMの読み込みを開始。 全てのコンテンツの読み込みが完了し、 JSイベントを実行。 Navigation Start DOM Loading Load Event Start ex. 1427014713416 1427014719823 + 6,407 ms 1427014803940 + 84,117 ms
- 46. 旧時代的かつもっとも実用的な仕様： Navigation Timing 2010年、IE9に実装すべくかなりの早さで仕様を固めたのがNavigation Timingです。実用的ですが、まもなく消えます ブラウザ上での計測 Webページ遷移時のパフォーマンス 計測方法と値の定義 JavaScript APIの仕様 W3C勧告で安定しているけど 数年後には人々の記憶から失われることになる
- 48. これからのパフォーマンス計測の標準と言えば： Performance Timelineと… 次世代は、Performance Timelineという仕組みを通じて、様々な計測値が高精度で取得できるようになります ブラウザ上での計測 ＋Navigation Timing 2 ＋Resource Timing ＋Frame Timing ＋User Timing ＋Server Timing 計測対象とその仕様 精度に関する仕様 ＋High Resolution Time ＋High Resolution Time 2 ※注:APPENDIX-2も参考のこと
- 55. 巨大なファイルのアップロードやダウンロードも、ユースケースに含めていく方針です ブラウザ上での計測 5. 巨大ファイルのダウン/アップロードも計測する!(これから) ブラウザ サーバ ZIP 動画 画像 Resource Timing
- 56. Power On モバイル固有の問題にだって、対応していく予定です ブラウザ上での計測 6. モバイルをしっかりと捉える!(これから) ネットワーク インタフェースの 活性化の時間も可視化 Navigation Timing 2
- 58. 3. パフォーマンスの改善
- 59. HTTP1.x
- 60. HTTP1.xの時代、通信効率を上げることについて、TCP接続がネックになっていました HTTP1.xのインフラ戦略 通信時間を短縮したい!! ・TCP接続のオーバヘッドを減らす → KeepAlive ・接続後の通信量を減らす → gzip ・既にロードしたことある場合は読み込まない → Expires 通信効率を上げたい!! ・JS/CSSファイル数を減らす → Concat ・画像ファイル数を減らす → CSS Sprite ・ファイル読込の並列性を上げる → ドメインシャーディング
- 62. SPDY?
- 64. HTTP/2
- 66. 通信周りに対する問題は、HTTP/2の登場である程度解決してくれるらしいです。らしい？何が言いたいかと言うと 通信時間を短縮したい!! ・TCP接続のオーバヘッドを減らす → HTTP/2 !? ・接続後の通信量を減らす → HTTP/2 !? ・既にロードしたことある場合は読み込まない → HTTP/2 !? 通信効率を上げたい!! ・JS/CSSファイル数を減らす → HTTP/2 !? ・画像ファイル数を減らす → HTTP/2 !? ・ファイル読込の並列性を上げる → HTTP/2 !? HTTP/2世代のインフラ戦略 …ええ、怖いですよ。
- 70. 画面を描画する過程、読み込むファイルの中の作りにまで踏み込んで見えるのは、アプリ開発者だけです HTML5世代のアプリケーション戦略 Navigation Start Unload First Paint DOMContentLoaded Above to fold(ATF) Loaded → クリック or サブミット → 画面を白くする → 描画を開始する → DOMの読み込みを完了する → 最初に見えるスクリーン内の描画を完了する HTML JS/CSSJS/CSSJS/CSS ImageImageImage
- 71. First Viewの最適化 ・Resource Priorities ファイル(リソース)の読み込み優先度の制御 ・Resource Hints 別ページで使われるファイルやページ全体を先読み Repeat Viewの最適化 ・Service Worker オンライン時の振る舞い・キャッシュの細かい制御 作りを把握した上で、アプローチする方法も日々生み出されています HTML5世代のアプリケーション戦略
- 73. 4. 最後に
- 75. ・Google - Ilya Grigorik一派 →実装最速 ・Microsoft - Tobin Titus一派 →実装速度は2番手ぐらい。かなり速い方。 ・Mozilla →少し後ろを走りつつも追っている。 ・Apple → ＼(^o^)／ 肝心のアダプションについて しかも残念なことに、Appleは全くもってパフォーマンス系の機能をサポートしてくれません
- 76. モバイル…無理なのか!?
- 77. ところが…
- 79. 喜ぶ人々。
- 80. ・Google - Ilya Grigorik一派 →実装最速 ・Microsoft - Tobin Titus一派 →実装速度は2番手ぐらい。かなり速い方。 ・Mozilla →少し後ろを走りつつも追っている。 ・Apple - Ryosuke Niwa一派!? → 2015年は本気出す…!? 2015年も パフォーマンスの技術はもっと良くなる!! 肝心のアダプションについて これからAppleもパフォーマンス系の機能に力を入れてくれそうで、2015年もますます発展が期待できそうです
- 82. APPENDIX-1 TCP Fast Open(TFO) → クライアント サーバ …こんなの、私の知っているTCPじゃない けど、なんかわくわくする!! syn + HttpRequest ack + HttpResponse TCPデータ
- 87. 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
- 88. 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
- 89. 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