Measure performance with the RAIL model

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 毫秒內加載交互式內容。

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的什么是 Web 应用性能评测领域的 RAIL 模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。