• Like
スマホ向けWebアプリ開発で使えるフロントエンド高速化手法
Upcoming SlideShare
Loading in...5
×

スマホ向けWebアプリ開発で使えるフロントエンド高速化手法

  • 6,028 views
Uploaded on

第一回Build Insider OFFLINEでの資料です。

第一回Build Insider OFFLINEでの資料です。

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
6,028
On Slideshare
0
From Embeds
0
Number of Embeds
9

Actions

Shares
Downloads
45
Comments
0
Likes
34

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. スマホ向けWebアプリ開発で使えるフロントエンド高速化手法株式会社gloops児玉 映治
  • 2. 2自己紹介• 児玉 映治• 株式会社gloopsUI/UXグループマネージャー兼WEBデザイングループマネージャー• 元々サーバサイドのエンジニア
  • 3. 3弊社紹介• 株式会社gloops• 事業内容:ソーシャルアプリケーション事業• 累計ユーザー数1800万人• 主なタイトル
  • 4. 4アジェンダ1. フロントエンド高速化の基本① ページサイズとHTTPリクエストの軽減② ソースコードの最適化2. ユーザーの体感速度① レンダリング② イベント
  • 5. 51. フロントエンド高速化の基本
  • 6. 6なぜフロントエンドの高速化が必要なのか・ネイティブアプリ並のリッチさとパフォーマンスをスマホのWebアプリにも求められる・UXに直結・継続率、離脱率、売上などに影響
  • 7. 7代表的な高速化の方法・ページサイズを軽くする・HTTPリクエストを減らす・styleは上に、scriptは下に書く・CSSセレクタの最適化・処理速度の速いJavaScriptを書くこことここの話
  • 8. 8① ページサイズとHTTPリクエストの軽減
  • 9. 9ページサイズを軽くする方法・画像最適化・画像をCSSで代用する・minify化、gzip圧縮・キャッシュを使う
  • 10. 10HTTPリクエストを減らす方法・CSSスプライトを使う・DataURIスキームを使う・画像をCSSで代用する・cssファイルや、jsファイルを纏めるここの話
  • 11. 11・HTTPリクエストを一気に減らせるCSSスプライトの特徴・画像の表示は遅い⇒CSSの解釈が終わってから画像を取りに行くため・画像を用意する人とCSSを作る人が別々の場合運用が少々面倒
  • 12. 12DataURIスキームの特徴・CSSスプライトより表示処理は早い・画像ファイルの時より容量が増加する=キャッシュ必須・画像を更新するにはCSSファイルも更新する必要がある=キャッシュクリアされ、初回の読込みに時間がかかる・HTTPリクエストが発生しない
  • 13. 13CSSスプライト・更新頻度が少ない・一つの画面で1回くらいしか使わないそれぞれどう使い分ける?DataURIスキーム・更新頻度が少ない・一つの画面で何度も使う・色数やサイズが小さい
  • 14. 14・ページサイズは何kb?HTTPリクエストは何回?どの程度まで軽減するべきか?・1秒以内を目指す⇒2秒を超えると人は遅いと感じる・速ければ速い程良い・あとはデザインのクオリティと相談
  • 15. 15ページサイズを軽くした結果ページサイズ HTTPリクエスト 時間1120kb 50 1238.36ms725kb 50 1036.88ms508kb 50 910.67ms308kb 50 689.29msあるアプリでのLoadイベントまでの時間※iPhone4S(ios6.1) 3G回線を使用
  • 16. 16HTTPリクエストを減らした結果ページサイズ HTTPリクエスト 時間447kb 80 1006.86ms436kb 50 939.71ms442kb 35 662.50ms
  • 17. 17ページサイズ HTTPリクエスト 時間447kb 80 1006.86ms436kb 50 939.71ms442kb 35 662.50ms
  • 18. 18あるアプリBで、2倍以上の差が発生ページサイズ HTTPリクエスト 時間アプリA 508kb 57 910.67msアプリA 442kb 35 662.50msアプリB 517kb 33 2091.90ms減らすだけでは不十分
  • 19. 19ページサイズとHTTPリクエストを減らしても遅い場合
  • 20. 20② ソースコードの最適化その1. CSS編
  • 21. 21CSSセレクタの高速化・セレクタは右から左へ解釈されるので細かくするよりもシンプルにする方が高速
  • 22. 22計ってみたiPhone4 iPhone5 Galaxy Nexusdiv > div> div > div.hoge432ms 203ms 605ms.hoge 405ms 201ms 595ms1000回実行してみると
  • 23. 23CSSセレクタの高速化・セレクタは右から左へ解釈されるので細かくするよりもシンプルにする方が高速・運用性を重視した方が総合的に見て良い・難解なセレクタ、汎用性のないセレクタ、複雑な構造のHTMLにならないようにする
  • 24. 24セレクタよりも描画処理に注意する・Google Chromeの開発ツールでTimelineを確認するとボトルネックは大抵描画(緑色:Painting)
  • 25. 25・重めのCSS・スマホでCSSスプライトを使う場合RetinaDisplay対応のためにbackground-size指定はほぼ必須⇒スプライト画像が大きいとbackground-sizeの処理も重くなる描画が重くなるCSS
  • 26. 26描画が重い原因を探す・Google Chrome Canaryの開発ツール・CSSプロパティを調整し重い原因を探す
  • 27. 27② ソースコードの最適化その2. JavaScript編
  • 28. 28変数を利用する・DOM, 関数, style, length etc…複数回使うなら変数の中に入れてそっちを使う・必ずvarで宣言してローカル変数にする・基本中の基本・だけど見落としやすい
  • 29. 29変数を利用してDOM操作の回数を減らす
  • 30. 30一度に処理してDOM操作の回数を減らす
  • 31. 31かかる時間はJavaScriptだけではない・DOM操作を行うと、ブラウザ側でもスタイルやレイアウトの再計算が行われている・DOM操作の回数を減らすことでJavaScriptの処理だけでなくブラウザ側の処理も軽くすることができる
  • 32. 32② ソースコードの最適化その3. jQuery編
  • 33. 33jQueryの最適化・jQueryオブジェクトの生成速いのはどっち?
  • 34. 34jQueryの最適化・jQueryオブジェクトの生成○×速いのはどっち?※ただしgetElementsByClassNameが実装されていないブラウザの場合はBが速いスマホの場合はA
  • 35. 35jQueryのセレクタの仕組み① 初めにgetElementBy系が使われる(getElementById, getElementsByClassName, getElementsByTagName)② ①で取れない場合はquerySelectorAllが使われる③ ②でもダメならsizzleエンジンが使われる
  • 36. 36jQueryのセレクタの仕組み① 初めにgetElementBy系が使われる(getElementById, getElementsByClassName, getElementsByTagName)② ①で取れない場合はquerySelectorAllが使われる③ ②でもダメならsizzleエンジンが使われる
  • 37. 37jQueryなどライブラリ利用時の注意点・確かに便利・だけど中でどういう処理がされているのかを知っておくことで、より速い処理を選択することができる
  • 38. 381. フロントエンド高速化の基本 まとめ・様々な高速化の手法が既に公開されている・必ず自分自身で確かめる・しかし自分と全く同じ環境で効果があるとは限らない
  • 39. 392. ユーザーの体感速度
  • 40. 40・ページサイズとHTTPリクエストを軽減すれば速くなる高速化のジレンマ・ある程度まで軽減すると、そこから先はデザインのクオリティが犠牲になる
  • 41. 41デザインのクオリティは下げられない表示速度をこれ以上速くするのは難しい
  • 42. 42① レンダリングユーザーは読み込み中であろうと操作できると思ったら即座に操作を始める操作できると思う部分を先に表示してユーザーにとっての待ち時間を短くする
  • 43. 43・画像のレンダリングは表示方法によって順番が異なる画像のレンダリング順を入れ替える・img要素か、CSSのbackground-imageか・img要素の方が、CSSのbackground-imageより速く表示される(先にレンダリングされる)・速く表示したい部分はimg要素で実装する
  • 44. 44<a href=“#” style=“position:absolute; width:20px; height:20px;overflow:hidden; display:block;”><img src=“sprite.png” width=“100” height=“200” alt=“hoge”style=“position:absolute; top:50px; left:0px;” /></a>スプライト画像を使う・img要素でもスプライト画像は使える※但しHTMLの階層が深くなりやすい
  • 45. 45② イベントユーザーは何かの操作に対する応答が100ms以上かかると違和感を持つユーザーの操作に対して速く応答する
  • 46. 46タップ時のイベントの種類・スマホでのタップ関連のイベントは主に次の6つがあるmousedown, mousemove, mouseuptouchstart, touchmove, touchend
  • 47. 47touchイベントとmouseイベントの違い・PCはtouchイベントが発生しない・スマホでもmouseイベントやclickイベントは発生するが違和感を感じるレベルでtouchイベントよりも遅い・スマホであればtouchイベントを使う何でもかんでもonclickで作らない
  • 48. 48touchstartとtouchend・touchstart⇒指が触れただけで発生するtouchend⇒ディスプレイから指を離すと発生する・モーダルウィンドウやアコーディオンの表示など、瞬時に処理を実行したい場合はtouchstartを使う・ただしスマホの場合、画面をスクロールする時にボタンに触れてしまうことがよくある。画面遷移の実行など全て反応が速ければ良いというわけでもない
  • 49. 492. ユーザーの体感速度 まとめ・基本的な高速化の対応をしたら後はどれだけ気付き、気遣えるか・そのためにはユーザーと同じ目線、通信環境、心理状態になって自分のアプリを触ってみることが必要・ユーザーに取って重要な部分がわかったら、徹底的にそこをチューニングする
  • 50. 503. さいごに
  • 51. 51なぜフロントエンドの高速化が必要なのか・ネイティブアプリ並のリッチさとパフォーマンスをスマホのWebアプリにも求められる・UXに直結・継続率、離脱率、売上などに影響
  • 52. 52なぜフロントエンドの高速化が必要なのか・より良いUXの提供を目指す上で操作時の不自然さは大きな障害・その不自然さを取り除くことが高速化の役割・方法は色々あるので、ユーザー目線に立って根気強くベストプラクティスを探す