ウェブパフォーマンスの基礎とこれから
Mar. 22, 2015•0 likes•111,639 views
Download to read offline
Report
Technology
ウェブパフォーマンスの基礎と今後の動向について、Web標準周りを中心に解説しています。GREEのMini Tech Talkで発表時の資料です。
Hiroshi KawadaFollow
More Related Content
What's hot
学生時代に知っておきたかったWeb技術の学び方の学び方 | リブセンスLivesense Inc.
スクラムの知られざる勘所Yoshifumi Tsuda
事業の進展とデータマネジメント体制の進歩（＋プレトタイプの話）Tokoroten Nakayama
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveTokoroten Nakayama
Qua s tom-メトリクスによるソフトウェアの品質把握と改善Hironori Washizaki
フロー効率性とリソース効率性、再入門 #devlove #devkanItsuki Kuroda
Viewers also liked
Sails workshop2Tomokatsu Iguchi
Sails workshop3Tomokatsu Iguchi
Sails workshop1Tomokatsu Iguchi
Sails workshop4Tomokatsu Iguchi
技術選択とアーキテクトの役割Toru Yamaguchi
偶然にも500万個のSSH公開鍵を手に入れた俺たちはYoshio Hanawa
Similar to ウェブパフォーマンスの基礎とこれから
20141003 webマーケティングエンジニアリングInnova Inc.
Html5時代のクリエイターのあり方Masakazu Muraoka
Cloudflareを活用したWebパフォーマンスチューニングYoichiro Takehora
アジャイルソフトウェア開発の道具箱Koichi ITO
![[Observability conference 2022/3/11] NewsPicks のプロダクト開発エンジニアが実践するスキルとしての SRE](https://cdn.slidesharecdn.com/ss_thumbnails/observabilityconference2022311newspickssre-220310143345-thumbnail.jpg?width=384&height=256&fit=bounds)
[Observability conference 2022/3/11] NewsPicks のプロダクト開発エンジニアが実践するスキルとしての SREIida Yukako
デブサミ2013【14-E-2】パフォーマンス・チューニングに革命をもたらす最新テクノロジー － トランザクショントレースDevelopers Summit
![[Observability conference 2022/3/11] NewsPicks のプロダクト開発エンジニアが実践するスキルとしての SRE](https://cdn.slidesharecdn.com/ss_thumbnails/observabilityconference2022311newspickssre-220310143345-thumbnail.jpg?width=1600&height=908&fit=bounds)
![[GrapeCity Web TECH FORUM 2018]グレープシティJavaScript製品のご紹介 活用のコツと開発のポイント](https://cdn.slidesharecdn.com/ss_thumbnails/grapecity-webtechforum20181207-181225045631-thumbnail.jpg?width=1600&height=908&fit=bounds)
Recently uploaded
遠征ドルヲタのための便利サイトを作ってみたKenta Fujimoto
拡散する画像生成.pdfNTTDOCOMO-ServiceInnovation
CatBoost on GPU のひみつTakuji Tahara
MLOps Course Slides_JP（配布用）.pdfYuya Yamamoto
インフラチームとCCoEの関係.pptxssuser5c7ee4
磁石内臓イヤリングによる磁力変化を利用したジェスチャ識別sugiuralab
ウェブパフォーマンスの基礎とこれから
- 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