SSR与SSG渲染方案对比

可视化演示

展示四种前端渲染模式：CSR客户端渲染、SSR服务端渲染、SSG静态生成、ISR增量静态再生，动态对比TTFB和SEO表现差异。

CSR的困境——现点现炒，顾客等不起

以前开川菜馆，顾客坐下后才去后厨洗菜、切菜，再下锅爆炒，最后端上桌。顾客望着空盘子等了十几分钟，早就没了胃口。前端开发里的SPA（单页应用）正是如此：用户访问网站，浏览器先拿到一个几乎没有内容的HTML骨架，就像空盘子上桌，真正的“菜”——页面内容——要等浏览器下载并执行完一堆JavaScript之后才被“炒”出来。

这种模式叫客户端渲染（Client-Side Rendering，CSR）。页面内容靠浏览器里的JS动态生成，消耗的是用户设备的性能和网络带宽。网络慢一点、手机旧一点，首屏时间就会成倍拉长；更麻烦的是，很多搜索引擎爬虫读不懂白屏骨架里的内容，SEO排名自然吃亏。把CSR的首屏耗时拆成四段，问题就一目了然了：

$$\displaystyle \text{首屏时间}_{\text{CSR}} = t_{\text{HTML空壳}} + t_{\text{JS下载}} + t_{\text{JS执行}} + t_{\text{渲染}}$$

1. HTML空壳：服务器返回一个只包含根节点的空白HTML文档，浏览器开始解析时页面还是一片空白。

$$t_{\text{HTML空壳}}$$

2. JS下载：浏览器需要通过网络下载打包好的JavaScript文件，脚本体积越大下载越慢。

$$t_{\text{JS下载}}$$

3. JS执行：下载完成后，浏览器要解析、编译并执行JS，这是一个CPU密集型过程，老设备尤其吃力。

$$t_{\text{JS执行}}$$

4. 渲染：JS调用框架的渲染引擎，把虚拟节点转换成真实DOM，页面内容才真正可见。

$$t_{\text{渲染}}$$

回到餐馆的比喻——让顾客干等不仅败好感，还会直接流失客人。CSR的“现点现炒”模式，在用户体验和SEO上都付出了高昂代价，这才催生了SSR和SSG两种新的“出餐方案”。

SSR服务端渲染——后厨实时出菜

既然“现点现炒”让顾客等太久，那试试另一种餐馆的做法：顾客点完菜，后厨立刻开火，用提前备好的食材快速翻炒，几分钟后端上桌的是一盘完整的菜。浏览器请求一个页面时，服务器不再返回空壳，而是在服务器里把组件渲染成完整HTML，再一次性返回给浏览器。这种模式叫服务端渲染（Server-Side Rendering，SSR）。

SSR的关键在于“渲染发生在服务器”。用户请求到达服务器时，服务器执行前端框架的渲染逻辑——读取数据、运行组件、生成HTML字符串——然后把内容完整地送回浏览器。用户看到的不再是白屏，而是已经包含文字和图片的真实页面，首屏体验瞬间提升。这一特性也让爬虫抓取到的HTML直接带正文，SEO效果接近纯静态页面。

SSR的首屏时间主要由三部分构成：

$$\displaystyle \text{首屏时间}_{\text{SSR}} = t_{\text{请求往返}} + t_{\text{服务端渲染}} + t_{\text{HTML传输}}$$

1. 请求往返：浏览器把页面URL发给服务器，网络请求在浏览器和服务器之间走一趟，耗时取决于网络质量。

$$t_{\text{请求往返}}$$

2. 服务端渲染：服务器执行组件的渲染逻辑，将数据和模板组合成完整的HTML字符串，这是SSR的核心开销。

$$t_{\text{服务端渲染}}$$

3. HTML传输：渲染完成的HTML通过网络返回浏览器，浏览器直接解析并显示，不再依赖JavaScript执行。

$$t_{\text{HTML传输}}$$

SSR像“后厨实时出菜”，好处是菜品新鲜、内容实时，坏处是每来一桌客人都要占一个灶台——服务器得实时渲染每个请求，流量一大CPU就吃紧。所以SSR适合登录态强、数据频繁变化的应用，但要注意扩容、缓存和渲染性能优化。

SSG静态生成——预制菜直接上桌

还有一家更极致的餐馆：开店之前就把所有招牌菜做成预制菜，按份封装冷藏。顾客进门，按单取菜，十秒钟就端上桌。静态生成（Static Site Generation，SSG）就是这个思路——在构建阶段就把所有页面渲染成静态HTML文件，然后发布到CDN或静态服务器上，用户访问时直接返回现成文件。

SSG的核心特征是“渲染前置”：把本来在用户请求时的工作，提前到项目构建时完成。部署后，用户的请求不再触发任何服务器计算，CDN边缘节点直接把预先构建好的HTML文件返回浏览器。因为跳过了服务端渲染和JS下载执行等耗时步骤，SSG的首屏速度通常是三种方案里最快的，而且部署成本极低。

SSG首屏的时间模型非常简洁：

$$\displaystyle \text{首屏时间}_{\text{SSG}} = t_{\text{CDN查找}} + t_{\text{HTML传输}}$$

1. CDN查找：用户请求从最近的CDN边缘节点查找对应的静态文件，缓存命中时耗时仅几毫秒。

$$t_{\text{CDN查找}}$$

2. HTML传输：静态文件直接从CDN传输给浏览器，途中没有服务器计算和渲染开销，速度取决于网络带宽。

$$t_{\text{HTML传输}}$$

预制菜的代价也很明显：如果菜品要换配方，不能只改一块，得把整批预制菜重新生产——SSG页面内容一变，就需要重新构建、重新部署所有页面。因此SSG适合官网、博客、文档这类内容更新频率低的站点，静态文件越多，出餐效率越高。

性能与SEO对比——三条出品线的账本

现在把三家餐馆的账本摆在一起看。CSR像顾客等厨师现场炒菜，首屏慢、SEO弱，但胜在部署简单、服务器零压力；SSR像顾客点单后厨现做，首屏快、SEO好，但每次请求都要占服务器资源；SSG像预制菜直接上桌，首屏最快、SEO友好，而且几乎没有服务器计算压力。

从SEO的角度看，搜索引擎爬虫抓取页面时，看到的是服务器返回的HTML内容。CSR返回空壳HTML，正文全靠JS后续生成，爬虫往往拿不到内容；SSR和SSG返回的都是含完整正文的HTML，爬虫可以直接提取文字、图片和链接，收录效果自然更好。

$$\displaystyle \text{SEO友好度}: \quad \text{SSG} \approx \text{SSR} > \text{CSR}$$

1. SSG（≈最高）：静态HTML把正文直接内置，对爬虫最友好，收录效果最稳定。

$$\text{SSG} \approx 100\%$$

2. SSR（≈最高）：请求返回的HTML同样包含完整正文，爬虫抓取效果与SSG接近。

$$\text{SSR} \approx 100\%$$

3. CSR（较低）：爬虫只能抓到空白骨架，正文不可见，SEO效果明显不如前两者。

$$\text{CSR} < 50\%$$

在性能方面，SSG首屏最快，SSR次之，CSR最慢；在部署运维方面，CSR最简单（纯静态托管），SSG稍复杂（需要构建步骤），SSR最重（需要常驻Node服务器）。选型本质上是“新鲜度、速度、成本”三者的权衡。

主流框架实践——Next.js与Nuxt.js的“菜单”

餐馆开到连锁店阶段，想在同一家店里既卖预制菜又做现炒菜，就需要一套标准化的“菜单系统”。在前端领域，这套系统就是Next.js和Nuxt.js。它们是主流的全栈框架，允许开发者在同一个项目里，按页面灵活切换SSR与SSG，不必为每个页面单独搭一套技术栈。

在Next.js（React生态）中，SSR和SSG的切换主要由数据获取函数决定。页面组件里导出一个特殊函数，框架就会在对应阶段执行它：如果导出的是getServerSideProps，该页面会在每次请求时执行服务端渲染；如果导出的是getStaticProps，该页面会在构建时预生成静态HTML。两者就像菜单上标注的“现炒”和“预制”两种做法，同一道菜可以按需选择。

$$\displaystyle \text{Next.js 页面策略} = \begin{cases} \text{SSR: } \text{getServerSideProps}(\text{请求}) \\ \text{SSG: } \text{getStaticProps}(\text{数据}) \end{cases}$$

1. SSR分支：getServerSideProps接收每个请求的上下文对象，每次访问都会在服务器上执行渲染逻辑，适合数据频繁变化的页面。

$$\text{getServerSideProps}(\text{req}) \rightarrow \text{HTML}_{\text{实时}}$$

2. SSG分支：getStaticProps在构建时读取数据并注入页面，生成静态HTML文件，适合内容相对固定的页面。

$$\text{getStaticProps}(\text{data}) \rightarrow \text{HTML}_{\text{静态}}$$

Nuxt.js（Vue生态）提供类似能力：nuxt generate 命令生成静态站点，对应SSG；默认的服务端渲染模式则通过Node服务器实时渲染页面，对应SSR。两大框架的选型逻辑完全一致：看页面内容的更新频度，更新频繁的用SSR，长期稳定的用SSG。

ISR混合渲染——定时保鲜的预制菜

预制菜虽快，但放久了不新鲜。如果一家食堂既想保留预制菜的极速出餐，又想保证招牌菜每隔几小时换一批新的，怎么办？聪明的做法是“定时重做”——每隔一段时间重新生产一批预制菜替换旧的。这正对应增量静态再生（Incremental Static Regeneration，ISR）。

ISR在SSG的静态页面上加了“保质期”（TTL，Time To Live）。页面第一次以静态HTML提供服务，TTL计时开始；当TTL到期后，用户请求会触发服务器在后台重新渲染该页面，并把新HTML替换成新的静态版本。访问者可能先看到旧版本，但下一次刷新就能看到新内容，整个过程用户无感知。

$$\displaystyle \text{ISR}: \quad \text{HTML}_{t_0} \xrightarrow{\text{TTL失效}} \text{后台重建} \xrightarrow{} \text{HTML}_{t_1}$$

1. 旧版HTML：t0时刻生成的静态版本，在TTL有效期内对用户正常响应，保持静态页秒开体验。

$$\text{HTML}_{t_0}$$

2. TTL失效：时间超过设定的有效期后，页面进入“需要刷新”状态，但旧版本仍可服务用户。

$$\text{TTL} \to 0$$

3. 后台重建：服务器异步重新获取数据并渲染页面，生成t1时刻的新版本，替换旧版本后TTL重新计时。

$$\text{HTML}_{t_1}$$

ISR非常适合“内容定期变化但不需要秒级实时”的场景，例如新闻列表、商品促销价、活动聚合页——既享受静态页面秒开的极速体验，又不必每次改动都手动重新构建全站。这就像定期更换预制菜，顾客吃到的始终是新做的，但等待时间几乎为零。

AI 应用场景

Python 演示

import random  def csr_first_paint(js_size=300):    """模拟客户端渲染首屏耗时：空壳HTML + 下载JS + 执行JS + 渲染"""    html_empty = 20    js_download = 60 + js_size * 0.1    js_parse = 80 + js_size * 0.05    render = 40 + random.random() * 20    return html_empty + js_download + js_parse + render  def ssr_first_paint(server_time=120):    """模拟服务端渲染首屏耗时：网络请求 + 服务器渲染 + 返回HTML"""    network = 25    server_render = server_time + random.random() * 20    html_transfer = 10 + random.random() * 5    return network + server_render + html_transfer  def ssg_first_paint(cdn_latency=8):    """模拟静态生成首屏耗时：CDN查找 + 返回HTML"""    cdn_search = 3 + random.random() * 3    html_transfer = cdn_latency + random.random() * 5    return cdn_search + html_transfer  if __name__ == "__main__":    samples = 5    csr_times = [csr_first_paint() for _ in range(samples)]    ssr_times = [ssr_first_paint() for _ in range(samples)]    ssg_times = [ssg_first_paint() for _ in range(samples)]     print("渲染方案首屏耗时模拟（单位：毫秒，取5次平均）")    print(f"CSR: {sum(csr_times) / samples:7.1f} ms")    print(f"SSR: {sum(ssr_times) / samples:7.1f} ms")    print(f"SSG: {sum(ssg_times) / samples:7.1f} ms")

1. def csr_first_paint(js_size=300)定义CSR耗时函数，包含HTML空壳、JS下载、JS执行和渲染四段耗时，跟正文公式一一对应。
2. js_download = 60 + js_size * 0.1模拟JS体积越大、下载耗时越长的线性关系。
3. def ssr_first_paint(server_time=120)定义SSR耗时函数，包含请求往返、服务端渲染和HTML传输三段。
4. server_render = server_time + random.random() * 20模拟服务器渲染时间的不稳定性，这也是SSR在高负载下性能波动的根源。
5. def ssg_first_paint(cdn_latency=8)定义SSG耗时函数，只需CDN查找和文件传输，开销最小。
6. csr_times = [csr_first_paint() for _ in range(samples)]每种方案各采样5次，减少随机波动的影响。
7. print(f"CSR: {sum(csr_times) / samples:7.1f} ms")输出格式化结果，让三种方案的耗时对比一目了然。

常见误区

面试题