[译] 开启性能预算

• 原文地址：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#产品)、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。