性能预算应该写进需求文档

大部分 H5 项目的性能问题不是优化不够，而是从一开始就没人为性能负责。把首屏体积和帧率写成验收条款，比事后优化便宜十倍。

我们复盘过去三年做砸过的项目，发现性能问题有一个共同点：所有人都同意性能重要，但没有任何一份文档写明性能的具体数字，也没有任何一个人的工作被性能指标考核。

于是性能变成了一件默认由前端在开发后期独自承担的事。而到那个时候，能改的只剩压缩图片和懒加载，动效方案、素材规格、接口设计这些真正决定性能上限的决策早就定死了。

把数字写进需求

我们现在的做法是在需求评审阶段就确定三条红线：

这三个数字和功能需求写在同一份文档里，由同一批人签字确认。任何创意方案在评审时都要回答一个问题：它会消耗多少预算。

有了预算之后，讨论从"这个效果能不能做"变成"这个效果值不值 200KB"。这是一个完全不同的对话，而且是产品和设计能参与的对话。

在一个零售客户的项目里，我们否掉了三个视觉方案，不是因为做不了，而是因为算下来会超预算。客户当时觉得可惜，活动结束后反馈说这是对的决定。

预算写下来还不够，需要在 CI 里卡住。我们在构建流程中加了体积检查，超过阈值直接失败。这听起来严苛，但它让预算从一句口号变成了一条真实约束。

约束不是限制创意，是让创意落在能实现的范围内。