RAIL 是以使用者為中心的效能模型，提供思考效能的架構。這個模型會將使用者體驗細分為重要動作 (例如輕觸、捲動、載入)，並協助您為每個動作定義成效目標。
RAIL 代表網頁應用程式生命週期的四個不同面向：回應、動畫、閒置和載入。使用者對每種情境的效能期望不同，因此成效目標是根據情境和使用者對延遲感知的 UX 研究來定義。
重視使用者
將使用者視為成效工作的核心。下表說明使用者對效能延遲感受的主要指標：
使用者對效能延遲的感受| 0 至 16 毫秒 | 使用者非常擅長追蹤動作，而且不喜歡不流暢的動畫。只要每秒轉譯 60 個新影格，使用者就會認為動畫流暢。也就是每個影格 16 毫秒，包括瀏覽器將新影格繪製到螢幕所需的時間，因此應用程式約有 10 毫秒的時間產生影格。 |
| 0 至 100 毫秒 | 在這個時間範圍內回應使用者動作，使用者會覺得結果是立即的。如果時間過長，動作和反應之間的連結就會中斷。 |
| 100 至 1000 毫秒 | 在這個時間範圍內，使用者會覺得工作是自然且連續的進展。對大多數網路使用者來說，載入網頁或變更檢視畫面代表一項工作。 |
| 1000 毫秒以上 | 超過 1000 毫秒 (1 秒) 後，使用者就會失去對正在執行的工作的專注力。 |
| 10000 毫秒以上 | 超過 10,000 毫秒 (10 秒) 後，使用者會感到不耐煩，並可能放棄工作。他們可能不會再回來。 |
目標和規範
在 RAIL 的脈絡中，「目標」和「指南」一詞有特定含義：
目標：與使用者體驗相關的重要成效指標。舉例來說，輕觸後不到 100 毫秒就會繪製畫面。由於人類的感知相對穩定，這些目標在短期內不太可能改變。
規範。有助於達成目標的建議。這些建議可能與目前的硬體和網路連線狀況有關，因此可能會隨時間變更。
回應：在 50 毫秒內處理事件
目標：在 100 毫秒內完成由使用者輸入啟動的轉場，讓使用者感覺互動是即時的。
規範：
為確保在 100 毫秒內顯示回應，請在 50 毫秒內處理使用者輸入事件。這適用於大多數輸入內容，例如點選按鈕、切換表單控制項或啟動動畫。這項設定不適用於觸控拖曳或捲動。
雖然這可能不符合直覺，但立即回應使用者輸入內容不一定是正確的做法。您可以使用這 100 毫秒的視窗執行其他耗費資源的工作，但請注意不要封鎖使用者。如果可以，請在背景執行工作。
如果動作需要超過 50 毫秒才能完成，請務必提供意見回饋。
50 毫秒或 100 毫秒？
目標是在 100 毫秒內回應輸入內容，但為什麼預算只有 50 毫秒？這是因為除了輸入處理之外，通常還有其他工作正在進行，而這些工作會占用部分時間，導致輸入回應時間超過可接受的範圍。如果應用程式在閒置時間內，以建議的 50 毫秒區塊執行工作，則輸入內容在其中一個工作區塊中發生時，最多可排入佇列 50 毫秒。考量到這一點，可以合理假設只有剩餘的 50 毫秒可用於實際輸入處理。下圖呈現了這種效果，顯示在閒置工作期間收到的輸入內容如何排入佇列，減少可用的處理時間：
動畫：在 10 毫秒內產生影格
目標：
在 10 毫秒內產生動畫中的每個影格。技術上來說，每個影格的時間預算上限為 16 毫秒 (1000 毫秒/每秒 60 個影格 ≈ 16 毫秒)，但瀏覽器需要約 6 毫秒來轉譯每個影格，因此每個影格的準則為 10 毫秒。
追求視覺流暢度。使用者會注意到影格率的變化。
規範：
在動畫等高壓點，關鍵在於盡可能不執行任何操作，並在無法執行操作時盡可能減少操作。盡可能利用 100 毫秒的回應時間預先計算耗費資源的工作，盡可能提高達到 60 fps 的機率。
如需各種動畫最佳化策略，請參閱「轉譯效能」。
- 視覺動畫，例如進場和退場、補間動畫和載入指標。
- 捲動。包括快速滑動，也就是使用者開始捲動後放開，頁面繼續捲動。
- 拖曳。動畫通常會跟隨使用者互動，例如平移地圖或雙指撥動縮放。
閒置：盡可能延長閒置時間
目標：盡可能延長閒置時間，提高網頁在 50 毫秒內回應使用者輸入內容的機率。
規範：
利用閒置時間完成延後的工作。舉例來說，在初始網頁載入時，請盡可能載入少量資料，然後使用閒置時間載入其餘資料。
在閒置時間內執行工作，時間不超過 50 毫秒。如果超過這個時間，可能會干擾應用程式在 50 毫秒內回應使用者輸入內容的能力。
如果使用者在閒置時間工作期間與網頁互動，使用者互動應一律優先處理，並中斷閒置時間工作。
載入：在 5 秒內提供內容並可供互動
網頁載入速度緩慢時，使用者會分心，並認為工作已中斷。載入速度快的網站，平均工作階段時間較長、跳出率較低，且廣告可視度較高。
目標：
根據使用者的裝置和網路功能，盡可能縮短載入時間。目前，首次載入的理想目標是在 中階行動裝置上，透過緩慢的 3G 連線，在 5 秒內 載入頁面並可供互動。
後續載入時間則應控制在 2 秒內。
規範：
請在使用者常用的行動裝置和網路連線上測試載入效能。您可以透過 Chrome 使用者體驗報告，瞭解使用者的連線分布。如果網站沒有這類資料，2019 年行動經濟報告建議，全球適用的基準是中階 Android 手機 (例如 Moto G4) 和慢速 3G 網路 (定義為 400 毫秒 RTT 和 400 kbps 傳輸速度)。WebPageTest 提供這項組合。
請注意，雖然一般行動使用者的裝置可能會顯示 2G、3G 或 4G 連線，但實際上，由於封包遺失和網路差異，有效連線速度通常會明顯較慢。
您不必在 5 秒內載入所有內容，就能讓使用者感覺載入完成。建議您延遲載入圖片、分割 JavaScript 程式碼套件，以及採用 web.dev 建議的其他最佳化做法。
評估 RAIL 的工具
有幾項工具可協助您自動評估 RAIL。具體使用哪一種，取決於您需要的資訊類型，以及您偏好的工作流程類型。
Chrome 開發人員工具
Chrome 開發人員工具可深入分析載入網頁或執行時發生的所有事件。請參閱「開始分析執行階段效能」，熟悉「Performance」面板 UI。
以下是特別相關的開發人員工具功能：
對 CPU 進行節流，模擬效能較低的裝置。
限制網路，模擬連線速度較慢的情況。
查看主執行緒活動：查看錄製期間主執行緒上發生的所有事件。
在表格中查看主執行緒活動，根據耗時最長的活動排序。
分析每秒影格數 (FPS)，評估動畫是否能真正流暢執行。
使用效能監控工具，即時監控 CPU 使用率、JS 堆積大小、DOM 節點、每秒版面配置等。
使用「Network」部分，以視覺化方式呈現錄製期間發生的網路要求。
在錄製時擷取螢幕截圖，以便在載入網頁或觸發動畫等情況下，準確重現網頁的外觀。
查看互動，快速找出使用者與網頁互動後發生的情況。
只要在可能發生問題的事件監聽器觸發時醒目顯示網頁，即可即時找出捲動效能問題。
即時查看繪製事件，找出可能影響動畫效能的高成本繪製事件。
燈塔
Lighthouse 可以在 Chrome 開發人員工具、PageSpeed Insights、Chrome 擴充功能、Node.js 模組和 WebPageTest 中使用。只要提供網址，這項工具就會模擬中階裝置使用緩慢 3G 連線的情況，對網頁執行一系列稽核，然後提供載入效能報表和改善建議。
以下稽核項目特別相關：
回應
可能的最長 First Input Delay。根據主執行緒閒置時間，預估應用程式需要多久時間才能回應使用者輸入內容。
Total Blocking Time。 評估網頁無法回應使用者輸入內容 (例如滑鼠點擊、輕觸螢幕或按下鍵盤) 的總時間。
Time To Interactive。評估使用者何時能持續與所有網頁元素互動。
載入
未註冊控制頁面和 start_url 的 Service Worker。Service Worker 可在使用者裝置上快取常見資源，減少透過網路擷取資源所需的時間。
延遲載入畫面外圖片。延遲載入畫面外圖片，直到需要時再載入。
使用合適的圖片大小。請勿提供明顯大於行動可視區域顯示大小的圖片。
避免 DOM 過大。只傳送轉譯網頁所需的 DOM 節點，減少網路位元組。
WebPageTest
WebPageTest 是一項網頁效能工具，可使用實際瀏覽器存取網頁並收集時間指標。在 webpagetest.org/easy 輸入網址，即可取得詳細報表，瞭解網頁在 Moto G4 裝置上透過慢速 3G 連線載入的效能。您也可以設定納入 Lighthouse 稽核。
摘要
RAIL 是一種觀察網站使用者體驗的角度，將其視為由不同互動組成的歷程。瞭解使用者對網站的看法，設定對使用者體驗影響最大的成效目標。
專注於使用者需求
在 100 毫秒內回應使用者輸入內容。
在動畫或捲動時，在 10 毫秒內產生影格。
盡可能延長主執行緒閒置時間。
在 5000 毫秒內載入互動式內容。