RAIL 是「以使用者為中心」的效能模型,提供可用於評估效能的結構。這個模型會將使用者體驗細分為主要動作 (例如輕觸、捲動、載入),並協助您定義每個動作的成效目標。
RAIL 代表網頁應用程式生命週期的四個面向:回應、動畫、閒置和載入。使用者在上述情況下對效能的期望各有不同,因此成效目標是根據情境和使用者體驗研究,針對使用者感受到的差異定義。
重視使用者
讓使用者成為改善成效的核心。下表說明使用者如何感知效能延遲的重要指標:
使用者對效能延遲的看法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 秒內成為互動體驗
網頁載入緩慢時,使用者註意力會逐漸減少,使用者會將工作視為毀損。可快速載入的網站平均工作階段較長、跳出率較低,以及更高的廣告可視度。
目標:
相較於使用者的裝置和網路功能,加快載入效能的速度。目前,首次載入的理想目標是載入網頁,並在 3G 連線速度較慢的中階行動裝置上,在 5 秒以內進行互動。
後續載入時,理想的目標是在 2 秒內載入網頁。
規範:
利用使用者常見的行動裝置和網路連線來測試負載效能。您可以透過 Chrome 使用者體驗報告瞭解使用者的連線分佈情形。如果您的網站沒有資料,The Mobile Economy 2019 表示,良好的全球基準線是使用 Moto G4 等中階 Android 手機和緩慢的 3G 網路 (也就是 400 毫秒 RTT 和 400 kbps 傳輸速度)。WebPageTest 提供這個組合。
請注意,雖然一般行動裝置使用者可能會聲稱裝置使用的是 2G、3G 或 4G 連線,但實際上,有效連線速度可能會因封包遺失和網路變異而大幅降低。
您不必在 5 秒內載入所有內容,就能察覺完整的負載。請考慮使用延遲載入圖片、程式碼分割 JavaScript 套件,以及其他 web.dev 建議最佳化。
RAIL 測量工具
以下提供幾項工具,幫助您自動進行 RAIL 測量。您可以根據需要的資訊類型,以及偏好使用的工作流程類型來選擇工具。
Chrome 開發人員工具
Chrome 開發人員工具可深入分析網頁載入或執行期間發生的所有情況。請參閱「開始使用分析執行階段效能」,熟悉「效能」面板的 UI。
下列開發人員工具的功能特別相關:
限制 CPU 使用率來模擬效能較低的裝置。
限制網路以模擬較慢的連線。
查看主執行緒活動,查看錄製時主執行緒上發生的所有事件。
查看資料表��的主要執行緒活動,根據活動花費最多時間排序活動。
分析每秒影格數 (FPS),評估動畫是否能順暢執行。
使用效能監控器即時監控 CPU 用量、JS 堆積大小、DOM 節點、每秒版面配置等。
透過「Network」區段,以視覺化方式呈現記錄時發生的網路要求。
在錄製時擷取螢幕截圖,以便播放頁面載入或動畫觸發時的確切畫面,依此類推。
查看互動,可快速找出使用者與網頁互動後發生的網頁。
即時找出捲動效能問題,方法是在可能有問題的事件監聽器觸發時醒目顯示頁面。
即時查看繪製事件,找出可能損害動畫效能的昂貴繪製事件。
燈塔
您可以在 Chrome 開發人員工具、PageSpeed Insights 中,以 Chrome 擴充功能的形式、Node.js 模組和 WebPageTest 使用 Lighthouse。只要提供網址,就能模擬 3G 連線速度緩慢的中階裝置、在網頁上執行一系列稽核,然後提供載入效能報告,以及改善建議。
下列稽核特別具有相關性:
回應
最長首次輸入延遲時間。根據主要執行緒閒置時間,預估應用程式回應使用者輸入內容所需的時間。
總封鎖時間:測量禁止網頁回應使用者輸入內容的總時間長度,例如點按滑鼠、輕觸螢幕或按下鍵盤。
互動時間。評估使用者能否持續與所有網頁元素互動。
載入
未註冊控制網頁和 start_url 的 Service Worker。服務工作站可以在使用者的裝置上快取常見資源,減少透過網路擷取資源的時間。
延遲畫面外圖片。請延後載入畫面外圖片,直到有需要再載入。
適當大小圖片。不要提供明顯大於行動裝置可視區域顯示尺寸的圖片。
避免 DOM 大小過大。只運送轉譯頁面所需的 DOM 節點,藉此減少網路位元組數。
WebPageTest
WebPageTest 是一項網路效能工具,可使用實際瀏覽器存取網頁並收集時間指標。在 webpagetest.org/easy 輸入網址,即可取得 3G 連線速度較慢的 Moto G4 裝置網頁載入效能的詳細報告。您也可以將其設為包含 Lighthouse 稽核。
摘要
RAIL 可讓您檢視網站的使用者體驗,這個歷程由不同互動組成。瞭解使用者如何看待您的網站,設定對使用者體驗影響最大的成效目標。
專注於使用者需求
在 100 毫秒內回應使用者輸入內容。
在動畫或捲動時在 10 毫秒內產生影格。
將主執行緒的閒置時間最大化。
在 5000 毫秒內載入互動式內容。