[譯] 開啓性能預算

• 原文地址：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#產品)、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。