RAIL，以用戶為核心的性能模型

01-30

譯者註：本篇將使用視頻資源，需要大家採用正確的姿勢閱讀哦。

難道對性能提建議還能有不好的嗎？其實我們都在迴避這個問題的答案：每條優化建議的後面都跟著警告和免責聲明，有時候這些建議還是相互矛盾的。像「 DOM 太慢了」或者「儘可能地使用 CSS 動畫」這樣的大標題之下，掩蓋著的實際場景要複雜的多。

現在最常見的性能話題大概就是「載入時間」吧，就拿它來舉例。有人用 Speed Index 作為衡量的標準；有人以頁面首次繪製時間為準；仍有人使用 body.onload 或 DOMContentLoaded 又或者別的事件為準。衡量的標準並不統一。還有其他衡量性能的方法，比如用 JavaScript 基準（JavaScript benchmark）；比如60 FPS。但是這些標準適用在什麼場合？任何時間點都適用嗎？聽起來有點不現實啊。

我們當中幾乎沒有人可以把時間完全投入在優化上，所以我們需要一個標準來告訴我們現在要去優化什麼東西（或者什麼東西暫時不需要優化了）。該說的都說了，現在我們需要一個明確的指引告訴開發者，在用戶的眼裡「性能」意味著什麼，畢竟用戶才是我們最終服務的對象。

Chrome 團隊已經考慮過這個問題，並提出了 RAIL 模型。用戶在這個性能模型中扮演了很重要的角色。

如果你迫不及待想要把 RAIL 的精髓分享給你的團隊，那可以說說這些：

RAIL 將用戶體驗根據關鍵動作（比如，輕觸、拖拽、滾動、載入）分割到了不同的模塊中。
RAIL 給這些動作制定了性能目標（比如，輕觸後的繪製要在100毫秒之內完成）。
RAIL 提供了一個思考性能問題的方法論，所以當設計師和開發者想要處理對用戶影響最大的問題的時候有法可依。
在講如何運用 RAIL 以及如何使用它輔助你的項目前，讓我們先看看這個模型是怎麼來的。就從大家都很討厭的詞「慢」，開始吧。

「慢」

改變 DOM 結構會拖慢性能？如果在 <head> 標籤中添加 <script>，讓腳本一開始就被載入呢？JavaScript 動畫比 CSS 動畫要慢。一個操作要用 20 毫秒會不會太慢了？0.5 秒呢？10 秒呢？

不同的操作需要的完成時間長短不一，這是肯定的。脫離內容談載入速度都是耍流氓。舉個例子，在瀏覽器空閑的時間裡，代碼在 touch 句柄和遊戲循環（game loop）中的主線路徑的性能要求應該是不同的。換言之，用戶的性能期望會根據產品的內容不同而不同。我們為用戶體驗所做的一切能不能被終端用戶感知到，才是最重要的。事實上，在 Google』s ten things we know to be true 這篇文章中第一條就是「聚焦於用戶，則一切將水到渠成」。

不要再問「『慢』意為著什麼？」了，而應該問「在使用產品時，用戶的感受是怎樣的」。

以用戶為核心，考慮性能

在人機交互領域（HCI）有一個長期的研究項目就是針對這個問題的，你可以從 Jakob Nielsen 的研究成果中得到一些結論。基於研究成果，和現在最受歡迎的動畫效果，我們得到以下閾值：

100 毫秒：用戶採取操作後，要在 100 毫秒內收到響應，才不會有延遲感。
1 秒：在當前時窗中，物體要顯得自然又有整體性。超過了 1 秒，用戶就對當前任務的會失去耐心。對於 web 中的大部分用戶而言，載入頁面或者改變視圖就需要在 1 秒內完成。
16 毫秒：屏幕一秒鐘渲染 60 次，所以每一幀渲染到屏幕上至多 16 毫秒（1000毫秒/60 ~= 16）。人們本能地會跟隨運動，當動畫幀出現中斷或者卡頓，我們常常會覺得不爽。

有了這些閾值，我們就有了參考的標準，下一步就是將這些值映射到開發中。現在讓我們來考慮以下應用場景：[https://youtu.be/4t_Ox_nwHn0]

在上面的視頻中，用戶做了這些事情：

等待頁面載入完成，
觀看酷炫的動畫，
滾動頁面，
輕觸圖標，
觀看導航欄展開的動畫，
等待頁面載入完成，
觀看動畫，
滾動頁面。

給用戶的剛剛採取的動作用色塊做記號，然後得到下面這張圖：

每個色塊代表一個動作，你可以觀察到一共有4個色塊也就是4個動作。emmm，RAIL 也是4個字母呢，美妙的巧合。

讓我們再來看一個視頻，感受一下交互過程吧：

[https://youtu.be/jpJIBQy-a2A]

我們可以把交互的過程分成4個獨立的模塊。在 Google，我們將這些模塊稱為 RAIL，每個模塊都是它們的性能目標，這些目標也是基於我們剛剛介紹過的閾值。

RAIL 性能模型

RAIL 是 response （響應）、 animation（動畫）、idle（瀏覽器空置狀態）和 load（載入）。

從這四個模塊角度來思考你的產品。如果在每個模塊上，你都可以達到性能優化的目標值（也就是上文提及的閾值），那麼最終用戶感受到的將會是極致的體驗。

現在讓我們一個個來看。

Response

如果用戶點擊了一個按鈕，你需要保證在用戶察覺出延遲之前就得到反饋。無論是表單控制還是執行動畫，只要有輸入，這個原則都適用。如果沒有在合理的時窗內完成響應，也就是*採取動作和得到響應之間出現了斷層，用戶將會察覺到這個延遲。

響應的速度根本上來說取決於輸入的延遲，輸入的延遲存在於：指甲觸到屏幕玻璃和實際像素到達屏幕之間。你有沒有過這樣的經歷：輕觸到某種東西，結果它沒有給出任何反應，接著你就會質疑自己那個東西是否真的接收到你的輕觸。這種自我懷疑的場景就是我們想要避免的！

響應的主要交互是：

tapping（輕觸） – 當用戶輕觸或者點擊一個按鈕或者圖標時（比如，輕觸菜單圖標打開一個抽屜導航）。

要得到響應式的回應，我們需要：

在首次收到輸入時，在100毫秒內得到回應。
理想情況下，收到的回應就是最終結果。但如果最終結果還需要花更長的時間得到，那也要給用戶一個「載入中」的標識，或是顏色的變更，告訴用戶「本產品已經接收到了指令，還在處理中」，不至於讓用戶自我懷疑

2. Animation

動畫現在是應用的一大支柱，從滾動到視圖變化，都有動畫的身影。我們要明確在這段時間裡能做些什麼，因為用戶可能常常是直接操作，幀率的改變很容易被察覺到。但是用戶想要的只是流暢的響應而已。

動畫包含了以下概念：

視覺動畫
這個包括了動畫的開始和退出，狀態改變時的動畫，還有載入標識。
滾動
當用戶開始滾動頁面，頁面出現猛動的情況。
拖拽
當我們需要對用戶的拖拽交互在100毫秒以內做出響應時，比如平移地圖或者縮放屏幕時，我們需要依賴動畫。

要合理地動畫，每一幀動畫要在16毫秒內完成，才能達到60FPS（1000ms/60 ~= 16.6 ms）。

3. IDLE

要製作響應迅速動畫精良的應用通常需要比較長的工時。Optimistic UI模式利用這個技術達到了很好的效果。並非所有工作都要在 response 階段或者 load 階段完成：評論引導、組件初始化、數據檢索和排序和分析數據的送都不是需要立刻傳達給用戶的，所以可以在瀏覽器空閑的時候再處理這些任務。

要想合理地應用瀏覽器空閑時間，最好把時間以 50 毫秒為單位分組。為什麼要這麼做呢？在上文里也提到的，用戶做出動作後，應用應該在 100 毫秒內給出響應，不應該出現一個模板渲染 2 秒之久。

4. LOAD

頁面載入時間是最常見的性能話題。對用戶來說最先看到的內容應該是最有意義、最先被載入出來的。接著頁面要持續響應用戶，絕對不允許出現在滾動頁面、輕觸或者看動畫的時候卡頓。特別是當多個頁面使用同一個線程的時候，要實現這樣的目標真的很困難。

想要儘快將頁面載入出來，我們需要把最需要傳達的內容在 1 秒內渲染出來。超過 1 秒鐘，用戶的注意力就會被分散，當前執行的任務將有中斷感。要達到在 1 秒內渲染完畢的目標，我們要優先考慮關鍵渲染路徑，將所有不需要在載入時處理的任務延遲到瀏覽器空閑時再處理（或根據需求攔載入）。

性能目標

性能本質上來說是逃避工作的藝術，但是當它變得不可逃避的時候，保證你做的工作是高效的、花在處理問題上的時間是值得的。

既然現在我們有了 RAIL 模型，讓我們來總結一個性能目標吧

如何實踐

這裡有幾條好用的提升性能的方法：

將用戶的使用場景設定成 MacBook Pro 或者類似配置的機器是不合理的，大多數用戶使用的設備都比開發測試時用的設備性能落後個 10 倍！

Nexus 4 配置中端，是很不錯測試設備。
在 3G 環境下測試。
仔細分析你的數據，看看你的用戶用的都是什麼設備。然後你就能在測試階段感受到 90% 的用戶的體驗效果啦。

電源和內存

如果達到了上述的性能目標，但把用戶的設備搞的內存一點兒不剩還只剩下 10% 的電量，那用戶也會很不高興的。

現在我們還不能確定如何處理共享資源，不過可以確定在之後我們會想出解決方案，到時候就改名為 BLAIMR 或者 PRIMAL 了（B 代表電池，M 代表內存）。

商業前景

通常我們都是為了興趣而工作，因為我們超愛做一些很酷的東西。我們當然不能憑空想工作，我們需要把商業計劃交給經理、持股人還有客戶，性能會影響到用戶體驗的問題，自然也指的關注。

幸運的是，很多大公司都願意同我們共享數據，來完善這個模型，以下是一些案例：

Google: 2% slower = 2% less searching per user
Yahoo: 400 milliseconds faster = 9% more traffic
AOL: Faster pages = more page views
Amazon: 100 milliseconds faster = 1% more revenue
Shopzilla: 5 seconds faster = 25% more page views, 7 to 12% more revenue
Aberdeen Group: 1 second slower = 11% fewer page views, 7% less conversion
Google uses website speed in search ranking.

總結

RAIL 模型通過將用戶的交互行為劃分為不同區塊，來檢驗一個產品的用戶體驗。當你了解了每個交互模塊，你將會知道用戶期望得到的是什麼，換言之，你的目標是什麼。

摸索目標的過程很辛苦，但是以誠心對待用戶，用戶也會如此對待你的（產品）。

資源

如果你想要了解更多關於 RAIL 的資料，可以看看下面的鏈接：

演示

+ 「Performance RAIL』s: The Art and Science of optimizing for Silicon and Wetware」 (slides), Ilya Grigorik, Google, May 2015

+ 「How Users Perceive the Speed of The Web」 (slides), Paul Irish, FluentConf, April 2015

+ 「Performance on RAILs」 (視頻), Paul Lewis, Nordic.js, September 2015

各種文檔

+ 「Optimizing Performance,」 Web Fundamentals, Google Developers

+ 「Browser Rendering Optimization」 (course), Udacity

+ 「Profile」 (performance), Google Web Tools, Google Developers

+ 「The RAIL Performance Model,」 Web Fundamentals, Google Developers

性能調查

+ Performance Audit of theverge.com」 (July 2015) (complementary slides)

+ Performance Audit of imore.com」 (July 2015)

+ Performance Audit of m.reddit.com」 (July 2015)

+ Performance Audit of m.espn.com」 (April 2015)

+ Performance Audit of squarespace.com」 (April 2015)

+ Performance Audit of cafepress.com」 (April 2015)

+ Performance Audit of CNET, Wikipedia and Time.com」 (February 2015) (complementary slides)

+ Performance Audit of Wikipedia Rich Editor」 (February 2015)

原文鏈接：Introducing RAIL: A User-Centric Model For Performance

前端外刊評論の微博