RAIL 是一種以使用者為中心的性能模型，它提供了一種考慮性能的結構。 該模型将使用者體驗分解為關鍵操作（例如，點選、滾動、加載）并幫助您為每個操作定義性能目标。
RAIL 代表 Web 應用程式生命周期的四個不同方面：響應、動畫、空閑和加載，即 response, animation, idle 和 load的縮寫。使用者對這些上下文中的每一個都有不同的性能期望，是以性能目标是根據上下文和使用者如何感覺延遲的 UX 研究來定義的。
Focus on the user
讓使用者成為性能工作的焦點。 下表描述了使用者如何感覺性能延遲的關鍵名額：
使用者對性能延遲的看法
0 到 16 毫秒 使用者非常擅長跟蹤運動，并且不喜歡動畫不流暢時的跟蹤。 隻要每秒渲染 60 個新幀，他們就會認為動畫很流暢。 這是每幀 16 毫秒，包括浏覽器将新幀繪制到螢幕所需的時間，讓應用程式生成一個幀大約需要 10 毫秒。
0 到 100 ms 在此時間視窗内響應使用者操作，使用者感覺結果是立竿見影的。 如果超過這個時延，行動和反應之間的聯系就被打破了。
100 到 1000 ms 在這個視窗内，事情感覺是任務自然和連續進展的一部分。 對于網絡上的大多數使用者來說，加載頁面或更改視圖是一項任務。
1000 毫秒或更多 超過 1000 毫秒（1 秒），使用者會失去對他們正在執行的任務的注意力。
10000 毫秒或更多 超過 10000 毫秒（10 秒），使用者感到沮喪并可能放棄任務。 他們以後可能會也可能不會回來。
Goals and guidelines
在 RAIL 的上下文中，術語目标(goals)和指南(guidelines)具有特定含義：
目标:與使用者體驗相關的關鍵性能名額。 例如，點選即可在 100 毫秒内渲染。 由于人類的感覺是相對恒定的，這些目标不太可能很快改變。
準則:幫助您實作目标的建議。 這些可能特定于目前的硬體和網絡連接配接條件，是以可能會随着時間而改變。
Response: process events in under 50ms
目标：在 100 毫秒内完成由使用者輸入啟動的轉換，讓使用者感覺互動是即時的。
準則：
為確定 100 毫秒内的可見響應，請在 50 毫秒内處理使用者輸入事件。 這适用于大多數輸入，例如單擊按鈕、切換表單控件或啟動動畫。 這不适用于觸摸拖動或滾動。
盡管這聽起來有悖常理，但立即響應使用者輸入并不總是正确的做法。 您可以使用這個 100 毫秒的視窗來做其他昂貴的工作，但要注意不要阻塞使用者。 如果可能，請在背景工作。
對于需要 50 毫秒以上才能完成的操作，請始終提供回報。
50 ms 還是 100 ms？
目标是在 100 毫秒内響應輸入，那麼為什麼我們的預算隻有 50 毫秒？ 這是因為除了輸入處理之外，通常還有其他工作要做，并且這些工作占用了可接受的輸入響應的部分可用時間。 如果應用程式在空閑時間在推薦的 50 毫秒塊中執行工作，這意味着如果輸入在這些工作塊之一期間發生，則它可以排隊最多 50 毫秒。 考慮到這一點，可以安全地假設隻有剩餘的 50 毫秒可用于實際輸入處理。下圖顯示了這種效果，該圖顯示了在空閑任務期間收到的輸入如何排隊，進而減少了可用的處理時間：
Animation: produce a frame in 10 ms
目标：
在 10 毫秒或更短的時間内生成動畫中的每一幀。 從技術上講，每幀的最大預算為 16 毫秒（1000 毫秒/每秒 60 幀≈16 毫秒），但浏覽器需要大約 6 毫秒來渲染每幀，是以每幀 10 毫秒的準則。
以視覺平滑為目标。 使用者會注意到幀速率何時發生變化。
在像動畫這樣的高壓點中，關鍵是在你能做的地方什麼都不做，在你不能做的地方絕對最少。 盡可能利用 100 毫秒響應預先計算昂貴的工作，以便最大限度地提高達到 60 fps 的機會。
有關各種動畫優化政策，請參閱渲染性能。
認識所有類型的動畫。 動畫不僅僅是花哨的 UI 效果。 這些互動中的每一個都被視為動畫：
視覺動畫，例如入口和出口、補間和加載訓示器。
滾動。 這包括甩動，即使用者開始滾動，然後放手，頁面繼續滾動。
拖拽操作。 動畫通常遵循使用者互動，例如平移地圖或捏合縮放。
Idle: maximize idle time
目标：最大化空閑時間以增加頁面在 50 毫秒内響應使用者輸入的幾率。
利用空閑時間完成延期工作。 例如，對于初始頁面加載，加載盡可能少的資料，然後使用空閑時間加載其餘的資料。
在 50 毫秒或更短的空閑時間内執行工作。 再這樣下去，您就有可能幹擾應用程式在 50 毫秒内響應使用者輸入的能力。
如果使用者在空閑時間工作期間與頁面互動，則使用者互動應始終具有最高優先級并中斷空閑時間工作。
Load: deliver content and become interactive in under 5 seconds
當頁面加載緩慢時，使用者注意力會遊移，使用者會認為任務已損壞。 加載速度快的網站具有更長的平均會話、更低的跳出率和更高的廣告可見度。
優化與使用者的裝置和網絡功能相關的快速加載性能。 目前，首次加載的一個很好的目标是加載頁面并在 5 秒或更短的時間内在 3G 連接配接速度較慢的中端移動裝置上進行互動。
對于後續加載，一個好的目标是在 2 秒内加載頁面。
指南：
在您的使用者中常見的移動裝置和網絡連接配接上測試您的負載性能。 您可以使用 Chrome 使用者體驗報告來了解您使用者的連接配接分布。 如果資料不适用于您的站點，移動經濟 2019 建議良好的全球基線是中端 Android 手機，例如 Moto G4 和慢速 3G 網絡（定義為 400 ms RTT 和 400 kbps 傳輸速度 ）。 此組合在 WebPageTest 上可用。
請記住，盡管您的典型移動使用者的裝置可能聲稱它使用的是 2G、3G 或 4G 連接配接，但實際上，由于資料包丢失和網絡差異，有效連接配接速度通常要慢得多。
消除渲染阻塞資源。
您不必在 5 秒内加載所有内容即可産生完整加載的感覺。 考慮延遲加載圖像、代碼拆分 JavaScript 包以及 web.dev 上建議的其他優化。
認識影響頁面加載性能的因素：
網絡速度和延遲
硬體（例如，較慢的 CPU）
緩存驅逐(cache eviction)
L2/L3 緩存的差異
解析 JavaScript
Tools for measuring RAIL
有一些工具可以幫助您自動執行 RAIL 測量。 您使用哪一種取決于您需要什麼類型的資訊，以及您喜歡什麼類型的工作流程。
Chrome DevTools
以下 DevTools 功能特别相關：
限制 CPU 以模拟功能較弱的裝置
限制網絡以模拟較慢的連接配接
檢視主線程活動以檢視錄制時主線程上發生的每個事件
使用 Main 部分檢視頁面主線程上發生的活動。
檢視表中的主線程活動，以根據占用時間最多的活動對活動進行排序。
記錄頁面後，您無需僅依賴 Main 部分來分析活動。 DevTools 還提供了三個用于分析活動的表格視圖。 每個視圖都讓您對活動有不同的看法：
如果要檢視導緻最多工作的根活動，請使用“調用樹”頁籤。
如果要檢視直接花費時間最多的活動，請使用自下而上(Bottom-Up)頁籤。
如果要按記錄期間活動的發生順序檢視活動，請使用“事件日志”頁籤。
分析每秒幀數 (FPS) 以衡量您的動畫是否真正流暢地運作
使用性能螢幕實時監控 CPU 使用率、JS 堆大小、DOM 節點、每秒布局等
使用“網絡”部分可視化錄制時發生的網絡請求
在錄制時捕獲螢幕截圖以準确回放頁面加載時頁面的外觀，或動畫觸發等。
檢視互動以快速識别使用者與其互動後頁面上發生的情況
使用互動部分查找和分析錄制期間發生的使用者互動。
通過在潛在問題偵聽器觸發時突出顯示頁面來實時查找滾動性能問題。
實時檢視繪制事件以識别可能損害動畫性能的代價高昂的繪制事件。
Lighthouse
Lighthouse 可在 Chrome DevTools、web.dev/measure、Chrome 擴充、Node.js 子產品和 WebPageTest 中使用。 你給它一個 URL，它模拟一個 3G 連接配接速度較慢的中端裝置，在頁面上運作一系列審計，然後給你一份負載性能報告，以及如何改進的建議。
以下稽核尤其相關：
response
Max Potential First Input Delay：根據主線程空閑時間估計您的應用響應使用者輸入所需的時間。
不使用被動偵聽器來提高滾動性能。
總阻塞時間。測量頁面被阻止響應使用者輸入（例如滑鼠點選、螢幕點選或鍵盤按下）的總時間。
Time To Interactive：衡量使用者何時可以始終如一地與所有頁面元素進行互動。
Load
不注冊控制 page 和 start_url 的 service worker。 Service Worker 可以緩存使用者裝置上的公共資源，進而減少通過網絡擷取資源所花費的時間。
移動網絡上的頁面加載速度不夠快。
推遲螢幕外圖像(offscreen images). 推遲加載螢幕外圖像，直到需要它們。
适當大小的圖像。 不要提供明顯大于移動視口中呈現的尺寸的圖像。
避免連結關鍵請求。
不對其所有資源使用 HTTP/2。
有效地編碼圖像。
啟用文本壓縮。
避免巨大的網絡負載。
避免過大的 DOM 大小。 通過僅傳送呈現頁面所需的 DOM 節點來減少網絡位元組。
總結
以使用者為中心。
在 100 毫秒内響應使用者輸入。
動畫或滾動時，在 10 毫秒内生成一幀。
最大化主線程空閑時間。
在 5000 毫秒内加載互動式内容。