RAILモデルで応答を設計する

「このアプリは速い」「このサイトは遅い」。わたしたちは速度を一つの感想で語りがちだが、実際の体験は複数の異なる時間からできている。タップに反応する時間、画面が滑らかに動く時間、操作のない待機の時間、最初に開くまでの時間。これらを一括りにせず、場面ごとに分けて考えるための枠組みが、Googleの提唱した性能モデル「RAIL」である。

RAILは、Response(応答)、Animation(アニメーション)、Idle(待機)、Load(読み込み)の頭文字を取った名称だ。要点は、利用者の体験を四つの場面に分け、それぞれに異なる時間の目安を割り当てる点にある。一つの速度基準ですべてを測るのではなく、場面ごとに「ふさわしい速さ」を定義する。

応答(Response)

利用者が何か操作したとき、その反応はごく短い時間で返すべきだとされる。Googleの解説では、操作への反応はおおむね100ミリ秒以内が目安とされている。これは0.1秒の壁で見た知覚の連続性と一致する。タップやクリックに対する反応がこの範囲に収まれば、利用者は操作と結果を地続きに感じる。逆にここで遅れると、システムが反応していないという印象を与える。

アニメーション(Animation)

画面の動きが滑らかに見えるためには、各フレームを短い間隔で描き続ける必要がある。一般に毎秒60フレーム、つまり1フレームあたり約16ミリ秒という目安が知られている。スクロールや遷移がこの基準を下回ると、動きがカクつき、利用者は粗さを感じ取る。応答とアニメーションは、どちらも「即時」の領域に属するが、求められる時間の尺度はさらに細かい。

待機(Idle)と読み込み(Load)

待機は、利用者が操作していない時間をどう使うかという観点だ。この隙に、後で必要になりそうな処理を済ませておけば、いざ操作されたときの応答を速くできる。非同期という設計の発想と通じる、時間の前借りである。

読み込みは、最初に意味のある内容が表示されるまでの時間に関わる。ここで効くのは全体の完成時間より、初期表示の速さだ。ローディング体験の比較で見たように、骨格が早く現れれば、残りの読み込みは許容されやすい。RAILは、読み込みを「ゼロか完成か」ではなく、段階的な体験として捉えるよう促す。

時間に予算を割り当てる

RAILの実践的な価値は、速度を「時間予算」として配分する発想にある。すべてを最速にすることはできない。だから、操作への反応にはこれだけ、アニメーションにはこれだけ、と場面ごとに割り当て、その範囲に収まるよう設計する。限られた計算資源を、体感に効く場面へ重点的に振り向けるわけだ。

もっとも、RAILの数値もまた、絶対的な定数ではない。ドハティのしきい値と同様、これらは人間の知覚の大まかな性質に由来する目安であって、文脈によって最適点は動く。重要なのは個々の数字を暗記することではなく、体験を場面に分け、それぞれに適した時間を考えるという姿勢だ。

応答のタイミング設計は、しばしば「速くする」という単一の目標に還元されてしまう。だがRAILが示すのは、速さが場面ごとに違う意味を持つということだ。どこに労力を集中し、どこは緩めてよいか。その見取り図を持つことが、闇雲な高速化より遠くまで連れて行ってくれる。場面ごとの判断は、画面の外、通知の差し込み方にも及ぶ。その話題は通知のタイミング設計で続ける。