在很多项目里，性能问题总是在上线前才被提起。此时架构已经定型，能做的往往只是压缩图片、合并请求。真正有效的做法，是在项目开始时就为性能设定预算，并把它写进验收标准。

先定义“快”的标准

“打开要快”不是标准。我们会和团队一起明确几个可度量的指标：首屏内容出现时间、最大内容绘制时间、交互响应延迟，以及关键页面在弱网环境下的可用性。

  • 首屏关键内容不依赖第三方脚本；
  • 首屏图片明确尺寸与优先级，避免布局抖动；
  • 非关键模块延迟加载，把主线程留给交互。

SSR 不是银弹

服务端渲染能改善首屏内容出现时间，但如果数据请求串联过多，服务端等待时间同样会拖慢响应。我们在项目中会优先并行化独立请求，并为外部接口设置超时与降级策略。

性能预算的意义，不是让每个页面都做到极致，而是让团队在做出取舍时有一把共同的尺子。

持续度量，而不是一次性优化

性能会随着功能增加而自然退化。把关键指标接入日常监控，在每次迭代后对比基线，才能让“快”成为一种被持续维护的状态，而不是某次专项优化的结果。