web性能優化——使用RAIL模型評估性能

RAIL 簡介

RAIL 是一種以用戶爲中心的性能模型。每一個網絡應用均具備與其生命週期有關的四個不一樣方面，且這些方面以不一樣的方式影響着性能：

RAIL核心思想是以用戶爲中心；最終目標不是讓您的網站在任何特定設備上都能運行很快，而是使用戶滿意。主要包含如下幾個方面：

• 當即響應用戶；在 100 毫秒之內確認用戶輸入。
• 設置動畫或滾動時，在 10 毫秒之內生成幀。
• 最大程度增長主線程的空閒時間。
• 持續吸引用戶；在 1000 毫秒之內呈現交互內容。

以用戶爲中心

讓用戶成爲您的性能工做的中心。用戶花在網站上的大多數時間不是等待加載，而是在使用時等待響應。下表是用戶時間與用戶反應的關係：

延遲	用戶反應
0 - 16 毫秒	人們特別擅長跟蹤運動，若是動畫不流暢，他們就會對運動心生反感。 用戶能夠感知每秒渲染 60 幀的平滑動畫轉場。也就是每幀 16 毫秒（包括瀏覽器將新幀繪製到屏幕上所需的時間），留給應用大約 10 毫秒的時間來生成一幀。
0 - 100 毫秒	在此時間窗口內響應用戶操做，他們會以爲能夠當即得到結果。時間再長，操做與反應之間的鏈接就會中斷。
100 - 300 毫秒	用戶會遇到輕微可覺察的延遲。
300 - 1000 毫秒	在此窗口內，延遲感受像是任務天然和持續發展的一部分。對於網絡上的大多數用戶，加載頁面或更改視圖表明着一個任務。
1000+ 毫秒	超過 1 秒，用戶的注意力將離開他們正在執行的任務。
10,000+ 毫秒	用戶感到失望，可能會放棄任務；以後他們或許不會再回來。

響應：在 100 毫秒之內響應

在用戶注意到滯後以前您有 100 毫秒的時間能夠響應用戶輸入。這適用於大多數輸入，無論他們是在點擊按鈕、切換表單控件仍是啓動動畫。但不適用於觸摸拖動或滾動。

若是您未響應，操做與反應之間的鏈接就會中斷。用戶會注意到。

儘管很明顯應當即響應用戶的操做，但這並不老是正確的作法。使用此 100 毫秒窗口執行其餘開銷大的工做，但須要謹慎，以避免妨礙用戶。若是可能，請在後臺執行工做。

對於須要超過 500 毫秒才能完成的操做，請始終提供反饋。

動畫：在 10 毫秒內生成一幀

若是動畫幀率發生變化，您的用戶確實會注意到。您的目標就是每秒生成 60 幀，每一幀必須完成如下全部步驟：

從純粹的數學角度而言，每幀的預算約爲 16 毫秒（1000 毫秒 / 60 幀 = 16.66 毫秒/幀）。 但由於瀏覽器須要花費時間將新幀繪製到屏幕上，只有 10 毫秒來執行代碼。

在像動畫同樣的高壓點中，關鍵是不論能不能作，什麼都不要作，作最少的工做。 若是可能，請利用 100 毫秒響應預先計算開銷大的工做，這樣您就能夠儘量增長實現 60fps 的可能性。
如需瞭解詳細信息，請參閱渲染性能。

空閒：最大程度增長空閒時間

利用空閒時間完成推遲的工做。例如，儘量減小預加載數據，以便您的應用快速加載，並利用空閒時間加載剩餘數據。

推遲的工做應分紅每一個耗時約 50 毫秒的多個塊。若是用戶開始交互，優先級最高的事項是響應用戶。

要實現小於 100 毫秒的響應，應用必須在每 50 毫秒內將控制返回給主線程，這樣應用就能夠執行其像素管道、對用戶輸入做出反應，等等。

以 50 毫秒塊工做既能夠完成任務，又能確保即時的響應。

加載：在 1000 毫秒之內呈現內容

在 1 秒鐘內加載您的網站。不然，用戶的注意力會分散，他們處理任務的感受會中斷。

側重於優化關鍵渲染路徑以取消阻止渲染。

關鍵 RAIL 指標彙總

要根據 RAIL 指標評估您的網站，請使用 Chrome DevTools Timeline 工具記錄用戶操做。而後根據這些關鍵 RAIL 指標檢查 Timeline 中的記錄時間。

RAIL 步驟	關鍵指標	用戶操做
響應	輸入延遲時間（從點按到繪製）小於 100 毫秒。	用戶點按按鈕（例如打開導航）。
動畫	每一個幀的工做（從 JS 到繪製）完成時間小於 16 毫秒。	用戶滾動頁面，拖動手指（例如，打開菜單）或看到動畫。 拖動時，應用的響應與手指位置有關（例如，拉動刷新、滑動輪播）。 此指標僅適用於拖動的持續階段，不適用於開始階段。
空閒	主線程 JS 工做分紅不大於 50 毫秒的塊。	用戶沒有與頁面交互，但主線程應足夠用於處理下一個用戶輸入。
加載	頁面能夠在 1000 毫秒內就緒。	用戶加載頁面並看到關鍵路徑內容。