モバイル時代のWebパフォーマンス
78 likes18,652 views
2014/8/30に開催された「HTML5とか勉強会 in IWATE 2014」のセッション資料です。
More Related Content
What's hot (20)
Viewers also liked (20)
Similar to モバイル時代のWebパフォーマンス (20)
More from yoshikawa_t (15)
Recently uploaded (13)
![ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]](https://cdn.slidesharecdn.com/ss_thumbnails/searchtech-250228102455-ddc5ce09-thumbnail.jpg?width=560&fit=bounds)
モバイル時代のWebパフォーマンス
- 1. モバイル時代のWebパフォーマンス 2014/8/30 HTML5とか勉強会 in IWATE Toru Yoshikawa (@yoshikawa_̲t)
- 2. Who? 吉川 徹 / Toru Yoshikawa @yoshikawa_̲t html5j 代表／html5jビギナー部 (副部⻑⾧長) Google Developer Experts (Chrome) HTML5 Experts.jp エキスパート Web先端技術味⾒見見部 (顧問)／⽇日本jQuery Mobileユーザー会 (管理理⼈人)／Sublime Text 2 Japan Users Group (管理理⼈人)など など Blog: http://d.hatena.ne.jp/pikotea/
- 3. PR: HTML教科書 HTML5レベル1 書きました 「HTML教科書 HTML5レベル 1」9/17発売！ LPIの資格試験「HTML5プロフェッ ショナル試験 レベル1」対策本です 執筆陣: 吉川 徹、秋葉葉 秀樹、窪⽥田 則⼦子、⽩白⽯石 俊平 http://www.amazon.co.jp/dp/ 4798135836/
- 4. 時代はモバイル
- 5. モバイルの現状 2014年年の端末出荷台数は当然ながらPCに⽐比べて モバイル（スマフォ＋タブレット）が8倍 （Gatner） 2017年年には、タブレット単体でPCの出荷台数を 抜く（Gatner） インターネットトラフィックシェアは、2014年年7 ⽉月を堺に逆転（Intelligent Positioning）
- 7. ネイティブとHTML5 Facebookのザッカーバーグが「HTML5は時期尚早 だった」（http://www.publickey1.jp/blog/12/html5html5.html） サイバーエージェントがネイティブアプリに注⼒力力 （http://jp.techcrunch.com/2014/07/24/jp20140724cyberagent/） 機能的にはアプリのほとんどは、HTML5での実装 が可能なものにも関わらずネイティブアプリが強い モバイルアプリの隆盛とハイブリッドアプリの登場
- 9. mobile vision - How Can HTML Compete with Native?
- 11. API モバイルアプリ（Andorid、US）のうち、61% が APIが⾜足りないためにネイティブアプリを選択して いる しかし、Power Management APIとWifi APIが実装 されていれば、そのうちの 21% はWebアプリを選 択する ちょっとした⼀一部機能でAPIが⾜足りない状況
- 13. Tools、Education スキルセットがない⼈人が実装するのは難しい（ス キルセットがある⼈人でも簡単にはできない） まだまだHTML5を使いこなしている⼈人が少ない 適当に作っただけでは、⼗十分な品質のアプリが作 れない
- 14. Performance 既にデスクトップでは、⼗十分なパフォーマンスがある スマートフォンはPCの1/5の性能である ハードとブラウザの進化によって⽇日々パフォーマンス は向上しているものの、まだまだ過渡期できちんとし た作り込みが必要 パフォーマンスを向上して、ネイティブアプリに近づ ける努⼒力力が必要
- 15. Google I/O 2014の ”Mobile Web performance auditing”を 中⼼心に参考になるTipsを紹介 ! 同じセッションを題材にしたHTML5 Expert.jpの記事 http://html5experts.jp/furoshiki/8582/
- 16. パフォーマンスチューニング 2つの視点 Page Load … ページのローディング、表⽰示まで のチューニング Runtime … ページ中の動作を60fpsで実現する ためのチューニング
- 18. Page Load リソースの最適化 リクエスト数を抑える リダイレクトを避ける レンダリングの優先度度
- 19. リソースの最適化 Webサイトのサイズのうち63%は画像 画像を⼩小さくすれば多くの通信容量量を削減することができる 貧弱なモバイル回線ではとても重要 ツールを利利⽤用する JPEG: jpegtran、jpegoptim PNG: OptiPNG、PNGOUT （私はMacでImageAlpha、ImageOptimを使ってます） その他、JS、CSSファイルのminifyなど
- 20. リクエスト数を抑える モバイル回線ではHTTPリクエストは⾮非常に⾼高コスト 電波状況にもよるが、1リクエスト増えたら200ms〜～ 1000ms増えてもおかしくない JS、CSSの結合など 画像の結合（CSS Sprite） JS、CSS、画像の埋め込み（data URL）など
- 21. DNSプリフェッチ <link rel="dnp-prefetch" href="example.com"> ! 事前にDNS Lookupを済ませてキャッシュしておく 別ドメインへのアクセスがある場合は⾼高速化できる かも（SNSボタン等）
- 24. WebPageTestの結果
- 25. Page Load Page Loadで重要なのは、ファーストビューが描 画されるまでの時間（画⾯面外のレンダリングや画 像の読込みなどは体感速度度には影響しない） WebPageTestでは、「Speed Index」が良良い指 標になる 「Speed Index」は、ファーストビューが描画さ れるまで平均時間（ミリ秒）
- 26. WebPageTestの結果 White screen Visually complete
- 27. レンダリングの優先度度 レンダリングをブロックするリソースを取り除く ファーストビューのリソースを再優先に 画像の遅延読込みなど（Lazy Loadなど） スクロールしなければ表⽰示されない領領域は後回しに プログレッシブJPEG、インターレースPNGを使う
- 28. Optimizing the Critical Rendering Path https://developers.google.com/web/fundamentals/performance/critical-rendering-path/
- 29. Runtime 60Hz > 60fps > 16ms
- 30. Chrome DevTools／Timeline Chrome DevToolsを起動（Cmd+Opt+i／Ctrl+Alt+i）して Timelineパネル上で記録、停止（ ）。Frames mode（ ）で表示
- 31. Runtime アニメーションにおいて過度度な装飾を抑える requestAnimationFrameを使う DOMアクセスの最適化 メモリの最適化（JavaScript）
- 32. アニメーションにおいて過 度度な装飾を抑える 過度度な装飾は重い border-‐‑‒radius、box-‐‑‒shadow、text-‐‑‒shadow、*-‐‑‒gradient などなど とくにアニメーションする場合には注意が必要 場合によっては画像を使うことも検討 特定のプロパティを利利⽤用してアニメーションをするように 再構築する
- 33. Hight Performance Animation http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
- 34. Frames on Chrome DevTools
- 35. requestAnimationFrame を使う setIntervalやsetTimeoutでは、単に処理理をスタックさせ るだけなので16msのリフレッシュレートに合わせて実⾏行行 させるには不不⼗十分 ⾮非対応ブラウザにはPolyfillもあるので、積極的に requestAnimationFrameを使う
- 36. DOMアクセスの最適化 DOMプロパティを変数のように使わない（必要があれば 変数に格納） DOMプロパティへのアクセスはレイアウトの再計算など が⾛走ることがあるため必要最⼩小限に（キャッシュを利利 ⽤用） 特に注意が必要なプロパティ getComputedStyle()、offset*系のプロパティ、 client*系のプロパティ、scroll*系のプロパティ
- 37. DOMアクセスの最適化 毎回、レイアウトの再計算が発生して重い setInterval(function(){ div.style.left = (div.offsetLeft + 1) + 'px'; }, 1000/60); キャッシュ化して高速に var cache = div.offsetLeft; setInterval(function(){ cache++; div.style.left = cache + 'px'; }, 1000/60);
- 38. DOMアクセスの最適化 Chrom DevTools > Timelineパネル 記録・停止 > 警告マークのレコードをクリック
- 39. メモリの最適化 GCが発⽣生しないようにメモリの使⽤用量量をコントロールする 最初に必要なメモリをすべて確保する、オブジェクトプール を作る（オブジェクトの再利利⽤用）などの⽅方法がある よくある誤解としては、GCはいったん発⽣生すると200msの Stop the worldが発⽣生すると思われがちだが、最近ではイン クリメンタルGCの採⽤用で、1度度の停⽌止は10ms程度度に収まっ ている（その代わり何度度も発⽣生するので気にしなくて良良いと いうわけではない）
- 40. Writing Fast, Memory-‐‑‒Efficient JavaScript http://www.smashingmagazine.com/2012/11/05/writing-fast-memory-efficient-javascript/
- 41. JavaScript Memory Management Masterclass https://speakerdeck.com/addyosmani/javascript-memory-management-masterclass
- 42. その他
- 45. Extra: Service Worker オフラインWebアプリケーションのためのAppCache に代わる仕様 Webアプリのローカルプロキシとして、バックグラウ ンドプロセスで動作する 個別ファイルごとにキャッシュするかどうかを JavaScriptから制御できる http://html5experts.jp/myakura/8365/
- 46. Appendix: Web Components 独⾃自の要素（例例えばUIパーツなど）を個別に作成、イ ンポートできる仕様 詳細は他のセッションで。 将来的には、ツールでの活⽤用や、⾼高品質なコンポーネ ントを再利利⽤用することによって全体的な品質の底上げ が期待できる http://html5experts.jp/1000ch/8906/
- 49. Resources HTML5 Experts.jp 「Google I/O 2014 特集」 http://html5experts.jp/series/google-‐‑‒io-‐‑‒2014-‐‑‒2/ http://www.visionmobile.com/blog/2013/12/html5-‐‑‒performance-‐‑‒ is-‐‑‒fine-‐‑‒what-‐‑‒we-‐‑‒are-‐‑‒missing-‐‑‒is-‐‑‒tools/ https://www.google.com/events/io/schedule/session/ c8300366-‐‑‒03ed-‐‑‒e311-‐‑‒903f-‐‑‒00155d5066d7