SSG（Static Site Generation）
最传统的“构建期一次性产出所有 HTML”。站点规模小时最简单；规模大或更新频繁时构建耗时、内容时效性不足，于是催生了 ISG、ISR 等增量方案。
CSR（Client-Side Rendering）
全部在浏览器渲染，HTML 只有一个空 div 和脚本标签。首屏依赖 JS 下载执行，SEO 与性能短板明显，但回包最小、部署最简单。现实项目常与 SSG/SSR 组合成“混合渲染”。
SSR
SSR（Server-Side Rendering）指的是一种在服务器端渲染 HTML 的方案
TTFB
TTFB 是 “Time To First Byte” 的缩写，中文常译为“首字节时间”或“首字节延迟”。
它指的是：浏览器（或其他客户端）向服务器发起 HTTP 请求后，直到收到响应的第一个字节所经历的时间。这个时间段包含：
- DNS 解析、TCP/TLS 建连等网络往返耗时。
- 服务端接收请求、排队、执行逻辑（读取文件、调用接口、渲染模板等）的处理耗时。
- 服务器把第一个响应字节写入网络并抵达客户端所需的传输耗时。
TTFB 反映了服务器和网络层面的“起步延迟”。它越长，浏览器开始解析 HTML 的时间点就越晚，进而推迟 FCP/LCP 等首屏指标，因此是前端性能优化中需要重点关注的指标之一。
Stream
SSR、TTFB 和 Streaming SSR 三者的关系可以理解成"渲染方式（SSR）→ 性能指标（TTFB）→ 优化手段（Streaming SSR）"的递进链路：
SSR（Server-Side Rendering）
- 在服务器把组件渲染成完整 HTML。
- 好处：浏览器拿到的立即是可解析的 DOM，首屏速度快、SEO 友好。
- 代价：服务器要先执行渲染逻辑，才能返回首字节，这段耗时会直接体现在 TTFB 上。
TTFB（Time To First Byte）
- 是衡量“请求发出 → 收到首字节”这段时间的性能指标。
- 之所以关注它，是因为：
- SSR 把渲染计算前移到服务器，计算时间越长，TTFB 就越大；
- TTFB 又决定了浏览器能多早开始解析 HTML，从而影响 FCP/LCP 等首屏指标。
- 因此，在 SSR 场景里，优化首屏体验的一大重点就是让 TTFB 尽量小。
Streaming SSR（流式 SSR）
- 是对传统「整串 HTML 生成完再返回」方式的改进：
- 服务器把 HTML 切成片段，一边渲染、一边把已有片段写入响应流；
- 浏览器接收到首个片段就可以开始解析，而不必等完整 HTML。
- 效果：
- 绝对意义上 TTFB（收到第 1 个字节）可能变化不大，但浏览器能更早开始解析首屏相关的 HTML 片段；
- 实际体验上，首屏可见时间和交互准备时间都被拉前。
- 如果再配合 ISG/缓存，就能把流式渲染的结果保存下来，后续请求既享受“静态文件般”快速 TTFB，又兼具按需实时更新的灵活性。
总结
- SSR 决定了 HTML 在服务器生成，直接影响 TTFB。
- TTFB 是衡量 SSR（以及网络）延迟的指标，越短越好。
- Streaming SSR 通过“边渲染边发送”来缓解 SSR 对首屏时间的影响，让用户更早看到内容，并可进一步与 ISG 缓存结合提升整体性能。
SSR 和 Hydration(水合) 的关系
二者是一个“前后接力”的关系：
- SSR（Server-Side Rendering）
- 在服务器把组件渲染成完整 HTML 字符串，直接返回给浏览器。这样浏览器在收到首屏时就能立刻解析并绘制页面，提高可见速度、利于 SEO。但这时的页面只是静态 DOM，按钮点不了、表单也没有事件监听。
- Hydration（水合）
- 紧接着在浏览器端执行。框架把同一套组件的 JavaScript bundle 下载下来，调用 hydrate()（React）、createSSRApp().mount()（Vue）之类 API：
- 先把服务端生成的 DOM 结构“复用”，避免重新 diff / 重新插入节点。
- 再给对应元素绑定事件监听、恢复状态，使页面从“纯 HTML”变成“可交互应用”。
- 这个过程就叫水合，形象地说是“往已经成型的 DOM 里灌注生命力”。
因此：
- SSR 解决的是“首屏 HTML 从哪儿来”——在服务端生成，缩短 TTFB/FCP。
- Hydration 解决的是“如何让 SSR 输出的静态 HTML 继续用同一套组件逻辑接管交互”。
没有 SSR，就不会有服务端产出的那份可复用 DOM，自然也谈不上水合；反过来，如果只做 SSR 而不水合，用户看到的页面就只能浏览、不能交互（除非另写原生 JS）。所以在现代同构框架里，SSR 和 hydration 通常成对出现：先 SSR，再 hydration，形成完整的同构渲染链路。
ISG
ISG（Incremental Static Generation／增量静态生成）指的是一种 “按需生成 + 本地/边缘缓存” 的静态页方案：
- 第一次请求
服务器发现磁盘/对象存储里没有该 HTML，或已过期 ⇒ 运行渲染逻辑生成最新 HTML ⇒ 把结果写入缓存（磁盘、KV、Redis、S3 等） ⇒ 把 HTML 返回给用户。
- 后续请求
直接命中缓存，像普通静态文件一样高速返回。
- 过期策略
通过 revalidate（秒数）或某种命中失效信号，决定何时重新生成。
因此 ISG 兼具“按需实时渲染”与“静态文件高并发性能”两大优点。
