很多团队选择 SSR，是因为它看起来能同时解决几件事：
- 首屏更快可见
- SEO 更稳
- 用户更早看到页面结构
这些方向没错，但 SSR 本身不是性能保险。
一旦进入真实项目，瓶颈很快会从“渲染模式选择”变成：
- 服务端响应时间
- 数据获取链路
- 缓存命中率
- hydration 成本
也就是说，SSR 只是把性能问题从前端单点，扩展成了一整条链路问题。
SSR 更像“把首屏工作前移”，不是把工作变少
这是理解 SSR 性能的关键。
SSR 并不是无中生有地省掉了渲染成本，而是把一部分工作从浏览器搬到服务端提前做。
这意味着：
- 用户更早看到内容
- 服务器承担了更多计算压力
- 客户端后续仍然要完成 hydration
如果只看首屏 HTML，而忽略服务端耗时和 hydration，团队很容易误判项目已经“性能好了”。
数据获取路径决定 TTFB 上限
很多 SSR 应用慢，不是因为模板渲染慢，而是因为首屏依赖的数据链太长：
- 一个页面串行请求多个后端服务
- 某些数据并不影响首屏，却被强行等待
- 错误处理和超时策略缺失
这些问题会直接拉高 TTFB，让 SSR 的优势被抵消。
缓存不是附属优化，而是 SSR 性能基础设施
SSR 应用如果完全每次实时计算，成本通常很高。
更稳的结构通常包含多层缓存：
- 页面级缓存
- 数据级缓存
- CDN / 边缘缓存
- 组件或片段级复用
SSR 的性能调优，很多时候其实是在做缓存体系设计，而不是单纯改渲染代码。
流式渲染和分段交付要围绕用户感知来用
很多团队会把 streaming 当成“越多越好”的高级优化，但真正该问的是：
- 哪部分内容必须第一时间出现
- 哪部分内容可以后到
- 用户对页面完整性的最低预期是什么
如果流式渲染没有围绕真实页面结构设计，用户看到的可能只是更早出现的骨架，而不是更好的体验。
失败案例：首屏 HTML 返回更快了，但交互反而更迟钝
这是一类非常典型的 SSR 误判：
- 团队优化了服务端首屏输出
- Lighthouse 某些指标看起来更漂亮
- 但用户依然觉得页面“能看不能用”
问题常常出在 hydration 和主线程压力：
- 页面返回了大量组件状态
- 客户端接手成本很高
- 首屏可见和首屏可用之间仍有明显时间差
所以 SSR 性能不该只看“看见了没有”，还要看“多久能真正交互”。
调优优先级应按链路拆分
一个更稳的 SSR 调优顺序通常是：
- 先看服务器响应与慢查询
- 再看数据链路是否串行过长
- 再看缓存命中率和失效策略
- 最后看 hydration 和前端主线程压力
这样做能避免把问题全堆给前端或全堆给后端。
一份可直接复用的检查清单
- 页面慢的主因是在服务端计算、数据获取还是客户端 hydration
- 首屏必须数据和非必须数据是否已经拆分
- SSR 页面是否建立了合理的缓存层次
- 流式渲染是否围绕用户感知而不是技术炫技
- 是否同时关注首屏可见时间和首屏可交互时间
总结
SSR 应用性能调优的核心，不是“用了 SSR 就会更快”，而是把服务端、数据、缓存和客户端接手成本放在一条链路里统一优化。只有这样，SSR 才能真正转化成用户感知到的性能优势。
进一步阅读：
