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

難道

對效能提建議

還能有不好的嗎？其實我們都在

迴避這個問題的答案

：每條最佳化建議的後面都跟著警告和免責宣告，有時候這些建議還是相互矛盾的。像“ DOM 太慢了”或者“儘可能地使用 CSS 動畫”這樣的大標題之下，掩蓋著的實際場景要複雜的多。

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

我們當中幾乎沒有人可以把時間完全投入在最佳化上，所以我們需要一個標準來告訴我們現在要去最佳化什麼東西（或者什麼東西暫時不需要優化了）。該說的都說了，現在我們需要一個明確的指引告訴開發者，

在使用者的眼裡

“效能”意味著什麼，畢竟使用者才是我們最終服務的物件。

Chrome 團隊已經考慮過這個問題，並提出了

RAIL

模型。使用者在這個效能模型中扮演了很重要的角色。

如果你迫不及待想要把

RAIL

的精髓分享給你的團隊，那可以說說這些：

RAIL 將使用者體驗根據關鍵動作（比如，輕觸、拖拽、滾動、載入）分割到了不同的模組中。

RAIL 給這些動作制定了效能目標（比如，輕觸後的繪製要在100毫秒之內完成）。

RAIL 提供了一個思考效能問題的方法論，所以當設計師和開發者想要處理對使用者影響最大的問題的時候有法可依。

在講如何運用 RAIL 以及如何使用它輔助你的專案前，讓我們先看看這個模型是怎麼來的。就從大家都很討厭的詞“慢”，開始吧。

“慢”

改變 DOM 結構會拖慢效能？如果在 標籤中新增