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