Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

05162bc961c3654218bf1839974a4f35?s=128

Benoît Quenaudon

April 05, 2016
Tweet

More Decks by Benoît Quenaudon

Other Decks in Programming

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
  9. None
  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技 - First:初期の状態を記録。(位置+サイズ) - Last:アニメーション後の状態に更新 - 例:el.classList.add(‘expanded’); - Invert:transformを利用してコンポネントを処理の状態の戻す -

    例:transform: translate(-100px, -50px) scale(0.3); - Play: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
  27. None
  28. None
  29. None
  30. None
  31. RAIL勉強会 以上。