流式 SSR 与 Progressive Enhancement：别让首屏和交互互相伤害

前端这几年有个很微妙的悖论：

• CSR 时代，大家抱怨首屏白
• SSR 时代，大家开始抱怨“首屏看着出来了，但还是不能用”

这说明问题从来不只是“有没有 HTML”，而是：

用户是不是在等待一整套系统全部准备完毕之后，才终于得到一点可操作性？

传统 SSR 的确解决了“浏览器先拿到骨架”的问题，但如果页面必须等到完整数据、完整 JS、完整 hydration 都完成后，用户体验仍然像在排队等叫号。

流式 SSR 和 Progressive Enhancement 之所以重要，不是因为它们新，而是因为它们共同回答了一个产品级问题：

怎样让页面更早出现，同时更早有用。

1. 先区分三个时间点

很多团队讨论 SSR 时，把所有“快”都混成一件事。其实至少有三件事：

1. 什么时候看到内容
2. 什么时候能开始理解内容
3. 什么时候能开始操作内容

流式 SSR 主要改善第 1 件和第 2 件，渐进增强主要改善第 3 件。

1.1 传统 SSR 的瓶颈：必须等“完整”才能发车

在很多实现里，服务端会先把整棵页面准备完整：

• 数据都拿齐
• 组件都渲染完
• HTML 全部拼好

然后再一次性发送给浏览器。

这看似稳妥，问题是：最慢的那个模块，会拖住整个首屏。

一个推荐位接口慢 800ms，页面主体也得一起陪跑。这就像全班同学因为最后一个人没交作业，整节课都不能下课。

1.2 流式 SSR 的核心：先把能确定的部分发出去

流式渲染的思路很朴素：

先把稳定的壳和关键内容片段发送给浏览器，慢模块稍后补上。

它带来的不是“理论上的极致性能”，而是更诚实的用户感知：页面在持续展开，而不是一直沉默。

2. Progressive Enhancement 为什么不是“复古理念”

很多人听到“渐进增强”会想到一套很老派的前端哲学，好像它只适用于低配浏览器。

其实在今天，它更像一种产品纪律：

页面最关键的任务，不能全部押注在 JavaScript 最终成功执行这件事上。

对于现代站点，渐进增强不意味着不用 JS，而是意味着：

• 没有 JS 时，核心信息仍然可见
• JS 还没准备好时，用户不至于完全卡死
• JS 准备好后，再逐步增强交互体验

这不是保守，而是鲁棒性。

3. 流式 SSR 和渐进增强，应该怎么配

一个更现实的页面分层方式是：

3.1 第一层：立即可见的稳定外壳

包括：

• 头部导航
• 页面标题
• 核心说明文案
• 基本布局容器

这部分越早到，用户越早理解“我来到了哪里”。

3.2 第二层：关键任务区优先完成

比如：

• 商品详情页的商品图、标题、价格
• 文章页的标题、摘要、正文
• 控制台页面的核心表格或图表摘要

这部分决定用户是否开始投入注意力。

3.3 第三层：增强型模块延后到位

包括：

• 推荐内容
• 个性化卡片
• 非关键评论模块
• 富交互工具面板

这部分很有价值，但不应该拖累前两层。

4. 一个够用的落地模式

4.1 页面结构上，把“慢模块”显式隔离

不要让一个页面内部所有模块都共享同一条等待链。

伪代码可以这样理解：

const criticalDataPromise = getCriticalData()
const recommendationPromise = getRecommendations()

const criticalData = await criticalDataPromise

renderShell()
renderCriticalSection(criticalData)
streamPlaceholder('recommendation')

recommendationPromise.then((data) => {
  streamRecommendationSection(data)
})

关键不是语法，而是边界：重要信息优先闭环，次要模块异步跟进。

4.2 交互上，先保障关键表单和导航

如果一切交互都必须等全量 hydration 才可用，那流式 SSR 只是让用户更早看到“不可操作的界面”。

因此优先级应当是：

• 搜索框可输入
• 主导航可点击
• 核心提交按钮能工作

把其他花哨交互排在后面，体验反而更完整。

4.3 视觉上，要让“还没来得及增强”的状态也自然

不要把占位状态做成一种羞耻标记。好的渐进增强页面，在弱网和慢设备上也应该像一个有节奏的产品，而不是一堆故障灯。

5. 什么时候它值得做

流式 SSR 并不是所有项目的标准答案。

适合的场景：

• 内容页、详情页、营销页，首屏价值高
• 存在部分慢模块，但核心内容能先完成
• 页面模块边界清晰，适合拆出关键路径

不一定值得的场景：

• 极简单页应用，本身首屏负担很轻
• 后台系统以强交互为主，首屏信息展示价值有限
• 团队还没建立组件边界和数据分层，直接上流式只会把复杂度前置

一个成熟判断标准是：

如果你无法明确指出“哪部分必须先给用户，哪部分可以稍后补”，那你还没准备好做流式优化。

6. 最容易踩的坑

6.1 把所有模块都做成 suspense，结果整个页面像抽卡

用户不怕页面逐步展开，用户怕每一块都在随机跳变。节奏比技术更重要。

6.2 首屏 HTML 提前到了，但关键 CSS 和字体没跟上

这会让页面“理论上更快，视觉上更乱”。

6.3 过早追求花式流式，忽略最朴素的缓存与数据合并

有些页面真正的问题不是不会 stream，而是后端串行请求太多。不要用复杂方案掩盖基础问题。

7. 一个更现实的工程结论

流式 SSR 解决的是“别让最慢模块拖住全场”，Progressive Enhancement 解决的是“别把核心任务押注在 JS 最终成功这件事上”。

两者结合起来，本质上是在做一件成熟系统都会做的事：

把页面拆成不同优先级，再按优先级分配等待成本。

这件事很有思想含量，因为它要求团队接受一个事实：

页面不是一个整体，它是一组价值不同的承诺。

总结

• 流式 SSR 让关键内容更早到达，不再被最慢模块拖住。
• 渐进增强让核心任务更早可用，不再完全依赖全量 JS。
• 真正的收益来自优先级拆分，而不是技术名词本身。
• 如果页面边界混乱，先整理边界，再谈流式。

小明收尾一句：

好的页面不是“一次性全部出现”，而是每一步出现都刚好配得上用户此刻的等待。