前端性能配置要收口别等首屏变慢才发现性能退化很少来自某一行明显错误的代码。更常见的是一个日期组件、一段全量导入、一个重复 SDK在多次合并后慢慢堆进首屏。每次评审都觉得“只多一点”用户最终看到的却是更慢的加载和更长的可交互等待。因此性能不能只靠专项优化。项目需要把可观察的预算、构建产物对比和部署侧策略放进常规流程让每次变化在合并前就有机会被看到。预算先服务于真实页面主包大小、关键 CSS、图片体积、请求数量和核心交互指标都可以成为预算但预算值不是行业口号。不同页面面对的设备、网络和业务目标不同。后台系统与面向公众的落地页对首屏和交互的期待也不同。先选择少量能说明问题的指标。构建产物可以看压缩后的入口大小与总大小运行时可以看一个代表性页面的渲染、加载和布局稳定性网络层可以看首屏必须完成的请求。指标太多只会让团队忽略告警太少又会漏掉明显退化。每个预算应注明测量方式和环境。例如是压缩前还是压缩后大小测试运行在哪种浏览器和网络条件下页面数据量如何准备。没有这些上下文同一个数字在不同 CI 机器上会产生误导。构建检查要给出可操作的差异打包结束后检查器可以读取 manifest 和静态资源目录记录入口、异步 chunk、CSS 与图片的大小。发现超限时输出具体文件、当前值、基线和变化方向。开发者看到“主入口多了哪些模块”比看到“性能失败”更容易行动。不要把所有文件简单相加后得出结论。source map、服务端文件、预压缩文件和多入口产物的口径不同应该在配置中说明是否计入。必要时对关键入口单独设预算避免一个不相关的管理页面掩盖了用户首页的变化。与已验证基线做比较很有价值但基线更新必须经过明确流程。否则只要把新结果写成基线检查就失去意义。对于有意引入的大依赖可以在 PR 中解释理由、说明受影响路径并同步调整经过评审的预算。部署策略也属于性能配置构建变小不代表用户一定更快。静态资源的缓存策略、文件名是否带内容哈希、HTML 是否会及时更新、预加载是否只针对真正关键的资源都会影响实际体验。缓存配置不当时用户可能拿到新 HTML 和旧 chunk或在每次访问重新下载本可复用的资源。预加载与预取也不宜滥用。它们会抢占带宽若资源并非当前页面必须反而可能拖慢真正的关键请求。通过真实页面的网络记录确认资源优先级再决定是否配置而不是因为某项审计建议就全部开启。第三方脚本要有清单。它们往往体积不在自己的 bundle 中却会占用网络、主线程和隐私审查空间。引入前明确用途、加载时机和移除条件定期清理不再使用的 SDK。让告警进入日常决策性能预算触发不必总是直接拒绝合并但不能只留下一条没人看的日志。可以在 PR 中展示差异并要求超限时给出原因与后续处理对已验证且高风险的退化再采用阻断规则。重要的是规则稳定、结果可复现而不是告警声音有多大。性能配置的价值就在于让“以后再优化”变成有证据的当下选择。把产物、运行时指标和部署行为放在同一条反馈线上性能才不会在不知不觉中被下一次迭代吃掉。