跳到主要内容

SSG 与 SSR

面试速答（30 秒版 TL;DR）​

  • SSG（Static Site Generation，静态站点生成）：在构建阶段把页面 HTML 预先生成好，请求到来时直接返回静态文件。
  • SSR（Server-Side Rendering，服务端渲染）：在每次请求到来时，由服务端根据当前请求动态生成 HTML 再返回。
  • 它们最大的区别不是“哪个更先进”，而是 HTML 生成时机不同，这会进一步影响数据新鲜度、运行时成本、缓存策略和适用场景。
  • 一般来说：
    • 内容稳定、页面多、追求低成本分发：更偏 SSG
    • 首屏依赖实时数据、按用户或请求上下文变化：更偏 SSR
  • 一句话总结：SSG 把渲染成本前置到构建时，SSR 把渲染成本放到请求时。

一、先别背定义，先抓住本质差异​

SSG 和 SSR 解决的是同一类问题：

  • 让浏览器更早拿到可读 HTML
  • 改善首屏可见性
  • 降低纯 CSR 对客户端 JS 执行的依赖

但两者选择了不同的成本分配方式。

SSG 的思路​

发布前就把页面算好、写好、打包好。

特点是：

  • 访问时几乎不需要再做页面级渲染计算
  • 更容易走 CDN 缓存
  • 部署简单，吞吐高

SSR 的思路​

用户请求来了以后，再根据这一次请求去现算页面。

特点是：

  • 能拿到当前请求上下文
  • 能直接输出最新数据对应的 HTML
  • 服务端每次请求都要承担渲染成本

所以面试里最稳的一句话是：

SSG 和 SSR 的核心差异，是页面内容在“构建时就确定”，还是“请求时才确定”。

二、两条链路分别发生了什么​

1. SSG 链路​

拉取数据 -> 构建生成 HTML -> 发布到静态资源服务/CDN -> 用户请求 -> 直接返回 HTML

这条链路的关键点：

  • 数据大多在构建时拿
  • HTML 在发布前已经存在
  • 用户访问时主要是文件分发问题

它天然适合：

  • 文档站
  • 博客
  • 营销页
  • 更新频率低但访问量高的内容页

2. SSR 链路​

用户请求 -> 进入服务端应用 -> 拉取当前数据/读取上下文 -> 渲染 HTML -> 返回给浏览器

这条链路的关键点：

  • 渲染发生在运行时
  • 每次请求都可能得到不同 HTML
  • 性能瓶颈不只在前端，还包括服务端渲染、接口依赖、缓存设计

它天然适合：

  • 商品详情
  • 实时价格页
  • 强地域化或 AB 实验页
  • 首屏内容依赖用户身份或请求参数的页面

三、对比时不要只谈 SEO，要把工程代价讲全​

对比项SSGSSR
HTML 生成时机构建时请求时
数据新鲜度取决于重新构建/增量更新策略理论上更接近实时
首次请求成本低高于 SSG
吞吐能力通常更高受服务端渲染能力限制
缓存友好度非常好需要更细的页面或数据缓存设计
部署复杂度低较高
个性化支持弱强
SEO 友好度通常较好通常较好
典型风险构建慢、内容过期TTFB 高、服务端压力大

这里最容易被问的不是“谁更快”，而是“在哪个维度更快”。

更准确的说法应该是：

  • SSG 往往在访问时更快，因为 HTML 已经准备好了
  • SSR 在内容实时性上更强，但访问时要付出运行时渲染成本
  • 如果 SSR 做了完善缓存，它也可能很快
  • 如果 SSG 页面量巨大、构建链路很重，它的发布成本也可能很高

所以不要把问题说成简单的：

  • SSG 快，SSR 慢

要说成：

两者只是把成本放在不同阶段，SSG 偏构建时，SSR 偏请求时。

四、怎么判断一个页面该选 SSG 还是 SSR​

最实用的判断方式，不是看团队喜好，而是看这几个问题。

1. 页面首屏内容是否稳定​

如果页面首屏内容：

  • 大部分用户看到的都一样
  • 一天更新几次甚至更少
  • 可以接受“下一次构建后再更新”

那通常更偏 SSG。

典型例子：

  • 官网介绍页
  • 文档页
  • 帮助中心
  • 博客文章页

2. 页面是否强依赖实时数据​

如果页面首屏内容：

  • 依赖库存、价格、排名、状态
  • 需要拿到当前请求头、Cookie、地域信息
  • 不能接受“过一会儿再刷新”

那通常更偏 SSR。

典型例子：

  • 商品详情页
  • 酒店房态页
  • 活动库存页
  • 区域化落地页

3. 是否需要个性化首屏​

如果同一路由在不同用户身上要直接输出不同首屏：

  • 已登录用户和未登录用户不同
  • 不同地区文案不同
  • 不同实验桶内容不同

SSR 往往更自然。

因为 SSG 更擅长“一份结果服务很多请求”，而不是“每个请求都不同”。

4. 发布频率与页面数量是否匹配​

SSG 并不是页面越多越好用。

如果站点：

  • 页面数量极大
  • 一点小改动就要全量重建
  • 构建时间越来越长

那就要考虑：

  • 增量静态生成
  • 按需重建
  • 部分页面改为 SSR

注意：这些能力是否可用，取决于具体框架和部署方案。

五、为什么很多内容站优先用 SSG​

因为内容站通常有几个明显特点：

  • 内容以读为主，不强调强交互
  • 页面主体对所有用户几乎一致
  • 流量可能很大，但改动频率没那么高
  • 很适合走 CDN 缓存

这会带来几个直接收益：

  1. 首屏稳定
  2. 运维简单
  3. 成本更低
  4. 更容易抗突发流量

比如文档站场景：

  • 发布一次后，很多访问其实都只是读取同一份 HTML
  • 没必要每来一个请求都重新做模板渲染

所以像文档、博客、营销官网，通常天然适合 SSG。

六、为什么很多动态详情页会选 SSR​

因为动态详情页最怕的是：

  • HTML 和真实数据不一致
  • 首屏展示旧内容
  • 用户请求上下文丢失

举几个典型例子：

  • 商品价格实时变动
  • 酒店库存随时变化
  • 不同城市展示不同配送信息
  • 首屏要带登录态差异

这时如果用纯 SSG，就要额外补很多机制：

  • 频繁重建
  • 客户端首屏再拉一次数据覆盖静态内容
  • 边缘层做复杂缓存失效

结果可能会把方案变得更绕。

SSR 在这类场景里的价值，不只是 SEO，而是：

  • 首屏数据更实时
  • 请求上下文更完整
  • 页面输出和后端当前状态更一致

七、SSG 和 SSR 都不等于“不要客户端渲染”​

这是非常容易答错的一点。

无论是 SSG 还是 SSR，现代前端项目通常都还会有客户端接管过程，也就是常说的 hydration。

也就是说：

  • 服务端先给 HTML
  • 浏览器再加载 JS
  • 页面继续具备交互能力

所以不要把它理解成：

  • SSG/SSR 有 HTML，所以完全没有客户端渲染

更准确的理解是：

SSG/SSR 解决的是“首屏 HTML 怎么来”，而不是“后续交互还要不要 JS”。

八、真实项目里常见的折中方案​

很多项目不会只选一种渲染方式，而是按页面类型拆分。

常见组合：

  • 文档页、博客页用 SSG
  • 分类页、详情页用 SSR
  • 后台页、强交互工作台继续用 CSR

还有一些中间策略：

  • 静态生成 + 定时重建
  • 静态生成 + 按需刷新
  • SSR + 页面缓存
  • SSR + 数据缓存

面试里如果能补一句，会显得更工程化：

我不会把渲染方案当成全站统一答案，而是按页面是否承接搜索流量、是否依赖实时数据、是否需要个性化首屏来拆分。

九、典型题与标准答法​

Q1：SSG 和 SSR 的区别是什么？​

标准答法：

核心区别是 HTML 的生成时机不同。SSG 在构建阶段就把 HTML 生成好了，用户访问时直接返回静态内容；SSR 则是在请求到来时，由服务端根据当前请求动态生成 HTML。这个差异会进一步影响缓存方式、实时性、吞吐能力和运行成本。

Q2：两者哪个更适合 SEO？​

标准答法：

两者通常都比纯 CSR 更适合 SEO，因为它们都能更早返回带主体内容的 HTML。真正要区分的是页面类型。如果内容稳定，SSG 通常更简单、更稳；如果首屏强依赖实时数据或请求上下文，SSR 更自然。

Q3：为什么文档站常用 SSG？​

标准答法：

因为文档站页面内容通常比较稳定，对所有用户展示也基本一致，很适合在构建阶段一次性生成 HTML，然后通过静态资源服务和 CDN 分发。这样首屏稳定、吞吐高、运维成本也低。

Q4：SSR 的代价主要是什么？​

标准答法：

代价主要在运行时。每个请求都可能触发服务端渲染，所以会增加 TTFB 压力、服务端资源消耗、缓存设计复杂度，以及渲染异常带来的线上风险。

十、常见追问​

  • SSG 一定不能更新实时数据吗？
    • 不是。可以通过客户端补数据、定时重建、按需重建等方式解决，但方案复杂度会提高。
  • SSR 一定比 CSR 首屏快吗？
    • 不一定。如果服务端很慢、依赖接口很多，SSR 的 TTFB 也可能很差。
  • 只有 SEO 才需要 SSR/SSG 吗？
    • 不是。首屏可见性、白屏控制、低端设备体验也会推动你选择 SSR/SSG。
  • 页面个性化很强，还要做 SEO 怎么办？
    • 一般做法是把公共可索引主体用 SSR 输出，个性化部分放在客户端补齐或按权限再渲染。

十一、易错点 / 坑​

  • 把 SSG 和 SSR 说成两个框架名，而不是渲染策略。
  • 把问题简化成“谁更高级、谁更快”。
  • 只谈 SEO，不谈构建成本、运行成本和缓存设计。
  • 认为 SSG 页面一多就一定划算，忽略超长构建时间。
  • 认为 SSR 天然实时，忽略它依赖后端接口和缓存策略。
  • 把“有 HTML”错误理解为“完全不需要客户端 JS”。

十二、速记要点（可背诵）​

  • SSG：构建时生成 HTML。
  • SSR：请求时生成 HTML。
  • SSG 更偏低运行时成本和高缓存友好。
  • SSR 更偏实时数据和请求级定制。
  • 选型不要看口号，要看页面稳定性、实时性、个性化和成本。