[譯] 開啟效能預算

• 原文地址：Start Performance Budgeting
• 原文作者：Addy Osmani
• 譯文出自：掘金翻譯計劃
• 本文永久連結：github.com/xitu/gold-m…
• 譯者：Sam
• 校對者：Augustwuli, Calpa

如果你正在構建網站體驗，並且希望保持快速，效能預算也許就非常重要。為了能夠成功，需要接受效能預算並且學會在生活中運用它們。移動裝置上的網路以及 CPU 限制會提出諸如”對我的使用者來說真正重要的是什麼？“這樣的難題。

當我們同致力於提高效能的世界 500 強企業對話時，(瞭解到)一旦迴歸到功能開發，效能指標通常會快速回歸。效能預算幫助團隊確定功能的優先順序，優化並促進討論對使用者真正重要的是什麼。

“在專案早期的適當階段，擁有一個預設好的 ‘預算’ 會是一個清晰並切實的方式，可用來決定專案中應該包含什麼。” —— Mark Perkins

什麼是效能預算？

效能預算是一個團隊不能允許超過的頁面限制。它可以是最大的 JavaScript 包大小，所有影象的總體量，特定的載入時間（例如，在 3G/4G 網路上 5s 以內的互動時間）或者其它任何數量指標的閾值。

當然效能預算不僅僅是做門檻限制。它們更像財務預算，需要有意識的使用。把它們看作是在使用者體驗上花費和交易的貨幣。在 JavaScript 成本仍然較高的移動裝置環境中，預算可以說是指導我們取得成功的少數工具之一。

效能預算指標

效能預算的指標包括里程碑時間，基於數量的指標和基於規則的指標。

里程碑時間：基於載入一個頁面的使用者體驗的時間（例如，互動時間，首次內容繪製時間）。你會經常需要配對幾個里程碑時間，用來準確地描述頁面載入的整個過程。有些團隊還會維護自定義指標，譬如 Twitter 的“首次推文時間”。

基於數量的指標：基於原始值（例如：JavaScript 的體量（KB/MB），HTTP 請求數量）。這些都側重於瀏覽器體驗。

基於規則的指標：通過像 Lighthouse 或 WebPageTest 這樣的工具打分。通常是用單個數字或系列為你的網站評級。

如果一個 PR 降低了效能，包含效能預算的團隊通常會有 CI 告警或者構建錯誤提示。Lighthouse CI 現在支援當某一類別（比如效能）跌落到特定的值以下時，減低其 Lighthouse 分數：

一個基於“規則”的效能預算實際例子。使用 Lighthouse CI，我們可以給預算設定一個效能分數。如果他們的效能分低於一個特定的值，那麼 PR 就會失敗。

預算的例子

• 我們的產品頁面在移動端上釋出的 JavaScript 程式碼必須少於 170KB
• 我們的搜尋頁面包含的桌面圖片不能超過 2MB
• 我們的主頁必須在慢速的 3G/Moto G4（網路）上 5s 內載入並可互動
• 我們的部落格必須在 Lighthouse 的效能審查中獲得 80+ 的分數

下面是一個數量指標 —— 在 SpeedCurve 上 The Guardian’s 桌面網站的 JS 大小。它在預算範圍內以黃色高亮顯示，在超出預算時以紅色顯示。

我們還可以將里程碑指標視覺化。下面是第一次互動（這時第一個 CPU 空閒） —— 標記了瀏覽器主執行緒被任何單個任務阻塞不超過 50 毫秒的時間點，因此可以快速響應使用者的輸入。

預算會因為很多因素而不同，包括目標裝置級別。比較 Guardian 的移動端和桌面端體驗，我們可以看到它們有很大的總體量差別：

這或許表明不同裝置級別間的預算值得考慮。例如，移動裝置 <170KB（min/gzip）的 JS 程式碼量和桌面裝置 <1.5MB 的 JS 程式碼量，可以讓使用者擁有更快的 CPU 和網路連線。

量化新功能的影響

“當一個包含三張輪播圖和一張全屏高解析度背景圖片的模組已經審批通過時，還要保證頁面大小不能超過 500kB 對你來說可能不太容易” —— Tim Kadlec

通常，非工程利益相關的人員不能意識到他們的決定對功能和設計所帶來的效能影響。這不是他們的錯。我們需要讓產品經理，設計師和利益相關者更容易理解他們做得選擇所帶來的使用者體驗影響。

利益相關者可能需要幫助，去理解換一種 JavaScript 輪播或者過多的圖片會嚴重影響網站的效能。效能預算可以戰略性地幫助我們改變思維模式，以此來考量我們新增每件事物的價值。

如果我們從一開始就把效能作為我們專案目標的一部分，那就更好了。這會是效能預算心態的轉變，從只把它當做開發中的一個考量因子，轉變成貫穿整個專案生命週期的關鍵因素。

為使用者體驗做出權衡

和任何財務預算一樣，你的效能預算有時候可能會很低。這就需要你做出一些削減或權衡以確保持續的快速使用者體驗。哪些功能對你的使用者來說是真正重要的？哪一個最能激發或留住他們？這是一個艱難的對話，並且不總是很清晰。

可以用拋棄一個功能而開放另一個功能來結束這個對話。“拋棄”可能意味著把它從關鍵路徑移除 —— 該功能仍可在稍後使用者需要它的時候按需載入。

在這種情況下，你可以在逐頁的基礎上，打電話諮詢頁面效能預算，並把它作為事實來源幫助你持續接近目標。

實施預算

業務通過實施績效文化的內部流程方式來實現效能預算。

組織化的效能預算要確保預算是關聯到每個人身上的，而不僅僅是通過團隊的方式來定義。效能預算不能只是工程團隊關心的事。

“網路效能預算應該是關於多個正確因素協作效果建立出的一個方程式，用以幫助企業做出正確的決定，並且能產出必要的建議幫助其產品向前發展。這會比開展一項帶有潛在衝突的關於旨在修復網站效能閾值的對話要有效得多。” —— Tobias Baldauf

設定好預算，並且讓整個組織儘早瞭解有哪些預算引數時，可以說效能不再只是一個工程問題，而會作為構建網站整個軟體包的關鍵部分。

當考慮效能時它（譯者注：預算）提供了設計和工程指南，並且會根據每個可能影響效能的決策做檢查。

SpeedCurve 等監控服務還能讓你針對競爭對手的網站做基準測試，使你可以輕鬆的視覺化（檢視）他們在你預算上的效能表現。當你告訴利益相關者為什麼 “控制預算” 很重要時，這些會是很有幫助。

幫助執行效能預算的工具

存在很多用於實施效能預算的工具。

bundlesize 在 CI 中用於捕獲 JavaScript 迴歸大小特別合適：

Tinder.com 使用包大小來設定每次 PR 提交時檢查的 JavaScript 包預算。他們的 React 應用有一個 170KB 的主包預算和一個 20KB 的 CSS 預算。程式碼分拆的方式使它們能夠保持在預算範圍內。諸如 Trivago, Zendesk 和 OpenTable 這樣的網站使用的也是這種方式。

其他團隊使用 Webpack 內建支援的效能預算。你可以配置 performance.hints 在超過預算時告警或構建失敗。Webpack 支援最大資源尺寸（maxAssetSize）或 JavaScript 包入口檔案尺寸（maxEntrypointSize）配置。

SpeedCurve 支援為各種指標，資源大小和 Lighthouse 審查類別做預算配置。

例子裡以 80/100 的預算追蹤了 blog.google 在 Lighthouse 上的效能分數。紅線表示超出了預算。

Zillow 使用 SpeedCurve 為移動搜尋中的數量（例如影象大小）和里程碑時間指標設定預算。其他效能監控服務（如 Calibre）也支援設定預算和退回時的警報。

如果您正處於決定把什麼作為目標預算的計劃階段，https://performancebudget.io 是一個預設了不同網路速度的預算視覺輔助。

當然，早些時候提到的，如果一個團隊想要以規則為基礎在 PR 上做效能預算，Lighthouse CI 會是很好的選擇。

結束思考

效能預算引入了一種問責文化，這使得利益相關者能夠權衡每次網站變更中以使用者為中心的指標。和你的團隊聊聊，看看是否可以在你的專案裡採用效能預算。如果值得加快（譯者注：網站體驗），那就值得保持快速。❤️

如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。

---

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。com/xitu/gold-miner#產品)、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。