RAIL 是一種以使用者為中心的效能模型，可提供思考效能的架構。這項模型會將使用者體驗分解為重要動作 (例如輕觸、捲動、載入)，協助您為每個動作定義成效目標。
RAIL 代表網頁應用程式生命週期的四個不同層面：回應、動畫、閒置和載入。使用者對這些情境的效能期望不同，因此效能目標是根據情境和使用者對延遲的認知 UX 研究定義。
重視使用者
以使用者為成效改善工作的重心。下表說明使用者對效能延遲的感受，以及相關的重要指標：
使用者對效能延遲的觀感| 0 至 16 毫秒 | 使用者非常擅長追蹤動作，而且不喜歡不流暢的動畫。只要每秒算繪 60 個新影格，使用者就會覺得動畫很流暢。也就是說，每個影格的轉譯時間為 16 毫秒，包括瀏覽器將新影格繪製到畫面上所需的時間，因此應用程式產生影格的時間約為 10 毫秒。 |
| 0 至 100 毫秒 | 在這個時間範圍內回應使用者動作，使用者會覺得結果是立即顯示。如果時間再長，動作與反應之間的連結就會中斷。 |
| 100 至 1000 毫秒 | 在這個時間範圍內，工作會感覺是自然且持續的進展。對大多數網路使用者而言，載入網頁或變更檢視畫面都代表一項工作。 |
| 1000 毫秒以上 | 超過 1000 毫秒 (1 秒) 後，使用者就會對執行的工作失去專注力。 |
| 10000 毫秒以上 | 如果超過 10000 毫秒 (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 秒內提供內容並與使用者互動
網頁載入速度緩慢時，使用者注意力會渙散，並認為工作流程中斷。載入速度快的網站平均工作階段時間較長、跳出率較低，且廣告可視率較高。
目標：
規範：
請在使用者常用的行動裝置和網路連線中測試載入效能。您可以透過 Chrome 使用者體驗報告，瞭解使用者的連線分布情形。如果網站沒有相關資料，2019 年行動經濟報告建議，全球基準應為中階 Android 手機 (例如 Moto G4) 和慢速 3G 網路 (定義為 400 毫秒 RTT 和 400 kbps 傳輸速度)。這項組合適用於 WebPageTest。
請注意，雖然一般行動裝置使用者可能會聲稱自己連上 2G、3G 或 4G 網路，但實際上有效連線速度往往會慢上許多，這是因為封包遺失和網路差異所致。
您不必在 5 秒內載入所有內容，就能讓使用者覺得載入完成。建議您延遲載入圖片、將 JavaScript 套件進行程式碼分割，以及web.dev 建議的其他最佳化做法。
評估 RAIL 的工具
您可以使用幾項工具自動執行 RAIL 評估。具體使用哪一種方式，取決於您需要的資訊類型和偏好的工作流程。
Chrome 開發人員工具
Chrome 開發人員工具可深入分析網頁載入或執行時發生的所有情況。請參閱「開始分析執行階段效能」，熟悉「效能」面板 UI。
下列開發人員工具功能特別實用：
節流 CPU，模擬效能較低的裝置。
節流網路，模擬連線速度較慢的情況。
查看主執行緒活動：查看錄製期間主執行緒上發生的所有事件。
在表格中查看主執行緒活動，並根據活動耗費的時間排序。
分析每秒影格數 (FPS)，評估動畫是否真的流暢。
使用效能監控器，即時監控 CPU 使用率、JS 堆積大小、DOM 節點、每秒版面配置等。
以視覺化方式呈現您使用「網路」部分記錄時發生的網路要求。
在錄製期間擷取螢幕截圖，即可重播網頁載入時的確切樣貌，或動畫觸發時的狀態等。
查看互動：快速找出使用者與網頁互動後發生的情況。
即時找出捲動效能問題：每當可能造成問題的事件監聽器觸發時，系統就會醒目顯示網頁。
即時查看繪製事件，找出可能影響動畫效能的高成本繪製事件。
燈塔
Lighthouse 可在 Chrome 開發人員工具、PageSpeed Insights、Chrome 擴充功能、Node.js 模組和 WebPageTest 中使用。您只要提供網址，工具就會模擬使用緩慢 3G 連線的中階裝置，對網頁執行一系列稽核，然後提供載入效能報表，以及改進建議。
以下稽核特別重要：
回應
首次輸入延遲時間最長預估值。根據主執行緒閒置時間，預估應用程式回應使用者輸入內容所需的時間。
總封鎖時間。 測量網頁無法回應使用者輸入內容 (例如滑鼠點擊、輕觸螢幕或按下鍵盤) 的總時間長度。
互動準備時間。 評估使用者何時能持續與所有網頁元素互動。
載入
未註冊負責控管網頁和 start_url 的 Service Worker。服務工作人員可以在使用者的裝置上快取常見資源，減少透過網路擷取資源所花費的時間。
延後載入畫面外圖片。延遲載入螢幕關閉圖片，直到需要時才載入。
使用合適的圖片大小。請勿放送比行動裝置可視區域中顯示大小大上許多的圖片。
避免 DOM 過大。只傳送轉譯網頁所需的 DOM 節點，減少網路位元組。
WebPageTest
WebPageTest 是一種網頁效能工具，可使用實際瀏覽器存取網頁並收集時間指標。在 webpagetest.org/easy 輸入網址，即可取得詳細報表，瞭解網頁在 Moto G4 裝置上透過緩慢的 3G 連線載入時的效能。您也可以設定納入 Lighthouse 稽核。
摘要
RAIL 是一種觀察網站使用者體驗的工具，可將使用者體驗視為由不同互動組成的歷程。瞭解使用者對您網站的觀感，以便設定對使用者體驗影響最大的成效目標。
專注於使用者需求
在 100 毫秒內回應使用者輸入內容。
在動畫或捲動時，於 10 毫秒內產生影格。
盡量延長主執行緒閒置時間。
在 5000 毫秒內載入互動式內容。