Rail というUIパフォーマンスモデル

Transcript

1. RAILという UIパフォーマンスモデル User中心
2. By － 2015年中から － Fluentカンファレンスに発表があった。 － ユーザを中心にしたアプリのパフォーマンスモデ ル。 － Chromeチームから生まれたもので話はWebアプリに寄りがち。 － ネイティブアプリでも使える。
3. パフォーマンス 対 成功性 パフォーマンス 遅すぎる ユーザ退場 ま〜ま〜 ユーザ残る サクサク ユーザ喜ぶ サクサク ROI? 成 功 性
4. パフォーマンス 対 成功性 パフォーマンス サクサク ユーザ喜ぶ 成 功 性 遅すぎる ROI 減少
5. － 遅いって何？50msは遅い？速い？ 　⇒ ユーザはどう感じる？
6. ユーザが感じる：返事 遅延 所感 0 - 100 ms 即刻 100 - 1000 ms 集中切れず遅延を感じる 1000+ ms 脳コンテキストスイッチ 10,000+ ms また今度
7. ユーザが感じる：アニメーション 24 FPS（~40 ms） 違和感がない 60 FPS（~16 ms） サクサク感じる ただし、全体のFPSに統一感が無ければ FPS をさげて統 一感を守った方がユーザに優しい。 ※FPS：Frame Per Second
8. アプリ内のフロー：アクション目線 読んでいる・考えている ステート変更 進捗表示 ナビゲーション クリック トランジション ドラッグ スクロール 読み込み Idle Animation Response Load
10. Response － Tap to Paint：100ms － 100ms以内、ユーザのインプットに対してフィード バックを － 300ms以上かかりそうなら、その旨もフィードバック で伝える － 逆目線：100msが経つまで処理してもユーザは気づかない
11. Response：GChrome風 onListItemClick() { let spinnerTimeout = setTimeout(showSpinner, 300); loadDetailsData().then(data => { clearTimeout(spinnerTimeout); hideSpinner(); transitionToDetailsView(data); } }
12. Animation － 16ms － ブラウザやOSの処理もあるから8msぐらいまで狙った方が良い － 実現するのは難しい ⇒ アニメーション中は処理をしないのがベストプラク ティス － iOS 対 Android も昔でその面で大きく違った － GChrome風：FLIP ※詳細説明は後ほど
13. Idle － バックグラウンド処理はここでする！ － ユーザは操作していないけどするかも？のスタンスで ⇒ 50msで終わる単位で － ユーザが操作しだした時に即刻（100ms以内）に応えられるため
14. Idle：GChrome風 － requestIdleCallback － Chromeのみ（47＋） － 標準化されていないがEDはある － https://w3c.github.io/requestidlecallback/ Window.requestIdleCallback(callback[, options]);
15. Idle：GChrome風 let tasks = []; let MIN_TASK_TIME = 20; function handleTasks(deadline) { while (tasks.length && deadline.timeRemaining() > MIN_TASK_TIME) processTask(tasks.pop()); if (tasks.length) requestIdleCallback(handleTasks); } requestIdleCallback(handleTasks);
16. Load － ユーザのインプットのゴールを達成する － 1s：意味のあるペイントまでの時間 － 実現するのは難しい － 1s 以内にすべてを表示する必要はない － キャッシング（Service Worker）、ストリーミング等 － クリティカルレンダリングパスに集中する
17. Load：プログレッシブレンダリング 改善されたプロ グレッシブレンダ リング 改善されていな いレンダリング
18. RAIL：まとめ Response < 100ms 即刻ユーザにフィードバックを Animation < 16ms サクサク、統一感上で動く Idle < 50ms バックグラウンド処理をする Load < 1000ms クリティカル情報を先に出す あなたのアプリのRAILはどうなっているの？
19. パフォーマンスって改善して意味あるのか。 － Google：2% スピード減少 = 2% ユーザ検索減少 － Yahoo：400ms 速度上昇 = 9% トラフィック増加 － AOL：速いロード = PV増加 － Amazon：100ms 速度上昇 = 1% 売上増加 － Google：ウェブサイトのスピードがランキングの指標としてある
20. 世の中の列 － グーグラーが作ったボイスメモ － https://voice-memos.appspot.com/ － インドのFlipkart － http://www.flipkart.com/ － Google I/O 2015 － https://events.google.com/io2015/
21. Animation：GChrome風 － アニメーション中に処理したらあかんならその前に すれば良い － レンダリングにコストの高い処理を避ける事が目的 － https://github.com/GoogleChrome/flipjs
22. Animation：GCのピクセルパイプライン － Javascript：画面に変更のある処理を担う（javascriptに限らず） － Style：どのCSSルールがどのElementに一致する算定 － Layout：各Elementの性質とそのポジションを計算 － Paint：各レイヤーのピクセルをペイントする － Composite：すべてのレイヤーをうまい事、画面に表示する どのプロパティがどの処理を実行するか？⇒ http://csstriggers.com/
23. Animation：ローコストレンダリング Response Animation • Position： transform: translate(mpx, npx); • Scale： transform: scale(n); • Rotation： transform: rotate(ndeg); • Opacity： opacity: 0...1; 100ms 100ms にAnimationに必要な処理を入れれば？
24. Animation：FLIP技 － Ｆirst：初期の状態を記録。（位置＋サイズ） － Ｌast：アニメーション後の状態に更新 － 例：el.classList.add(‘expanded’); － Ｉnvert：transformを利用してコンポネントを処理の状態の戻す － 例：transform: translate(-100px, -50px) scale(0.3); － Ｐlay：Invertで適用したスタイルを無効にし、最低コストで最後 の状態に更に戻す － 例：transform: none;
25. Animation：FLIP技
26. パフォーマンスAudit － Chrome DevTools － http://www.webpagetest.org/ － https://developers.google.com/speed/pagespeed/insights/ － http://developer.android.com/training/testing/performance.h tml
31. RAIL勉強会 以上。