趣味でつくる​ アバター×アバター​ マッチングアプリ~Performanceチューニング編~​

Transcript

1. 趣味でつくる アバター×アバター マッチングアプリ ~Performanceチューニング編~ BOXP

2. 自己紹介 • 一箱さん (の体を借りたBOXP) • 某Web企業でソフトウェアエン ジニアをしています • 好きなLispはClojureです

3. None

4. 製作中のアプリ • VRChat、Virtual Castなどから 好みのアバターを自動で探して くれるサービス • IPhone・Android向けWebアプリ としてリリース予定 •

   VRじゃなくてごめんなさい • 所謂PWA(Progressive Web Apps)を目指して製作中

5. なぜWeb？ • 無名のアプリなので インストールの手間があるとその まま直帰してしまう… 多くの人に触ってほしい • このスライドも社内勉強会の資料 を再編集したもの 実験的な技術を試して

   業務に活かしたい

6. なぜWeb？ • 無名のアプリなので インストールの手間があるとその まま直帰してしまう… 多くの人に触ってほしい • このスライドも社内勉強会の資料 を再編集したもの 実験的な技術を試して

   業務に活かしたい

7. とは言え インストールの手間がなくても Webページがもっさりしていると 使ってもらえない

8. もっさりしないために Hito Hubで何をしたか

9. 状況に応じて 必要なパフォーマンス を満たす

10. Webアプリ 4つの側面 (RAILモデ ル) • Response: ユーザーの入力に対する応答中の状態 • Animation: アニメーション再生中の状態

    • Idle: ユーザーの入力を待機している状態 • Load: コンテンツ読み込み中の状態 引用元: RAIL モデルでパフォーマンスを計測する https://developers.google.com/web/fundamentals/performance/rail

11. 快適な パフォーマンス の目安 •100ミリ秒以内の応答 •これよりも遅いと操作と反応のズレを感じる Response •10ミリ秒以内に画面をレンダリング •1000ms / 60fps

    - ブラウザによるレンダリング時間 (約6ms) =約10ms Animation •アイドル時間を利用したタスク分担 •100ミリ秒以上かかる処理はアイドル時間まで後回 し •ユーザー入力へのレスポンスが最優先 Idle •読み込みは1000ミリ秒以内に •1000ミリ秒より長いとユーザーの集中力が切れて しまう Load ※Google調べ

12. Hito Hubですべて満たすまで 最適化してみました

13. 全ての入力に対して 100ms以内に応答する 100ms以内に応答が間に合わ ない場合は別の応答を返す • Rippleを表示させるなど 応答処理と他の処理を同時に 実行させない • リソースの取得などは別スレッド

    (WebWorkerなど)で行うか後回しに する Response

14. アニメーションを60fps で動かす アニメーションが必要なカードだけ別 レイヤーに • will-change: transform;スタイルによって別レ イヤーへ • 重ね合わせによるピクセルの計算をスキッ

    プできる 透過・座標移動のみでアニメーション を実現させる • transform,opacityスタイルを使う Animation

15. 読み込み時間を 1秒以内に Load JavaScriptファイルは分割して 必要な分だけロードさせる • 追加のJavaScriptファイルが必要なと きにはじめてロードする 他の画面に必要なファイルを prefetchしておく

    • WebWorkerを使って画面の処理を 邪魔せず先読みしておく

16. 最適化の結果

17. None

18. 最適化の甲斐あって なんとかサクサク動くよう になった

19. ～Fin～

20. 最後に告知的なもの

21. 7月末までにリリース予定！

22. Thanks!