アプリの起動段階やタイミング (やユーザーストーリー) についての下記の表には、Firefox OS アプリ用のベストプラクティスがあります。それは全て(低スペック端末も含めた)Firefox OS端末のアプリパフォーマンスとして "受容できる" 観点のものです。これはFirefox OS パフォーマンスチームの、性能要件を満たしたアプリの UX-承認 定義を形成し、Firefox OSの応答性と知覚できるパフォーマンス用のMozillaのプログラムの一部です。
アプリの起動段階や認識時間の目標
下記の表はアプリ起動時の色々な段階と、知覚されるアプリパフォーマンスの改善時に狙う目標を定義します。
段階
段階 | 説明 |
---|---|
Chrome Visible | アプリのワイヤーフレーム、例えば ヘッダ、フッタやナビゲーション要素が表示されている。 |
Chrome Interactive | アプリのワイヤーフレーム、例えば ヘッダ、フッタやナビゲーション要素がユーザーの操作可能になっている。 |
Content Visible | 初期の 'above-the-fold'【訳注: ファーストビューとも言う、スクロールしなくても見えている部分】 コンテンツが表示され、レンダリングが完了している。この状態では、アプリが視覚的にユーザー操作可能な準備ができているように見えている。 |
Interaction Ready | 'above-the-fold' コンテンツ用に主要なサブセットがユーザーの操作可能になっている。 |
Content Ready | アプリの残っている、重要でない部分がロードされて操作可能であり、全てのバックグラウンドプロセスが完了している。 |
目標
スピード | アクション |
---|---|
0 - 140ms | アプリアイコンがタッチされた表示になる。 |
0 - 1.0s | アプリのランチアニメーションが開始し、完了している。 |
0 - 1.0s | アプリのワイヤーフレーム、例えばバナーやコントロール、がロードされ、表示されている。 |
0 - 1.0s | アプリの表示コンテンツやロード中のインジケーターが表示されるべきである。この指標は上記の "Content Visible" 段階でヒットしないといけない。 |
0 - 1.25s | アプリはユーザー操作、例えばタッチ、スクロール、などが可能である |
記: これらの目標時間は、アプリのコールド起動について言及し、蓄積されたものです。例えば、アプリアイコンのタッチとアプリの反応準備ができるまでは 1.25 秒以内に起こるべきです。
実装
バッケージ型の認定アプリ用に、共有された PerformanceTestingHelper スクリプトが同梱されている限り、実装はwindow要素から離れたイベントを起動するシンプルなものです、なぜならPerformanceTestingHelper はメトリクスを集めるためにこうしたプラットフォーム標準イベントをリッスンしているからです。
// moz-chrome-dom-loaded window.dispatchEvent(new CustomEvent('moz-chrome-dom-loaded'));
あなたのアプリが、DOM内に主要なchromeやナビゲーションインターフェイスを存在させていると指定し、それらが表示される準備ができているとマークする時に、このイベントを発生させて下さい。例えば要素が display: none;
や他の非表示機能ではない時です。
// moz-chrome-interactive window.dispatchEvent(new CustomEvent('moz-chrome-interactive'));
あなたのアプリが、主要なchromeやナビゲーションインターフェイスのイベントが関連づけられてユーザー操作可能であると指定する時に、このイベントを発生させて下さい。
// moz-app-visually-complete window.dispatchEvent(new CustomEvent('moz-app-visually-complete'));
このイベントは上記の Content Visible マーカーの重要な割当になります。あなたのアプリが視覚的にロードされたのを指定する時に、このイベントを発生させて下さい。例えば"above-the-fold" コンテンツがDOM内に存在し、それが表示される準備ができている、つまりdisplay: none;
や他の非表示機能でないのをマークします。
// moz-content-interative window.dispatchEvent(new CustomEvent('moz-content-interactive'));
あなたのアプリが、最小機能セットのイベントと関連づけできていて、 the user to interact with the moz-app-visually-complete
で利用可能になった"above-the-fold" コンテンツをユーザーが操作できるのを指定する時に、このイベントを発生させて下さい。
// moz-app-loaded window.dispatchEvent(new CustomEvent('moz-app-loaded'));
あなたのアプリが完全にロードされたのを指定する時に、このイベントを発生させて下さい。例えばあらゆる関連した "below-the-fold"【訳注: ファーストビュー以外】 機能がDOMに流し込まれ、表示済みにマークされ、操作の準備ができていて、必要となる起動時のバックアッププロセスは完了していて、さらなるユーザー操作を妨げる安定状態にあるべきです。
ユーザーストーリー
下記のユーザーストーリーは、アプリ使用時にユーザーがどのように時間やパフォーマンスを知覚するかについて、いくつかの洞察を提供します。
原因と結果の知覚 (140ms)
- 時間: 140ミリ秒
- ユースケース
- タッチ状態 (つまりキーボード)
- 遷移
- 端末の回転
- ストーリー
- ユーザーとして、アプリ起動に 140ms 以内の見た目の変化を期待します。
- ユーザーとして、ボタンやリスト項目がタッチされてから140ms 以内にハイライト状態が表示されるのを期待します。
- ユーザーとして、スクリーン遷移が140ms 以内の初期化で開始されるのを期待します。
- ユーザーとして、端末が回転して140ms 以内に、アプリで縦/横向きに再描画が開始されるのを期待します。
進行中の知覚
- 時間: 1秒
- ユースケース
- アプリが起動する。
- 最初の描画。
- "above the fold"部のロード
- 完全なロード
- 時間のかかる操作 (例: ダウンロード、wifi 接続).
- 最初の操作までの時間
- ストーリー
- ユーザーとして、 アプリのファーストビュー(above the fold)のレンダリングが1秒以内に完了するのを期待します。
- ユーザーとして、長い時間のかかる操作の進行中は、継続的な見た目の更新を期待します。
- ユーザーとして、アプリの操作が1秒以内にできるのを期待します。
手と目の協調
- 時間: 100ミリ秒
- ユースケース
- ドラッグ & ドロップ (ホームスクリーンとドックアイコンを動かす)
- スクロールする
- ピンチ/ズームする
- ページをスワイプ、ドロワーを引き出す
- ストーリー
- ユーザーとして、ドラッグの動作の見た目が100ms以内に反応することを期待します。
- ユーザーとして、ピンチ/ズームがサポートされている場合、100ms以内に見た目が反応することを期待します。
- ユーザーとして、スクロールが100ms以内に初期化されて、見た目が反応することを期待します。
- ユーザーとして、スクロールがタッチイベントに同期して100ms以内残ることを期待します。
- ユーザーとして、スワイプ開始から100ms以内に見た目が反応することを期待します。
参考情報
動画
- Fluent 2014: Ilya Grigorik, "Speed, Performance, and Human Perception"
- Fluent 2014: Steve Souders, "The Perception of Speed"
- SXSW 2012: Andy Hume: "CSS for Grownups"
文書
- Cognitive Biases
- Cognitive Load: The latest behavioral economics & consumer psychology research distilled down into helpful little brain gems.
- CSS
- High Performance Web Sites (Steve Souders)
- Jank-free Web
- Perceived Performance Introduction