Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Rail というUIパフォーマンスモデル
Search
Benoît Quenaudon
April 05, 2016
Programming
1
130
Rail というUIパフォーマンスモデル
Benoît Quenaudon
April 05, 2016
Tweet
Share
More Decks by Benoît Quenaudon
See All by Benoît Quenaudon
36・15 Cash App
oldergod
1
180
Sweet Architecture
oldergod
1
360
Architecture at Scale (droidconNYC 2022)
oldergod
2
600
Managing gRPC with Wire
oldergod
2
520
Wire & Proto3
oldergod
0
79
Effective Reactive Architecture
oldergod
2
210
Wire 3 : Tackling gRPC with Kotlin
oldergod
0
970
Server Driven UI Workflow
oldergod
2
490
Applying Rx Best Practices to Your Architecture
oldergod
1
230
Other Decks in Programming
See All in Programming
Rails 1.0 のコードで学ぶ find_by* と method_missing の仕組み / Learn how find_by_* and method_missing work in Rails 1.0 code
maimux2x
1
260
ソフトウェアエンジニアの成長
masuda220
PRO
12
2.1k
CloudNativePGを布教したい
nnaka2992
0
120
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
1k
PRレビューのお供にDanger
stoticdev
1
240
Django NinjaによるAPI開発の効率化とリプレースの実践
kashewnuts
1
290
未経験でSRE、はじめました! 組織を支える役割と軌跡
curekoshimizu
1
200
Ça bouge du côté des animations CSS !
goetter
2
160
オレを救った Cline を紹介する
codehex
7
2.8k
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.6k
Domain-Driven Design (Tutorial)
hschwentner
13
22k
Honoとフロントエンドの 型安全性について
yodaka
7
1.5k
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.3k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Why Our Code Smells
bkeepers
PRO
336
57k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
580
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
The Cost Of JavaScript in 2023
addyosmani
47
7.4k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
RailsConf 2023
tenderlove
29
1k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
260
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
134
33k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.4k
Transcript
RAILという UIパフォーマンスモデル User中心
By - 2015年中から - Fluentカンファレンスに発表があった。 - ユーザを中心にしたアプリのパフォーマンスモデ ル。 - Chromeチームから生まれたもので話はWebアプリに寄りがち。
- ネイティブアプリでも使える。
パフォーマンス 対 成功性 パフォーマンス 遅すぎる ユーザ退場 ま〜ま〜 ユーザ残る サクサク ユーザ喜ぶ
サクサク ROI? 成 功 性
パフォーマンス 対 成功性 パフォーマンス サクサク ユーザ喜ぶ 成 功 性 遅すぎる
ROI 減少
- 遅いって何?50msは遅い?速い? ⇒ ユーザはどう感じる?
ユーザが感じる:返事 遅延 所感 0 - 100 ms 即刻 100 -
1000 ms 集中切れず遅延を感じる 1000+ ms 脳コンテキストスイッチ 10,000+ ms また今度
ユーザが感じる:アニメーション 24 FPS(~40 ms) 違和感がない 60 FPS(~16 ms) サクサク感じる ただし、全体のFPSに統一感が無ければ
FPS をさげて統 一感を守った方がユーザに優しい。 ※FPS:Frame Per Second
アプリ内のフロー:アクション目線 読んでいる・考えている ステート変更 進捗表示 ナビゲーション クリック トランジション ドラッグ スクロール 読み込み
Idle Animation Response Load
None
Response - Tap to Paint:100ms - 100ms以内、ユーザのインプットに対してフィード バックを - 300ms以上かかりそうなら、その旨もフィードバック
で伝える - 逆目線:100msが経つまで処理してもユーザは気づかない
Response:GChrome風 onListItemClick() { let spinnerTimeout = setTimeout(showSpinner, 300); loadDetailsData().then(data =>
{ clearTimeout(spinnerTimeout); hideSpinner(); transitionToDetailsView(data); } }
Animation - 16ms - ブラウザやOSの処理もあるから8msぐらいまで狙った方が良い - 実現するのは難しい ⇒ アニメーション中は処理をしないのがベストプラク ティス
- iOS 対 Android も昔でその面で大きく違った - GChrome風:FLIP ※詳細説明は後ほど
Idle - バックグラウンド処理はここでする! - ユーザは操作していないけどするかも?のスタンスで ⇒ 50msで終わる単位で - ユーザが操作しだした時に即刻(100ms以内)に応えられるため
Idle:GChrome風 - requestIdleCallback - Chromeのみ(47+) - 標準化されていないがEDはある - https://w3c.github.io/requestidlecallback/ Window.requestIdleCallback(callback[,
options]);
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);
Load - ユーザのインプットのゴールを達成する - 1s:意味のあるペイントまでの時間 - 実現するのは難しい - 1s 以内にすべてを表示する必要はない
- キャッシング(Service Worker)、ストリーミング等 - クリティカルレンダリングパスに集中する
Load:プログレッシブレンダリング 改善されたプロ グレッシブレンダ リング 改善されていな いレンダリング
RAIL:まとめ Response < 100ms 即刻ユーザにフィードバックを Animation < 16ms サクサク、統一感上で動く Idle
< 50ms バックグラウンド処理をする Load < 1000ms クリティカル情報を先に出す あなたのアプリのRAILはどうなっているの?
パフォーマンスって改善して意味あるのか。 - Google:2% スピード減少 = 2% ユーザ検索減少 - Yahoo:400ms 速度上昇
= 9% トラフィック増加 - AOL:速いロード = PV増加 - Amazon:100ms 速度上昇 = 1% 売上増加 - Google:ウェブサイトのスピードがランキングの指標としてある
世の中の列 - グーグラーが作ったボイスメモ - https://voice-memos.appspot.com/ - インドのFlipkart - http://www.flipkart.com/ -
Google I/O 2015 - https://events.google.com/io2015/
Animation:GChrome風 - アニメーション中に処理したらあかんならその前に すれば良い - レンダリングにコストの高い処理を避ける事が目的 - https://github.com/GoogleChrome/flipjs
Animation:GCのピクセルパイプライン - Javascript:画面に変更のある処理を担う(javascriptに限らず) - Style:どのCSSルールがどのElementに一致する算定 - Layout:各Elementの性質とそのポジションを計算 - Paint:各レイヤーのピクセルをペイントする -
Composite:すべてのレイヤーをうまい事、画面に表示する どのプロパティがどの処理を実行するか?⇒ http://csstriggers.com/
Animation:ローコストレンダリング Response Animation • Position: transform: translate(mpx, npx); • Scale:
transform: scale(n); • Rotation: transform: rotate(ndeg); • Opacity: opacity: 0...1; 100ms 100ms にAnimationに必要な処理を入れれば?
Animation:FLIP技 - First:初期の状態を記録。(位置+サイズ) - Last:アニメーション後の状態に更新 - 例:el.classList.add(‘expanded’); - Invert:transformを利用してコンポネントを処理の状態の戻す -
例:transform: translate(-100px, -50px) scale(0.3); - Play:Invertで適用したスタイルを無効にし、最低コストで最後 の状態に更に戻す - 例:transform: none;
Animation:FLIP技
パフォーマンスAudit - Chrome DevTools - http://www.webpagetest.org/ - https://developers.google.com/speed/pagespeed/insights/ - http://developer.android.com/training/testing/performance.h
tml
None
None
None
None
RAIL勉強会 以上。