モバイル時代のWebパフォーマンス

モバイル時代のWebパフォーマンス 2014/8/30 HTML5とか勉強会 in IWATE Toru Yoshikawa (@yoshikawa_̲t)

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/

PR: HTML教科書 HTML5レベル1 書きました「HTML教科書 HTML5レベル 1」9/17発売！ LPIの資格試験「HTML5プロフェッショナル試験レベル1」対策本です執筆陣: 吉川徹、秋葉葉秀樹、窪⽥田則⼦子、⽩白⽯石俊平 http://www.amazon.co.jp/dp/ 4798135836/

時代はモバイル

モバイルの現状 2014年年の端末出荷台数は当然ながらPCに⽐比べてモバイル（スマフォ＋タブレット）が8倍（Gatner） 2017年年には、タブレット単体でPCの出荷台数を抜く（Gatner）インターネットトラフィックシェアは、2014年年7 ⽉月を堺に逆転（Intelligent Positioning）

http://www.intelligentpositioning.com/blog/2014/01/mobile-and-tablet-traffic-set-to-overtake-desktop-by-mid- 2014/

ネイティブとHTML5 Facebookのザッカーバーグが「HTML5は時期尚早だった」（http://www.publickey1.jp/blog/12/html5html5.html）サイバーエージェントがネイティブアプリに注⼒力力（http://jp.techcrunch.com/2014/07/24/jp20140724cyberagent/）機能的にはアプリのほとんどは、HTML5での実装が可能なものにも関わらずネイティブアプリが強いモバイルアプリの隆盛とハイブリッドアプリの登場

Webアプリ（HTML5）に⾜足りないものはなにか？

mobile vision - How Can HTML Compete with Native?

API モバイルアプリ（Andorid、US）のうち、61% が APIが⾜足りないためにネイティブアプリを選択しているしかし、Power Management APIとWifi APIが実装されていれば、そのうちの 21% はWebアプリを選択するちょっとした⼀一部機能でAPIが⾜足りない状況

Tools、Education スキルセットがない⼈人が実装するのは難しい（スキルセットがある⼈人でも簡単にはできない）まだまだHTML5を使いこなしている⼈人が少ない適当に作っただけでは、⼗十分な品質のアプリが作れない

Performance 既にデスクトップでは、⼗十分なパフォーマンスがあるスマートフォンはPCの1/5の性能であるハードとブラウザの進化によって⽇日々パフォーマンスは向上しているものの、まだまだ過渡期できちんとした作り込みが必要パフォーマンスを向上して、ネイティブアプリに近づける努⼒力力が必要

Google I/O 2014の ”Mobile Web performance auditing”を中⼼心に参考になるTipsを紹介 ! 同じセッションを題材にしたHTML5 Expert.jpの記事 http://html5experts.jp/furoshiki/8582/

パフォーマンスチューニング 2つの視点 Page Load … ページのローディング、表⽰示までのチューニング Runtime … ページ中の動作を60fpsで実現するためのチューニング

Page Load ページのローディング

Page Load リソースの最適化リクエスト数を抑えるリダイレクトを避けるレンダリングの優先度度

リソースの最適化 Webサイトのサイズのうち63%は画像画像を⼩小さくすれば多くの通信容量量を削減することができる貧弱なモバイル回線ではとても重要ツールを利利⽤用する JPEG: jpegtran、jpegoptim PNG: OptiPNG、PNGOUT （私はMacでImageAlpha、ImageOptimを使ってます）その他、JS、CSSファイルのminifyなど

リクエスト数を抑えるモバイル回線ではHTTPリクエストは⾮非常に⾼高コスト電波状況にもよるが、1リクエスト増えたら200ms〜～ 1000ms増えてもおかしくない JS、CSSの結合など画像の結合（CSS Sprite） JS、CSS、画像の埋め込み（data URL）など

DNSプリフェッチ <link rel="dnp-prefetch" href="example.com"> ! 事前にDNS Lookupを済ませてキャッシュしておく別ドメインへのアクセスがある場合は⾼高速化できるかも（SNSボタン等）

リダイレクトを避けるモバイルサイトへのリダイレクトなどを避ける同⼀一のURLで複数のUAに対応したり、レスポンシブにする

WebPageTest http://www.webpagetest.org/

WebPageTestの結果

Page Load Page Loadで重要なのは、ファーストビューが描画されるまでの時間（画⾯面外のレンダリングや画像の読込みなどは体感速度度には影響しない） WebPageTestでは、「Speed Index」が良良い指標になる「Speed Index」は、ファーストビューが描画されるまで平均時間（ミリ秒）

WebPageTestの結果 White screen Visually complete

レンダリングの優先度度レンダリングをブロックするリソースを取り除くファーストビューのリソースを再優先に画像の遅延読込みなど（Lazy Loadなど）スクロールしなければ表⽰示されない領領域は後回しにプログレッシブJPEG、インターレースPNGを使う

Optimizing the Critical Rendering Path https://developers.google.com/web/fundamentals/performance/critical-rendering-path/

Runtime 60Hz > 60fps > 16ms

Chrome DevTools／Timeline Chrome DevToolsを起動（Cmd+Opt+i／Ctrl+Alt+i）して Timelineパネル上で記録、停止（　）。Frames mode（　）で表示

Runtime アニメーションにおいて過度度な装飾を抑える requestAnimationFrameを使う DOMアクセスの最適化メモリの最適化（JavaScript）

アニメーションにおいて過度度な装飾を抑える過度度な装飾は重い border-‐‑‒radius、box-‐‑‒shadow、text-‐‑‒shadow、*-‐‑‒gradient などなどとくにアニメーションする場合には注意が必要場合によっては画像を使うことも検討特定のプロパティを利利⽤用してアニメーションをするように再構築する

Hight Performance Animation http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/

Frames on Chrome DevTools

requestAnimationFrame を使う setIntervalやsetTimeoutでは、単に処理理をスタックさせるだけなので16msのリフレッシュレートに合わせて実⾏行行させるには不不⼗十分⾮非対応ブラウザにはPolyfillもあるので、積極的に requestAnimationFrameを使う

DOMアクセスの最適化 DOMプロパティを変数のように使わない（必要があれば変数に格納） DOMプロパティへのアクセスはレイアウトの再計算などが⾛走ることがあるため必要最⼩小限に（キャッシュを利利⽤用）特に注意が必要なプロパティ getComputedStyle()、offset*系のプロパティ、 client*系のプロパティ、scroll*系のプロパティ

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);

DOMアクセスの最適化 Chrom DevTools > Timelineパネル記録・停止 > 警告マークのレコードをクリック

メモリの最適化 GCが発⽣生しないようにメモリの使⽤用量量をコントロールする最初に必要なメモリをすべて確保する、オブジェクトプールを作る（オブジェクトの再利利⽤用）などの⽅方法があるよくある誤解としては、GCはいったん発⽣生すると200msの Stop the worldが発⽣生すると思われがちだが、最近ではインクリメンタルGCの採⽤用で、1度度の停⽌止は10ms程度度に収まっている（その代わり何度度も発⽣生するので気にしなくて良良いというわけではない）

Writing Fast, Memory-‐‑‒Efficient JavaScript http://www.smashingmagazine.com/2012/11/05/writing-fast-memory-efficient-javascript/

JavaScript Memory Management Masterclass https://speakerdeck.com/addyosmani/javascript-memory-management-masterclass

その他

PageSpeed Insight http://developers.google.com/speed/pagespeed/insights/

Extra: Service Worker オフラインWebアプリケーションのためのAppCache に代わる仕様 Webアプリのローカルプロキシとして、バックグラウンドプロセスで動作する個別ファイルごとにキャッシュするかどうかを JavaScriptから制御できる http://html5experts.jp/myakura/8365/

Appendix: Web Components 独⾃自の要素（例例えばUIパーツなど）を個別に作成、インポートできる仕様詳細は他のセッションで。将来的には、ツールでの活⽤用や、⾼高品質なコンポーネントを再利利⽤用することによって全体的な品質の底上げが期待できる http://html5experts.jp/1000ch/8906/

ネイティブとの差を埋めてよりよいHTML5ライフを

Thank you!! (@yoshikawa_̲t)

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

モバイル時代のWebパフォーマンス

by yoshikawa_t

on Aug 30, 2014

Statistics

Views

Actions

1 Embed 12

Accessibility

Categories

Upload Details

Usage Rights

Report content

モバイル時代のWebパフォーマンス Presentation Transcript