绩效预算

性能预算是指预先设定并作为开发流程一部分执行的，对决定页面加载和响应速度的各项特性设定的明确限制。预算通常以阈值的形式表示，例如基于最大内容绘制 (LCP) 等指标、基于 JavaScript 总大小等数量，或者基于规则（例如允许的第三方请求数量）。

它解决的问题是性能退化而非优化。网站变慢并非源于单一决策，而是许多看似合理的改动累积而成，每次改动都微不足道，不易引起关注。一项新功能、一个额外的跟踪脚本、一张更大的首页图片、一种新的字体粗细、以及一个组件库的升级，每一项都只会增加零点几秒的延迟，但两年后，网站速度却会显著下降，却找不到原因。预算限制使得每次改动都面临一定的限制。

预算之所以有效，是因为它能将对速度的抽象偏好转化为决策时必须考虑的约束条件。如果没有预算，关于某个脚本是否物有所值的争论就会在事后发生（甚至根本不会发生），而提出增加脚本的人也没有理由去考虑它。有了预算，增加脚本就意味着要么在预算范围内，要么明确地移除其他脚本，而这本来就是应该存在的权衡取舍。

设定预算目标需要依据事实而非空想。有用的参考指标包括：当前表现，确保预算能够避免业绩下滑；竞争对手的业绩，确保目标能够反映网站所处市场的实际情况；以及与搜索和用户体验相关的关键指标的阈值。将预算设定在网站目前无法达到的水平固然可以作为目标，但必须将其与新项目实施的限制区分开来，否则每次构建都会失败，并且该限制将被禁用。

自动化工具中的强制执行机制是区分预算和文档的关键所在。将检查集成到构建流程中，使得超出限制的变更要么失败，要么需要明确批准，这种机制正是实现这种行为的根本所在。规范中记录的预算，即使由相关工程师定期检查，也经常会被超支，因为等到有人注意到时，工作已经交付，而撤销的成本超过了接受它的成本。

粒度应与网站的构建方式相匹配。不同的模板具有不同的特性，单一的全站预算要么会不必要地限制简单的页面，要么会允许交互式页面不受控制地扩展。为每个模板设置预算，并对高价值路径（例如着陆页和结账页）设置最严格的限制，可以将限制集中在最关键的地方。

例外情况需要明确的流程，而不是被禁止或随意处理。在某些情况下，某个功能确实需要额外的资源投入，而预算中没有例外条款要么会导致功能被规避，要么会阻碍重要的工作开展。要求例外情况必须由负责人提出申请、获得批准，并记录有效期，既能确保机制的公信力，又能允许真正需要的例外情况得到处理。

由于预算限制了工程、设计和营销等各个部门的决策，因此需要绩效考核团队以外的各方达成一致。实际上，预算限制是通过以下方式设定的： 网络性能 工作和执法已融入到流程中 产品开发而这种限制的商业理由通常是通过将性能与转化率联系起来，利用通过以下方式维护的分析来证明的： 数据分析.