CSR vs SSR vs SSG vs 流式渲染：性能上的权衡是什么？

Question

IT Interview Practice · Accepted Answer

渲染策略决定 HTML *在何处、何时*被构建，这会驱动各项加载指标。没有普适的最优——把它匹配到内容有多动态、多个性化。

## 各种策略

```text
CSR      Server sends near-empty HTML + JS ──▶ browser fetches data ──▶ renders   (slow first paint)
SSR      Server renders full HTML per request ──▶ browser shows it ──▶ hydrates   (fresh, TTFB cost)
SSG      HTML built ONCE at deploy ──▶ served from CDN ──▶ hydrates               (fastest, static)
Stream   Server flushes HTML in chunks as ready ──▶ shell first, data fills in    (fast TTFB + fresh)
```

- **CSR（客户端渲染）**——发送一个空壳 + JS；由浏览器获取数据并渲染。托管成本低，但 LCP 和 SEO 都差，因为内容要等 JS。
- **SSR（服务端渲染）**——为每个请求渲染完整 HTML。首次绘制快、对 SEO 友好且始终新鲜，但会增加 TTFB（每个请求都有服务端工作），并且仍需 hydration。
- **SSG（静态）**——在构建时渲染，从 CDN 提供。最佳的 TTFB/LCP，但内容的新鲜度只到你上一次构建为止；**ISR** 增加了周期性/按需的重建。
- **流式 SSR**——立即冲刷 HTML 外壳并流式传输较慢的部分（React Suspense / `renderToPipeableStream`），让用户在数据加载时就能看到内容。

## 如何选择

| 内容 | 最佳选择 |
|---------|----------|
| 营销、文档、博客 | SSG（+ ISR） |
| 个性化、按请求 | SSR / 流式 |
| 认证后的高度交互 app | CSR 或 SSR + islands |

## hydration 成本（共同的陷阱）

SSR/SSG 绘制得快，但页面在 JS **hydrate** 之前并不可交互——这是一段 INP 会受损的间隙。部分/渐进式 hydration 和 React Server Components 的存在，就是为了发送更少的客户端 JS 并缩小这段间隙。

## 为什么这很重要

资深工程师被期望能针对每个界面权衡这一取舍，而不是教条式地选定某一种。犀利的洞见是：快速绘制（SSR/SSG）并不意味着快速可交互——hydration 是隐藏的税，而流式渲染 + server components 是同时获得两者的现代答案。

内容	最佳选择
营销、文档、博客	SSG（+ ISR）
个性化、按请求	SSR / 流式
认证后的高度交互 app	CSR 或 SSR + islands

各种策略

如何选择

hydration 成本（共同的陷阱）

为什么这很重要

相关问题