【SSR】SSR 性能问题

1. 首屏渲染慢

• 原因：

  • SSR 会在服务端执行完整的 React 渲染逻辑，CPU 开销大。
  • 需要等待数据请求完成再拼接 HTML，导致 TTFB（首字节时间）变长。
  • 代码体积过大（bundle 太肥）。

• 优化方向：

  • 使用 流式渲染 (React 18 Streaming SSR)，边算边输出，缩短白屏时间。
  • 数据提前请求（例如 React Server Components / getServerSideProps 提前拿数据）。
  • 做 代码分割、减小 bundle。
  • 使用缓存（CDN 缓存 HTML / API 缓存数据）。

---

2. 服务端压力大

• 原因：

  • SSR 每次请求都要跑一遍 React 渲染逻辑，CPU 消耗比 CSR 高。
  • 突发流量可能导致 Node.js 阻塞或过载。

• 优化方向：

  • 引入 页面级缓存（热门页面直接缓存 HTML）。
  • 使用 微缓存（例如 1 秒缓存，抗击瞬时高并发）。
  • 把数据层结果缓存到 Redis 或内存，避免每次都打 DB。
  • 增加服务端渲染集群，配合负载均衡。

---

3. Hydration 慢

• 原因：

  • 客户端拿到 SSR HTML 后，还要执行 Hydration（给已有 DOM 绑定事件、恢复状态）。
  • 如果 JS 体积大、依赖多，Hydration 时间会很长。

• 优化方向：

  • 部分 Hydration（只对交互区域做水合，例如 Qwik、Astro 的做法）。
  • 延迟 Hydration（比如 lazy + 交互时再挂事件）。
  • 组件级 代码分割，减少首屏 JS。

---

4. 大量阻塞资源

• 原因：

  • SSR 输出的 HTML 可能包含很多 <script>、<link>，阻塞浏览器渲染。
  • 数据请求慢 → 阻塞 HTML 拼接。

• 优化方向：

  • 使用 Preload / Prefetch 提前加载关键资源。
  • 后端渲染时就内联关键 CSS（Critical CSS）。
  • 异步加载非关键 JS。

---

5. SEO / 爬虫相关开销

• 原因：

  • 对于大量动态页面，SSR 每次都要算一遍，性能压力大。

• 优化方向：

  • 对 SEO 需求高但数据不常变的页面，直接用 静态生成（SSG）。
  • 混合方案：热门页面走缓存 + SSG，动态数据部分用客户端请求补充。

---

6. 常见线上排查点

• Node.js CPU 飙升（渲染逻辑太重）。
• TTFB 大于 500ms（数据获取或渲染卡）。
• Hydration 超过 1s（bundle 太大）。
• 大量 FCP/TTI 延迟（阻塞资源没优化）。

---

👉 总结一句话：
SSR 的性能问题主要集中在 “服务端渲染耗时 + 客户端 Hydration 耗时” 两个阶段，解决思路就是 → 缓存 / 分片 / 流式 / 减 JS。