前置き
この記事ではWeb パフォーマンスを学び直す中で改めて押さえておきたい「RAIL モデル」について調べたことを整理しています。
Core Web Vitals との違いや、RAIL がどのように “ユーザーの行動と体感速度” を基準にしているのか、なぜそれが必要なのかを理解することを目的としています。
関連記事
🧱 ブラウザの基礎（Rendering Pipeline）
-
ブラウザレンダリングの仕組み（基礎編）
DOM / CSSOM / Render Tree の基礎まとめ -
ブラウザレンダリング（内部構造と最適化）
メインスレッド / コンポジタ / ラスタ / GPU
⚙️ JavaScript と非同期処理
-
JavaScript の実行順
JS が「どの順番で実行されるか」を理解する -
小学生にもわかるかもしれない同期・非同期・Promise
同期と非同期をわかりやすく説明
🚀 パフォーマンスと UX
-
ユーザー中心のパフォーマンス モデル RAIL
UX の体感速度を設計する枠組み -
Core Web Vitals
Google が推す“実測体験”の評価指標
RAILとは
2015 年に Google Chrome チームが発案した、パフォーマンスを考慮するための構造を提供するユーザー中心のパフォーマンス モデル
Response / Animation / Idle / Load の頭文字で、ウェブパフォーマンスの4つの重要領域を表します。
ユーザー操作は通常 Response → Animation →（余裕があれば）Idle → Load の順で発生するため、RAIL は実際のユーザー行動をそのまま性能目標としてマッピングしている。
このモデルは、滑らかで快適な体験を実現するための明確な目標値を示します。
4 つの要素
R: Response（レスポンス）
ユーザー操作に 100ms 以内に反応する。内部処理のために実際の入力処理は 50ms 以内に終わらせる。
※50ms は、ブラウザの input handling・EventLoop の遅延を吸収して、100ms以内に応答を返すための実務上の安全ライン。
対策
イベントハンドラは軽く保ち、重い処理は後回しや非同期へ。
- イベント処理はシンプルに
- 重い処理は分割・遅延
- 優先度の低いタスクはrequestIdleCallback を活用
- Passive Event Listener の利用（スクロールやタッチ / ブラウザがスクロールをブロックしなくなる）
- サードパーティのscript を減らす（同期的に動く Analytics / Tag manager）
A: Animation（アニメーション）
アニメーションやスクロール操作などは 1 フレーム 10ms 以内で処理し、60fps を維持する。
つまり 1フレームあたり 16ms が処理時間の目安
※1フレームは16.6msだが、ブラウザ側の Layout / Paint の時間が必要なため、実処理に使えるのは10ms程度。
対策
滑らかなアニメーションを維持するためには、描画遅延を避ける工夫が必要。
- CSS アニメーションをなるべく利用（特にComposite-only properties の
transformとopacity） - アニメ中の JS 実行は最小限に
- レイアウトスラッシングを避ける
- requestAnimationFrame の正しい利用
- Layout thrashing を避けるため、値の読み取りと書き込みを分離する
const width = el.offsetWidth // read
el.style.width = width + 'px' // write
I: Idle（アイドル）
アイドル時間を使ってバックグラウンド処理を行い、次のユーザー操作に素早く応答できるよう備える。
いつ入力されても 50ms 以内に応答できるよう余裕を確保する。
対策
- 優先度の低いタスクは
requestIdleCallbackを活用 - 大きい処理は細分化する
- 将来必要になりそうなデータを prefetch
- プリレンダリング / prefetch / preloadする
- 非同期の import（Code Splitting）を使う
// before
import { sayHello } from "./greet.js";
document.getElementById("btn").addEventListener("click", () => {
sayHello("こんにちは");
});
// after
document.getElementById("btn").addEventListener("click", async () => {
const { sayHello } = await import("./greet.js");
sayHello("こんにちは");
});
ちゃんと理解するCode Splitting
L: Load（読み込み）
低速なネット環境のミッドレンジモバイル + 遅い 3G 環境で 5 秒以内にインタラクティブ化（操作可能状態になる）。以降の読み込みは 2 秒未満が理想。
対策
ユーザーはページが遅いとすぐ離脱してしまう。
- 画像やアセットの圧縮・遅延読み込み
- JavaScript の肥大化を避ける
- preload / preconnect で重要リソースを先に読み込む
- LCP の最適化・画像の preload・サイズ見直し・無駄な JS/ CSS を排除。
- クリティカルレンダリングパス の短縮・・・レンダリングをブロックする CSS/JS の削減。
- Service Worker キャッシュ戦略
- メインスレッドを忙しくさせない（・初期ロードで重いJSを読み込まない・重い処理はWeb Workerに逃がす・レンダリングブロックを減らす・長時間ブロッキングする関数を分割）
クリティカルレンダリングパス、メインスレッドについては
ブラウザレンダリングの仕組み (内部構造とパフォーマンス最適化編)
なぜ RAIL?
RAIL の焦点は 体感速度。
Google の研究をもとにした認知科学やUX 研究を基盤にした目標値を設定できる。
ページ全体よりも「ユーザーのアクション単位」で最適化する視点が提供される。
Core Web Vitalsとの違い
Core Web Vitals（LCP / FID / INP / CLS）がページ全体の健全性指標であるのに対し、RAIL は“ユーザー行動ごとの最適化指針”として補完関係にある。
- RAIL → ユーザー行動 × 認知科学 × 体感速度のモデル→どう作るか
- CWV → Page Experience の評価指標（計測のためのメトリクス）→どう測るか
測定に使う主なツール
- Chrome DevTools：実行中の CPU・ネットワーク・メインスレッド・FPS 分析など
- Lighthouse：低速環境のシミュレーションと改善提案を自動レポート
まとめ
RAIL は、ページ全体の速さではなくユーザーが触れる瞬間ごとの体験を高速化するためのモデル。
レスポンス・アニメーション・アイドル・読み込みの各段階で守るべき時間目標を明確にし、UX を壊さないウェブを設計するための指針。
参考サイト
RAIL モデルでパフォーマンスを測定する
MDN Web Docs 用語集 > RAIL
The RAIL Model: Making Web Apps Feel Lightning Fast