モバイル时代の奥别产パフォーマンス罢颈辫蝉
- 1. モバイル时代の奥别产パフォーマンス罢颈辫蝉 2014/8/22 ? 第2回 ?HTML5minutes！ ? Toru ?Yoshikawa ?(@yoshikawa_?t)
- 2. Who? 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/ 吉川 ?徹 ?/ ?Toru ?Yoshikawa ? @yoshikawa_?t
- 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 ?笔辞蝉颈迟颈辞苍颈苍驳）
- 7. ネイティブとHTML5 Facebookのザッカーバーグが「HTML5は時期尚早 だった」（http://www.publickey1.jp/blog/12/html5html5.html） ? サイバーエージェントがネイティブアプリに注?力力 （http://jp.techcrunch.com/2014/07/24/jp20140724cyberagent/） ? 機能的にはアプリのほとんどは、HTML5での実装 が可能なものにも関わらずネイティブアプリが強い ? モバイルアプリの隆盛とハイブリッドアプリの登場
- 11. API モバイルアプリ（Andorid、US）のうち、61% ?が APIが?足りないためにネイティブアプリを選択して いる ? しかし、Power ?Management ?APIとWi? ?APIが実装 されていれば、そのうちの ?21% ?はWebアプリを選 択する ? ちょっとした?一部機能でAPIが?足りない状況
- 14. Performance 既にデスクトップでは、?十分なパフォーマンスがある ? モバイルはスマートフォンの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で実現する ためのチューニング
- 17. Page ?Load リソースの最適化 ? リクエスト数を抑える ? リダイレクトを避ける ? レンダリングの優先度度
- 18. リソースの最適化 Webサイトのサイズのうち63%は画像 ? 画像を?小さくすれば多くの通信容量量を削減することができる ? 貧弱なモバイル回線ではとても重要 ? ツールを利利?用する ? JPEG: ?jpegtran、jpegoptim ? PNG: ?OptiPNG、PNGOUT ? （私はMacでImageAlpha、ImageOptimを使ってます） ? その他、JS、CSSファイルのminifyなど
- 19. リクエスト数を抑える モバイル回線ではHTTPリクエストは?非常に?高コスト ? 電波状況にもよるが、1リクエスト増えたら200ms?～ 1000ms増えてもおかしくない ? JS、CSSの結合など ? 画像の結合（CSS ?Sprite） ? JS、CSS、画像の埋め込み（data ?URL）など
- 20. DNSプリフェッチ ! 事前にDNS ?Lookupを済ませてキャッシュしておく ? 別ドメインへのアクセスがある場合は?高速化できる かも（SNSボタン等） <link rel="dnp-prefetch" href="example.com">
- 22. レンダリングの優先度度 レンダリングをブロックするリソースを取り除く ? ファーストビューのリソースを再優先に ? 画像の遅延読込みなど（Lazy ?Loadなど） ? スクロールしなければ表?示されない領領域は後回しに ? プログレッシブJPEG、インターレースPNGを使う
- 23. Runtime 変形や透過処理理を抑える ? requestAnimationFrameを使う ? DOMアクセスの最適化 ? メモリの最適化（JavaScript）
- 24. 過度度な装飾は重い ? border-‐??radius、box-‐??shadow、text-‐??shadow、*-‐??gradient などなど ? transformによる変形（移動はそうでもない）、opacityは 特に重い ? とくにアニメーションする場合には注意が必要 ? 場合によっては画像を使うことも検討 変形や透過処理理を抑える
- 26. DOMアクセスの最適化 DOMプロパティを変数のように使わない ? DOMプロパティへのアクセスはレイアウトの再計算など が?走ることがあるため必要最?小限に（必要があれば キャッシュするなど） ? 特に注意が必要なプロパティ ? getComputedStyle()、o?set*系のプロパティ、 client*系のプロパティ、scroll*系のプロパティ
- 27. 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); 毎回、レイアウトの再計算が発生して重い キャッシュ化して高速に
- 28. メモリの最適化 GCが発?生しないようにメモリの使?用量量をコントロールする ? 最初に必要なメモリをすべて確保する、オブジェクトプール を作る（オブジェクトの再利利?用）などの?方法がある ? よくある誤解としては、GCはいったん発?生すると200msの Stop ?the ?worldが発?生すると思われがちだが、最近ではイン クリメンタルGCの採?用で、1度度の停?止は10ms程度度に収まっ ている（その代わり何度度も発?生するので気にしなくて良良いと いうわけではない）
- 31. Extra: ?Service ?Worker オフラインWebアプリケーションのためのAppCache に代わる仕様 ? Webアプリのローカルプロキシとして、バックグラウ ンドプロセスで動作する ? 個別ファイルごとにキャッシュするかどうかを JavaScriptから制御できる ? http://html5experts.jp/myakura/8365/
- 32. Appendix: ?Web ?Components 独?自の要素（例例えばUIパーツなど）を個別に作成、イ ンポートできる仕様 ? 詳細は他のセッションで。 ? 将来的には、ツールでの活?用や、?高品質なコンポーネ ントを再利利?用することによって全体的な品質の底上げ が期待できる ? http://html5experts.jp/1000ch/8906/
- 35. 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-‐???ne-‐??what-‐??we-‐??are-‐??missing-‐?? is-‐??tools/ ? https://www.google.com/events/io/schedule/ session/c8300366-‐??03ed-‐?? e311-‐??903f-‐??00155d5066d7 ?