做 Web 性能优化时，`SSR`（Server-side rendering，服务端渲染）和静态渲染（常见是 `SSG` / Prerendering）经常被放在一起对比。很多团队会下意识觉得：只要把页面丢到服务端生成 `HTML`，用户就能更快看到内容，搜索引擎也更开心。现实更微妙：`SSR` 的“动态性”会带来明显的算力成本，而且如果实现方式不够讲究，还可能把 `TTFB` 拉长，甚至让客户端 `Hydration` 变成新的性能瓶颈，最后 `TBT`、`INP` 反而更难看。([web.dev][1])

下面从浏览器渲染链路出发，把 `SSR` 与静态渲染的差异、代价、优化抓手讲清楚，并配一些“真实世界”场景，帮你在工程里做决策。

---

## 从浏览器视角看：用户等待的时间，究竟花在哪

当用户访问一个 URL，浏览器大致会经历几件事：

* **网络阶段**：发起请求，等待服务器返回响应的第一个字节，也就是 `TTFB`（Time to First Byte）。如果服务器能更早“冲刷”响应（例如先把 `HTTP` 头或 `<head>` 发出去），`TTFB` 往往会更好看。([web.dev][2])
* **解析与渲染阶段**：浏览器解析 `HTML`，构建 `DOM`，再结合 `CSS` 形成渲染结果。
* **交互阶段**：用户能不能“点得动”，取决于主线程是否被长任务占住。实验室里常用 `TBT`（Total Blocking Time）衡量主线程在页面加载期间被阻塞的总时长。([web.dev][3])
* **真实交互体验**：线上更关注 `INP`（Interaction to Next Paint），它观察用户访问生命周期内的点击、键盘、触摸等交互延迟，最终取最差（并忽略部分离群值）作为页面响应性指标。([web.dev][4])

把这条链路记在脑子里，你会发现：`SSR` 让“看到内容”变早，并不自动意味着“交互就更快”。如果 `Hydration`（把服务端生成的静态 `HTML` 变成可交互应用的过程）很重，用户看到内容后依然可能“点了没反应”。`Hydration` 的设计本身就是一种折中：服务端先给可见内容，客户端再接管并补齐交互能力。([web.dev][1])

---

## 静态渲染在做什么：把昂贵的工作前置

静态渲染的核心思路很朴素：**把页面 `HTML` 提前生成**，要么在构建期生成，要么在后台按需再生成并缓存起来；用户请求来了就直接发缓存结果。

以 `Next.js` 为例，官方把它描述为：静态渲染的路由在构建时或后台再验证后生成，生成结果会进入缓存并在后续请求复用。([Next.js][5])

静态渲染的优势通常体现在：

* **`TTFB` 天然更短**：因为服务器不需要每次请求都“跑一遍渲染”。
* **更容易吃满 `CDN` 缓存**：边缘节点就能回源更少。
* **成本更可控**：算力高峰时不会因为每个请求都做渲染而爆炸。

代价也很明确：**数据可能变陈旧**。当然，现代框架提供了再验证、增量生成等机制，试图在“快”和“新鲜”之间找平衡。([Vercel][6])

---

## `SSR` 在做什么：每个请求都“现场出菜”

`SSR` 的定义同样直接：**每个 URL 请求到来时，服务端动态生成 `HTML`**，再把它发回浏览器。([web.dev][1])

它的优势集中在一个词：**“活”**。

* 你可以在渲染时读取更实时的数据源。
* 你可以应对更复杂、更细分的请求形态。
* 你可以做个性化：例如按用户、按地区、按登录态输出不同内容。这类需求用纯静态渲染往往很别扭。([web.dev][1])

但这份“活”，会把成本和复杂度带进来。

---

## 为什么 `SSR` 不是万能解：算力、`TTFB`、重复工作，三座大山

### 1) 动态渲染的算力开销是真金白银

`SSR` 每次请求都要跑渲染逻辑，遇到流量峰值，渲染开销会线性放大。相较之下，静态渲染更像“批量生产 + 缓存分发”，天然更省。([web.dev][1])

### 2) 不会“早冲刷”的 `SSR` 反而会拖慢 `TTFB`

很多 `SSR` 方案会等整棵组件树渲染完才把响应发出去，于是用户拿到第一个字节的时间被拖长。浏览器关于 `TTFB` 的讨论里也明确提到：部分服务器允许提前冲刷响应（例如只冲刷头部或 `<head>`），这和 `Early Hints` 一样，都能让浏览器更早开始工作。([web.dev][2])

### 3) `Hydration` 往往意味着“同一个应用做两遍”

很多基于 `React` 的典型 `SSR` 路径是：

* 服务端渲染：输出 `HTML`
* 客户端再渲染一次：把事件监听、状态等挂回去（`hydrateRoot`）

`React` 文档对 `hydrateRoot` 的描述很直白：它用于把之前由 `react-dom/server` 生成过 `HTML` 的 `DOM` 节点“显示”成可交互的 `React` 应用。([React][7])

这就带来一个现实问题：**更快看到内容，不等于更少的客户端工作量**。如果客户端还要下载大包、执行大量 `JS`、做重 `Hydration`，主线程会被长任务压住，实验室的 `TBT` 会升高，线上 `INP` 也更容易变差。([web.dev][3])

---

## `React` 里的关键差异：`renderToString()` 与流式 `SSR`

在 `React` 生态里，很多人对 `SSR` 的第一印象来自 `renderToString()`：服务端把组件树同步渲染成一个完整字符串，再 `send` 给浏览器。([React][8])

它的问题在于：**同步、串行**。当组件树很大、数据依赖多、模板复杂时，服务端需要等全部渲染完成才开始返回。

`React` 新的服务端 `DOM` 接口提供了“流式渲染”能力。例如 `renderToPipeableStream` 可以把 `React` 树渲染到 `Node.js` 的流里，从而让“壳子”更早到达浏览器，后续内容边生成边发送。([React][9])

你可以把它理解成餐厅出菜逻辑：

* `renderToString()`：等所有菜都做好再一次性上桌。
* 流式 `SSR`：先把开胃菜和餐具端上来，主菜边做边上。

这类能力的价值，核心就是**缩短用户“开始看到东西”的时间窗口**，同时尽可能减少因为等待整棵树完成而拉高的 `TTFB`。([React][9])

---

## 静态渲染真的“过时”了吗：看三个真实世界场景就懂

### 场景 A：营销落地页与文档站

特点是内容更新频率低、访问量可能很高、首屏稳定，几乎不需要按用户差异化输出。

这类页面用静态渲染，配合 `CDN` 全缓存，往往能拿到非常漂亮的 `TTFB`，服务器成本也最低。再加上内容可直接以 `HTML` 形式被解析，搜索引擎抓取也更顺畅。

工程上常见做法是：正文静态化，少量动态区域（比如“最新公告”或“在线客服”）用客户端请求补齐即可。`Next.js` 也明确提到：你可以用静态生成，再通过客户端数据获取填充部分区域。([Next.js][10])

### 场景 B：电商商品详情页与价格库存

电商看起来“很动态”，但并不意味着必须全量 `SSR`。

一个很常见的折中是：

* 商品基础信息（标题、图、详情、参数）静态生成并缓存
* 库存、价格、优惠券等高频变化部分走客户端或边缘接口获取
* 定期再验证或增量生成，保证主要内容不至于过旧

这样做的收益是：大多数用户请求命中缓存，`TTFB` 和服务器成本都更好；动态部分也能保持足够新鲜。

如果你把所有内容都塞进 `SSR`，峰值流量时服务端渲染会变成巨大成本，而且你仍然要面对客户端 `Hydration` 的开销，未必比静态方案更“快点得动”。([web.dev][1])

### 场景 C：强个性化的首页或工作台

这类页面的关键不是“内容能不能提前生成”，而是“不同用户看到的东西差异很大”，例如：

* 登录后展示用户专属模块、待办、权限相关入口
* 不同地区、不同套餐看到不同价格与权益
* 需要按 `Cookie`、按用户画像输出

这里 `SSR` 的价值就非常明确：服务端可以在渲染期拿到更完整的请求信息，并输出更贴合用户的 `HTML`。同时，你可以用 `HTML caching` 做“分层缓存”：按用户段（segment）缓存，而不是按每个具体用户缓存，把成本压下去。([web.dev][1])

---

## 把 `SSR` 做对：关键不是“用不用”，而是“怎么省一次渲染”

从工程经验看，`SSR` 的坑大多不在“能不能渲染”，而在“能不能在高并发下稳定且便宜地渲染”。

下面这些抓手很实用。

### 1) 让响应更早开始：流式渲染 + 早冲刷

如果你用 `React` 做 `SSR`，优先考虑流式方案，让壳子更快到达浏览器。`renderToPipeableStream` 的定位就是为 `Node.js` 流式输出服务端 `HTML`。([React][9])

示例（用单引号，避免 `"`）：

```js
import express from 'express'
import React from 'react'
import { renderToPipeableStream } from 'react-dom/server'
import App from './App.js'

const app = express()

app.get('*', (req, res) => {
  res.setHeader('Content-Type', 'text/html; charset=utf-8')

  const { pipe, abort } = renderToPipeableStream(<App url={req.url} />, {
    onShellReady() {
      res.statusCode = 200
      pipe(res)
    },
    onError(err) {
      console.error(err)
    }
  })

  // 防止极端情况下渲染挂死占资源
  setTimeout(() => abort(), 10000)
})

app.listen(3000)
```

这段代码的核心价值是：`onShellReady` 时就开始 `pipe`，让浏览器尽早拿到可解析的 `HTML`，把“等待服务端做完全部工作”改成“边做边发”。([React][9])

### 2) 做 `HTML caching`，把“动态渲染”变成“动态生成 + 多次复用”

`SSR` 最大的问题是每次请求都渲染。解决它的关键就是缓存。

你可以做的缓存层次包括：

* **全页 `HTML` 缓存**：最直接，命中就不渲染。
* **组件级缓存**：例如导航栏、页脚、推荐模块，很多时候在短时间内并不变。
* **数据缓存**：对同一份数据的重复拉取是另一个隐藏成本。

这也是为什么很多框架会把“渲染策略”与“缓存策略”绑在一起讲。`Next.js` 文档就把渲染策略视为缓存可用性的基础：静态渲染结果可复用，动态渲染则更依赖你如何设计缓存。([Next.js][5])

### 3) 控制 `Hydration` 的重量：别让主线程被自己打爆

`TBT` 的定义强调了主线程在 `FCP` 后被长任务阻塞的总时长；任务超过 `50 ms` 的部分会计入阻塞。([web.dev][3])
`INP` 则直接度量交互延迟，最终取最慢交互作为结果。([web.dev][4])

这意味着：就算 `SSR` 让内容更早出现，只要 `Hydration` 把主线程占满，用户一样会觉得卡。

实操里常用的减负方法包括：

* **减少首屏 `JS` 体积**：拆包、懒加载，把非关键交互推迟。
* **降低一次性 `Hydration` 范围**：让关键区域先可交互，非关键区域晚一点再接管。
* **减少重复状态注入**：很多 `SSR` 会把初始状态内联进页面，客户端又再拉一遍或再计算一遍，导致“数据发了两次”。这类设计要尽量避免。([web.dev][1])

你可以把目标理解为：把 `SSR` 的收益（更早可见）真正转化成“更早可用”，而不是停留在“更早看到一个不能点的页面”。

---

## 一张决策清单：用更少争论换更快落地

下面这套判断在团队里很管用，你可以直接拿去当评审模板。

### 更偏向静态渲染的信号

* 页面内容对所有用户基本一致
* 内容更新频率不高，允许分钟级甚至小时级再验证
* 流量大、成本敏感，希望尽量命中 `CDN`
* 交互不重，或交互可以局部客户端化

对应例子：品牌官网、活动页、文档站、帮助中心、招聘页、博客正文。

### 更偏向 `SSR` 的信号

* 强个性化：登录态、权限、用户画像驱动的差异明显
* 数据必须请求时最新，且无法接受再验证延迟
* 需要在服务端做复杂聚合，客户端拿不到足够上下文

对应例子：工作台、订单中心、B2B 报价页、带权限的管理后台首页。

### 混合方案往往是性价比最高的现实解

大多数大型站点最后都会走向混合：

* 页面骨架静态化（快、便宜、可缓存）
* 局部动态区域按需获取或边缘渲染（新鲜、个性化）
* `SSR` 只用于那些“静态化会产生明显业务损失”的页面

这类思路和 `Hydration` 的折中精神是一致的：把渲染工作拆开，让“该快的快、该活的活”。([web.dev][1])

---

## 收束：真正的结论不是二选一，而是把代价放到正确的位置

`SSR` 的价值很真实：它能在请求时输出更“活”的内容，尤其适合个性化与强实时场景。([web.dev][1])
它的代价也很真实：动态渲染的算力开销、可能变长的 `TTFB`、以及客户端 `Hydration` 带来的主线程压力，会直接反映到 `TBT` 与 `INP` 上。([web.dev][2])

工程上更可靠的路线是：

* 能静态化的部分尽量静态化，让缓存吃满
* 必须动态的部分再动态，并用 `HTML caching`、数据缓存把渲染次数压下去
* 能流式就流式，让响应更早开始
* 把 `Hydration` 当成性能预算来管理，而不是默认全量接管

当你用这套视角回看 `SSR vs 静态渲染`，争论会少很多：因为你不是在选口号，而是在选一条“可测量、可压缩成本、可控风险”的渲染链路。

[1]: https://web.dev/articles/rendering-on-the-web?utm_source=chatgpt.com "Rendering on the Web | Articles"
[2]: https://web.dev/articles/ttfb?utm_source=chatgpt.com "Time to First Byte (TTFB) | Articles"
[3]: https://web.dev/articles/tbt?utm_source=chatgpt.com "Total Blocking Time (TBT) | Articles"
[4]: https://web.dev/articles/inp?utm_source=chatgpt.com "Interaction to Next Paint (INP) | Articles"
[5]: https://nextjs.org/docs/app/guides/caching?utm_source=chatgpt.com "Guides: Caching"
[6]: https://vercel.com/blog/nextjs-server-side-rendering-vs-static-generation?utm_source=chatgpt.com "Next.js: Server-side Rendering vs. Static Generation"
[7]: https://react.dev/reference/react-dom/client/hydrateRoot?utm_source=chatgpt.com "hydrateRoot"
[8]: https://react.dev/reference/react-dom/server/renderToString?utm_source=chatgpt.com "renderToString"
[9]: https://react.dev/reference/react-dom/server/renderToPipeableStream?utm_source=chatgpt.com "renderToPipeableStream"
[10]: https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation?utm_source=chatgpt.com "Rendering: Static Site Generation (SSG)"


做 Web 性能优化时，SSR（Server-side rendering，服务端渲染）和静态渲染（常见是 SSG / Prerendering）经常被放在一起对比。很多团队会下意识觉得：只要把页面丢到服务端生成 HTML，用户就能更快看到内容，搜索引擎也更开心。现实更微妙：SSR 的“动态性”会带来明显的算力成本，而且如果实现方式不够讲究，还可能把 TTFB 拉长，甚至让客户端 Hydration 变成新的性能瓶颈，最后 TBT、INP 反而更难看。(web.dev)

SSR 与静态渲染到底怎么选：把 TTFB、Hydration、INP 一次讲透

做 Web 性能优化时，SSR（Server-side rendering，服务端渲染）和静态渲染（常见是 SSG / Prerendering）经常被放在一起对比。很多团队会下意识觉得：只要把页面丢到服务端生成 HTML，用户就能更快看到内容，搜索引擎也更开心。现实更微妙：SSR 的“动态性”会带来明显的算力成本，而且如果实现方式不够讲究，还可能把 TTFB 拉长，甚至让客户端 Hydratio

紫薇堂堂主

其他

SSR与静态渲染各有优劣：SSR适合个性化实时内容但成本高，静态渲染TTFB更快且成本低但数据可能陈旧。电商详情页等场景可采用混合方案，静态生成基础内容+动态获取库存价格。关键是根据业务需求选择渲染策略，通过流式渲染、HTML缓存、控制Hydration范围优化性能。

数据缓存

服务器

路由

4核4G3M云服务器 新用户低至38元/年！

2026采购季 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SSR 与静态渲染到底怎么选：把 TTFB、Hydration、INP 一次讲透-腾讯云开发者社区-腾讯云

SSR 与静态渲染到底怎么选：把 TTFB、Hydration、INP 一次讲透

SSR 与静态渲染到底怎么选：把 TTFB、Hydration、INP 一次讲透

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐