#36「RAILモデルとINPの改善」
今回はINPをどう改善していくかを考える際に参考にできる「RAILモデル」についての概要と、RAILモデルを踏まえてINPをどう改善していくかについてお話ししました。
※ オフラインのため、音声ファイルを再生できません。ネットワーク状況をご確認の上、再度アクセスしてください。
- 加藤
- こんにちは！
ミツエーテックラジオは株式会社ミツエーリンクスのスタッフがWebデザイン、 WebフロントエンドなどのWeb技術に関するニュースやツールなどをシェアするためのポッドキャストです。
1つ前に公開した「新たなパフォーマンス指標 Interaction To Next Paintとは」ではGoogleが発表した新たな指標であるINPの概要と計測方法についてお話ししました。後編となる今回は、INPをどう改善していくか、という割と開発寄りのところをもう少し深堀りできたらなと思います。佐竹さん、今回もよろしくお願いします！ - 佐竹
- よろしくお願いします。
では前回からの続きなのでいきなりですが、パフォーマンス指標でINPに限らず、達成すべき目標値のようなものがありますよね。 - 加藤
- たとえば、LCPの場合はページ読み込みから2.5秒以内ならいいパフォーマンスとか、そういうものですよね？
- 佐竹
- そうですね。INPの場合は200ミリ秒以下が良くて、200ミリ秒より長く500ミリ秒以下が要改善、500ミリ秒より長くかかっていると不良という参考値があるんですけど、前回お話しした通り、INPは入力遅延時間、処理時間、表示遅延時間の合計を示すものなので、INPが何ミリ秒かかっているかだけで考えてしまうとちょっと粒度が大きくて、何を改善したらいいかというのが漠然としてしまうと思うんですよね。
なので、今回は改善することにポイントをおいて、もう少し小さい粒度で考えていきたいなと思います。 - 加藤
- なるほど。INPは200ミリ秒までがいいとされているけど、じゃあそれを達成するためには入力遅延時間、処理時間、表示遅延時間の3つを何ミリ秒に抑えればいいのかってことですね。それぞれどれだけ改善すれば十分なのかっていうところがあんまりイメージできてないんですけど、その辺りってどうなんですか？
- 佐竹
- はい。そういうときに参考にしたいのがRAILモデルなんですね。RAILモデルは、ユーザーがWebページをストレスなく使うための数値目標やガイドラインをまとめたもので、Webアプリケーションを操作する時に発生しやすい遅延時間を4つに区分して、それぞれの遅延時間をどの程度に抑えるべきか、という具体的な数値目標を立てています。
- 加藤
- あーRAILモデル、名前は聞いたことあったんですけど、ちゃんと調べたことなかったですね。ちょっと詳しく教えてもらってもいいですか？
- 佐竹
- はい。まずRAILモデルという名前の「RAIL」はWebアプリのライフサイクルを構成する4つの要素、Response、Animation、Idle、Loadの4つの単語の頭文字から成っています。名前になるくらいなので、この4つの要素がRAILモデルのキーなんですね。
- 加藤
- なるほど。ちなみにそのWebアプリのライフサイクル、っていうのはどういうものですか？
- 佐竹
- はい。多くのWebサイトはまずページを読み込んで、読み込みが完了したらユーザーのスクロールやタップなどのインタラクションを受け入れる、というのが大ざっぱなサイクルですよね。そしてユーザーがスクロールしたりタップしたりする間には、Webサイトがユーザーの操作に応答するまでにかかる時間だったり、アニメーションにかかる時間、何も実行されていない待機時間というのが含まれているんです。
- 加藤
- あーなるほど。RAILモデルではページ滞在中のいろんな時間をより細分化して考えてるっていう感じですね。
- 佐竹
- そうですね。特にResponseとIdleはINPで計測される入力遅延時間、処理時間、表示遅延時間に関わってくるので、RAILモデルについても併せて知っておくといいと思います。
- 加藤
- なるほど！ではRAILモデルの構成要素について説明お願いします！
- 佐竹
- はい。Response、Animation、Idle、Loadの順に話したいところなんですけど、分かりやすさ優先で順番を入れ替えてお話ししていきます。
まず、比較的に分かりやすいLoad、つまり読み込み時間についてです。RAILモデルでは3G回線のモバイルデバイスという計測環境において、ページの読み込み開始から5秒以内でページを操作可能にすることが目標としてあげられています。
初めてRAILモデルが発表された時は特にネットワークなどの条件はなくて、ロードが1秒以内に完了することが目標値だったと思うんですけど、いつの間にかこの辺が変わったみたいですよね。 - 加藤
- んーじゃあやっぱり時代や状況に合わせて数値目標も変わっていく感じなんですかね。
- 佐竹
- そうなんでしょうね。
- 次がIdleについてです。結構分かりにくいんですが、Idleって直訳すると動いていないとか、稼働していないという意味を持っているので、ざっくり言うとロード中でもアニメーション中でもないアイドル時間、つまり準備時間をできるだけ確保しようという考え方です。目標としてはユーザーの操作に対する処理を50ミリ秒以内に開始できるように、この準備時間をできるだけ確保しようということが定められています。
- 加藤
- うーん、確かにちょっと分かりにくいですね。その準備時間をできるだけ確保するっていうことが、どうパフォーマンスにつながるんですか？
- 佐竹
- そうですね。うーん例えば100ミリ秒かかる処理があったとして、その処理のスタートとほぼ同時にユーザーの操作が起きた場合、少なくとも処理が終わるまではユーザーの操作に応答ができなくなってしまうんですよね。
- 加藤
- あーJavaScriptは2つの処理を同時並行で処理できないからですね？
- 佐竹
- そうですね。なので、1つ1つの処理にかかる時間を短くして、処理と処理のスキマを増やしておくことが、ユーザー操作にすばやく応答することにつながります。すばやく応答するということは入力遅延時間が短いということを指すので、処理を短くすることはINPの向上にもつながります。ちなみにRAILモデルではアイドル時間に発生する処理は、長くても50ミリ秒以内には完了させることを推奨しています。
- 加藤
- なるほど。その50ミリ秒っていうのが短いのか長いのかちょっと分かんないですね笑
- 佐竹
- そうですよね。50ミリ秒だったら人があまり気付かない程度の遅延なんですけど、それがどんどん積み重なっていくと体感できるレベルになって、ユーザー体験も悪くなってしまいます。
- では次に、3つ目のResponseでは、ユーザーの操作に対して100ミリ秒以内にユーザーが感じ取れるフィードバックを返しましょう、という目標値を設定しています。
- 加藤
- うん、これは直感的で分かりやすいですね。たとえばホバーした時とかクリックした時のフィードバックがなかったり遅かったりすると、自分の操作がうまくできてなかったのかな？と勘違いさせてしまったりしますよね。
- 佐竹
- そうですね。ユーザーの操作に対するフィードバックを返す、というところを少しだけ細分化すると「入力に対する処理」と「その処理の結果をブラウザに描画する処理」に分けられるんですけど、これはそれぞれINPでいう処理時間、表示時間にあたります。
- 加藤
- なるほど。ということはIdleと同様にResponseもINPの改善につながるっていうことですね。
- 佐竹
- そういうことですね。
- 加藤
- ちょっと疑問に思ったんですけど、INPでは200ミリ秒以内であれば良いパフォーマンスとされていたと思いますが、RAILモデルでは100ミリ秒以内が目標値なんですね。
- 佐竹
- そうですね。RAILモデルはリサーチに基づいて決定された目標値ですけど、INPの基準値は公開されているWebサイトを実際に計測した結果のうち、75パーセンタイルのデータを基準値としている、という違いがあります。もちろん、片方を意識して改善していけば、もう一方も自然と改善できるということは変わらないですよね。
- 加藤
- なるほど。
- 佐竹
- 最後がAnimationです。アニメーションの滑らかさを表す際には「FPS」、つまり1秒に何フレーム表示しているかという数値を基準として使います。
- 加藤
- 一般的には60FPSだとぬるぬる動くとか言われますよね。
- 佐竹
- そうですね。60FPSだと1秒間に60フレームを表示することになるので、単純に計算すると1フレームを表示するのに使える時間は16ミリ秒になります。
- 加藤
- んーなんかそう言われると以外と短いですね…！
- 佐竹
- そうなんです。それに加えて、ブラウザが1フレームをレンダリングするのに約6ミリ秒かかると言われているので、RAILモデルでは16ミリ秒から6ミリ秒をひいて10ミリ秒で各フレームを生成することを目標値としています。
- 加藤
- うーん、やっぱりなんか単位がかなり小さいのであんまり実感わかないですけど、なかなかシビアというか、けっこう細かい実装まで気を配る必要がありそうな感じがしますね。
- はい。RAILモデルについて分かってきたところで、それを踏まえてINPをどう改善していくかというところを話していきたいと思います。RAILモデルで推奨されていることを実践していけば自然とINPも改善できますし、INPを改善していけば、自然とRAILモデルで示されている目標値に近づくことができるということでしたね。
- 佐竹
- そうですね。なのでここからは、INPを構成する3つの時間である入力遅延、処理時間、表示遅延時間をもう少し具体的にどう改善していくかというところを話していこうと思います。
まず1つ目に入力遅延時間が長くなる要因としてあげられるのが、他の処理が邪魔をしているということです。JavaScriptは基本的にシングルスレッドで、複数の処理を同時に実行することはできないので、順番待ちしている処理を1つ1つ順番に実行していきますよね。そのため、ユーザー入力に応答しようとしても、他の順番待ちタスクが終わるまで待たないといけないっていうこともあります。 - 加藤
- たとえば、スクロールするたびに何か重い処理をやっているとかすると、操作しているうちに全体的に動きがもっさりしてきたり、まぁ最悪の場合「ページが応答しません」なんてブラウザのメッセージが出ることもありますよね。
- 佐竹
- ありますねー。なので、すぐに実行しなくてもいい処理はrequestIdleCallbackなどを用いて後まわしにしたり、計算などの重い処理はWeb Workerなどを使って別スレッドで処理するようにすると遅延時間を削減することができます。あとは、アイドル時間を最大化するために処理を分割して、1つ1つの処理にかかる時間をできるだけ減らすっていうことも大事ですね。
- 加藤
- なるほど、つまりユーザーからのインプットがいつ起きてもいいように、処理のタイミングをずらすだけではなく、各処理の実行時間を極力短くするように努めるっていうことですね。2つ目の処理時間を改善するにはどうすればいいですか？
- 佐竹
- こちらもロングタスクと呼ばれるような、処理に長い時間がかかっているタスクを見つけて、実行時間を短くしたり分割したりして改善していくことが必要かなと思います。
- 加藤
- なるほど。では最後は表示遅延時間、画面の描画にかかる時間ですが、これはどう改善していけばよいですか？
- 佐竹
- 描画については、ブラウザがどういうフローでレンダリングしているのかを理解することが改善につながります。詳細は省略しますけど、いわゆるリフローと呼ばれる処理をできるだけ減らしたり、CSS Triggersを見ながら、LayoutやPaintに関わる処理を減らしたりすることが表示遅延時間を減少させるポイントになります。
- 加藤
- うーんなるほど。じゃあレンダリングのパフォーマンスを改善する方法については、まぁINPが出てくる前からいろいろなところで話されてきたと思うんで、そういったこれまでのナレッジを活かせるような気がしますね。
- 加藤
- はい。今回はRAILモデルとINPの改善ポイントについてお話ししました。いやなんか全体的に細かい数字が多くて、正直言って難しいなと思っちゃいましたね。
- 佐竹
- 新しいものに対応していくのってほんと大変ですよねー。でもまぁ今後パフォーマンスの良いサイトが当たり前になっていくと思うので、今回のINPやRAILモデルとうまく付き合いながら、見た目だけのサイトではなくて中身で勝負できるサイトを作っていきたいですね。
- 加藤
- はい、ありがとうございます！では最後に、ミツエーリンクスではスマートなコミュニケーションをデザインしたいUIデザイナー、UI開発者を募集しています。採用サイトではオンライン説明会やオンライン面接なども行っていますのでチェックしてみてください。
また、このPodcastはApple Podcast、Google Podcast、Amazon Music、Spotify、YouTubeで配信していますので、お好みのプラットフォームでフォローいただけると、最新のエピソードをすぐ視聴できます！こちらもぜひご活用ください。「#ミツエーテックラジオ」でご意見、ご感想、こんなこと話してほしいというリクエストなどお待ちしております。それでは今日はこの辺で！ありがとうございました！ - 佐竹
- ありがとうございました！