RAIL という Web パフォーマンスモデルの概要

RAIL を簡単に紹介する

主に Googler が、という趣ですが今年に入ってから RAIL というパフォーマンスモデルが紹介される機会が増えてきました。

RAIL は Response / Animation / Idle / Load の頭文字をとった命名で「アプリケーションのライフサイクルの観点から、それぞれのフェーズの基準時間(限界時間)を示したもの」です。

手前味噌ながら Webパフォーマンスにおけるイニシャライズとランタイム で紹介したうちの「ランタイム」部分が細分化されて、それぞれに基準時間を割り当てたようなイメージです。

Idle や Animation あたりの時間は紹介する人・タイミングによって多少ブレている印象ですが、大まかに以下のような感じです。

Response : 100ms

「UI が操作されたときユーザーにレスポンスするまでの応答時間は 100ms 以内」

Response Time Limits: Article by Jakob Nielsen で示されている瞬時に UI が反応していてると感じられる限界時間が 100ms なので、これに倣っていると思われる基準です。

ボタンの視覚的な状態が変化したり、タブが切り替えられたり、その他もろもろユーザーが操作したことによるインタラクションの何らかを迅速に返すことができれば満たされます。

Animation : 16ms

「アニメーション中の 1 フレームあたりの時間は 16ms 以内」

60 FPS が保たれていれば、最もスムーズにアニメーションしている状態です。60 FPS をたもつには 1フレームが 16.6666...ms に収まってなくてはいけないという基準です。

実際は GC などアニメーション以外のコストもあるし、純粋にアニメーションの前準備として DOM操作などのスクリプト処理にかけられる時間は 10ms くらい、という紹介もありました。デバイスの種類によりますが、絶対に 60FPS を保つならば、10ms よりも更に節制しないといけない気もします。

Idle : 50ms

「アイドル状態に実行される処理単体の時間は 50ms 以内」

アイドル状態はロードが終わったあと、ユーザー操作が行われるまでの待機時間を指します。この間、画像を遅延ロードしたり、追加コンテンツのための XHR が走ったりすることでしょう。

それらがメインスレッドを長時間占有してしまうとユーザー操作があったときのレスポンスが遅延してしまいます。よって、アイドル中に行われる処理は 1チャンクあたり 50ms 以内にすべきという基準です。

Load : 1,000ms

「コンテンツの初期ロード時間は 1,000ms 以内」

これも Response Time Limits で示されている分かりやすい基準です。これによれば一連のナビゲーション(リンクなどからの画面遷移)が間断なく行われていると感じられる限界が 1,000ms です。

このロード時間に対応する指標として window.loadDOMContentLoadedfirst paint など何の計測値を使うかは諸説あるように思いますが、「ユーザーがロードされたと知覚しうるタイミング」を示す指標の決め手には欠けている印象です。理想は ATF がレンダリングされたタイミングを指標化できると良いでしょうか。

Web パフォーマンス != ロード時間

現在、Web パフォーマンスという言葉が使われるとき、単にロード時間のみの性能を指していることと、RAIL モデルのような包括的な性能を指していることの両方があります。

Web ページのイニシャライズに関するパフォーマンスは昔から注目され続けてきた反面、ランタイムについてはこれから認知されていく途上にあります。そんな中、RAIL モデルのような分かりやすい基準は、標語としても人に説明しやすくなるのでエヴァンジェリスト諸氏の上手さを感じるのでした。

ただし「RAIL」という単語が、Ruby on Rails 大先生の背中を超えてググラビリティが保証されているのかは謎です。あと他3つと比べて Idle が分かりづらくないですか、そうですか。

参考

Udacity の Lesson 2 が RAIL モデルを丁寧に説明しているので参考になります。