[Measure performance with the RAIL model](https://web.dev/rail/)

RAIL 是一種以使用者為中心的效能模型，它提供了一種考慮效能的結構。 該模型將使用者體驗分解為關鍵操作（例如，點選、滾動、載入）並幫助您為每個操作定義效能目標。

RAIL 代表 Web 應用程式生命週期的四個不同方面：響應、動畫、空閒和載入，即 response, animation, idle 和 load的縮寫。使用者對這些上下文中的每一個都有不同的效能期望，因此效能目標是根據上下文和使用者如何感知延遲的 UX 研究來定義的。

![](https://img-blog.csdnimg.cn/img_convert/0cc268090489235f6e57aa059a6b4b77.png)

# 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 毫秒可用於實際輸入處理。下圖顯示了這種效果，該圖顯示了在空閒任務期間收到的輸入如何排隊，從而減少了可用的處理時間：

![](https://img-blog.csdnimg.cn/img_convert/ec361eaf8dfdf5655630e4ecb6362c17.png)

# Animation: produce a frame in 10 ms

目標：

在 10 毫秒或更短的時間內生成動畫中的每一幀。 從技術上講，每幀的最大預算為 16 毫秒（1000 毫秒/每秒 60 幀≈16 毫秒），但瀏覽器需要大約 6 毫秒來渲染每幀，因此每幀 10 毫秒的準則。

以視覺平滑為目標。 使用者會注意到幀速率何時發生變化。

準則：

在像動畫這樣的高壓點中，關鍵是在你能做的地方什麼都不做，在你不能做的地方絕對最少。 儘可能利用 100 毫秒響應預先計算昂貴的工作，以便最大限度地提高達到 60 fps 的機會。

有關各種動畫最佳化策略，請參閱[渲染效能](https://developers.google.com/web/fundamentals/performance/rendering)。

認識所有型別的動畫。 動畫不僅僅是花哨的 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 以模擬功能較弱的裝置

![](https://img-blog.csdnimg.cn/img_convert/deb857d4f20060bb2d695eb8d7adb13a.png)

### 限制網路以模擬較慢的連線

![](https://img-blog.csdnimg.cn/img_convert/fd89ec4780cb9b941c4d0383e5b554fd.png)

### 檢視主執行緒活動以檢視錄製時主執行緒上發生的每個事件

使用 Main 部分檢視頁面主執行緒上發生的活動。

![](https://img-blog.csdnimg.cn/img_convert/71da8965b5156367cfe5c4da994eed43.png)

檢視錶中的主執行緒活動，以根據佔用時間最多的活動對活動進行排序。

記錄頁面後，您無需僅依賴 Main 部分來分析活動。 DevTools 還提供了三個用於分析活動的表格檢視。 每個檢視都讓您對活動有不同的看法：

* 如果要檢視導致最多工作的根活動，請使用“呼叫樹”選項卡。
* 如果要檢視直接花費時間最多的活動，請使用自下而上(Bottom-Up)選項卡。
* 如果要按記錄期間活動的發生順序檢視活動，請使用“事件日誌”選項卡。

### 分析每秒幀數 (FPS) 以衡量您的動畫是否真正流暢地執行

### 使用效能監視器實時監控 CPU 使用率、JS 堆大小、DOM 節點、每秒佈局等

### 使用“網路”部分視覺化錄製時發生的網路請求

![](https://img-blog.csdnimg.cn/img_convert/d891a991f982e82f16abbc6494c13409.png)

在錄製時捕獲螢幕截圖以準確回放頁面載入時頁面的外觀，或動畫觸發等。

### 檢視互動以快速識別使用者與其互動後頁面上發生的情況

使用互動部分查詢和分析錄製期間發生的使用者互動。

![](https://img-blog.csdnimg.cn/img_convert/2eedd49378fce9f5a345fd9a0bbc9bbe.png)

透過在潛在問題偵聽器觸發時突出顯示頁面來實時查詢滾動效能問題。

實時檢視繪製事件以識別可能損害動畫效能的代價高昂的繪製事件。

# 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 毫秒內載入互動式內容。

什麼是 Web 應用效能評測領域的 RAIL 模型

相關文章