性能優化模型

目錄

• 引子
• RAIL Model
  • 目標和方針
  • 關注用戶
  • Response
  • Animation
  • Idle
  • Load
• PRPL Pattern
• 參考資料

引子

在 About Performance 的最後提供了一些關注的點，但感受比較零散，有沒有理論體系化的思想做爲依據，經過查找資料，發現了兩種指導方式：RAIL Model 和 PRPL Pattern ，下面是帶有我的理解的部分翻譯。

翻譯時 RAIL Model 原文 Last updated 2019-02-12 ，PRPL Pattern 原文 Last updated: Nov 5, 2018 。

• Origin
• My GitHub

RAIL Model

RAIL 是一個以用戶爲中心的性能模型，它將用戶的體驗分解爲關鍵的操做。RAIL 的目標和方針旨在幫助開發人員和設計人員確保每個操做都有良好的用戶體驗。經過設計一個考慮性能的結構，RAIL 使設計人員和開發人員可以有效的關注影響用戶體驗最大的工做。

每一個 web 應用程序的生命週期都有四個不一樣的方面，性能以不一樣的方式適合它們：

目標和方針

在 RAIL 的上下文中，目標（goals）和方針（guidelines）有特殊的含義：

• 目標：用戶體驗相關的關鍵性能指標。由於人類的感知是相對穩定的，因此這些目標不太可能很快改變。
• 方針：幫助你實現目標的建議。這些多是特定於當前的硬件和網絡鏈接條件，所以可能隨着時間發生改變。

關注用戶

讓用戶成爲你的性能工做的焦點。下表描述了用戶如何感知性能延遲的關鍵指標：

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

用戶對性能延遲的感知不一樣，這取決於網絡條件和硬件。例如，經過快速 Wi-Fi 鏈接在功能強大的臺式機上，1000ms 內的加載體驗是合理的，所以用戶已經習慣了 1000ms 的加載體驗。但低於 3G 鏈接速度較慢的移動設備來講，5000ms 內的加載體驗是一個更實際的目標，所以移動用戶一般更耐心。

Back to top

Response：在 50ms 內處理事件

目標

在 100ms 內完成由用戶輸入啓動的過分。用戶花費大部分時間是在等待站點響應他們的輸入，而不是等待站點加載。

方針

• 在 50ms 內處理用戶輸入事件，是爲了保證 100ms 內有可見的響應，不然動做與反應的聯繫就會斷開。這適用於大多數輸入，例如單擊按鈕、切換表單控件或啓動動畫。這不適用於觸摸拖動或滾動。
• 儘管這聽起來可能有違直覺，但對用戶輸入作出當即響應並不老是正確的。你能夠用這個 100ms 的窗口作其它昂貴的工做。但要注意不要阻塞用戶，若是可能的話，在後臺工做。
• 對於須要超過 50ms 才能完成的操做，始終提供反饋。

50ms 仍是 100ms ?

目標是在 100ms 內響應輸入，那麼爲何咱們的預算只有 50ms ？這是由於除了輸入處理以外，一般還有其它的工做正在處理，而這部分工做佔據了可接受輸入響應的部分時間。若是應用程序在空閒時間以建議的 50ms 執行工做，這意味着若是在其中一個工做塊期間發生輸入，則輸入的排列等候能夠長達 50ms。根據這一點，假設只有剩餘 50ms 可用於實際的輸入處理是安全的。此效果在下圖中可見，顯示了在空閒任務隊列中，輸入是如何接受的，從而縮短了可用的處理時間：

Back to top

Animation：10ms 內生成一幀

目標

• 在10ms 或更短的時間內生成動畫中的每一幀。技術上，每幀的最大預算是 16ms（1000ms / 60幀/s ≈ 16ms），可是瀏覽器須要大約 6ms 來渲染每一個幀，所以每幀指導方針是 10ms 。
• 以視覺平滑度爲目標。當幀速率變化時，用戶會注意到。

方針

• 在像動畫這樣的高壓點中，關鍵是不論能不能作，什麼都不要作，作最少的工做。若是可能，利用 100ms 響應預先計算開銷大的工做，這樣你就能夠儘量增長實現 60fps 的可能性。
• 查看 Rendering Performance 中動畫優化策略。
• 識別全部類型的動畫。動畫不只僅是精緻的 UI 效果。這些交互都被視爲動畫：
  • 視覺動畫，例如進入、退出、補間和加載提示。
  • 滾動，包括拋擲，也就是用戶開始滾動，而後放開，頁面繼續滾動。
  • 拖拽，動畫一般遵循用戶交互，如平移地圖或捏縮放。

Back to top

Idle：最大化空閒時間

目標

最大化空閒時間以增長頁面在 50ms 內響應用戶輸入的可能性。

方針

• 利用空閒時間完成延遲的工做。例如，對於初始頁面加載，加載儘量少的數據，而後使用空閒時間加載其他的數據。
• 在 50ms 或更短的空閒時間內執行工做。再長一點，你就有可能干擾應用程序在 50ms 內響應用戶輸入的能力。
• 若是用戶在空閒時間工做期間與頁面交互，則用戶交互應始終具備最高優先級並中斷空閒時間工做。

Back to top

Load：傳送內容並在 5s 內具有可交互性

當頁面加載緩慢時，用戶的注意力就會轉移，用戶會認爲任務已經中斷。快速加載的站點具備更長的平均會話時間、更低的跳出率和更高的廣告可視性。

目標

• 快速加載性能的優化與用戶用於訪問站點的設備和網絡功能相關。目前，一個好的目標是，第一次加載的頁面，在 5s 或更短的時間內在3G鏈接速度較慢的中檔移動設備上具有可交互性。見 Can You Afford It?: Real-world Web Performance Budgets 。但要注意這些目標可能會隨着時間的推移而改變。
• 對於後續加載，一個好的目標是在 2s 內加載頁面。但這個目標也可能隨着時間的推移而改變。

方針

• 在用戶之間常見的移動設備和網絡鏈接上測試加載性能。若是您的企業有關於用戶使用的設備和網絡鏈接的信息，則可使用該組合並設置本身的加載性能目標。不然，能夠參考 The Mobile Economy 中的年度數據，選擇合適的目標。
• 請記住，儘管你的典型移動用戶可能聲稱它的設備是在 2G、3G 或 4G 鏈接上，但實際上，因爲數據包丟失和網絡變化，有效鏈接速度一般要慢得多。
• 專一於優化 Critical Rendering Path 。
• 沒有必要在 5 秒內加載全部的東西，以產生一種完整加載的感受。啓用漸進式渲染並在後臺執行某些操做。將非必要加載推遲到空閒時間段。
• 識別影響頁面加載性能的因素：
  • 網絡速度和延遲
  • 硬件（例如 CPU 速度慢）
  • 緩存回收
  • 二級/三級緩存的差別
  • JavaScript 解析

Back to top

PRPL Pattern

PRPL 描述了一種模式，用於使網頁更快的加載並變得可交互：

• Push（或者 preload）最重要的資源。
• 儘快渲染（Render）初始路徑。
• 預緩存（Pre-cache）剩餘資源.
• 延遲加載（Lazy load）其餘路由和非關鍵資源。

Apply instant loading with the PRPL pattern 中主要結合了一種工具進行講解，偏重實際操做，這裏就很少介紹了。

參考資料

• Measure Performance with the RAIL Model
• Apply instant loading with the PRPL pattern