随笔

2026-09-02

告别 hydration 瓶颈：流式渲染最佳实践

2026 年的前端领域，已经没有人再争论“服务端渲染（SSR）”还是“客户端渲染（CSR）”这种二选一的问题。真正的战场早已转移：当用户打开一个页面时，从服务器返回第一个字节到页面变得可以交互，这中间到底需要多少毫秒？在过去的两年里，我们见证了无数团队为了优化 LCP（最大内容绘制）和 INP（交互到下一次绘制）而焦头烂额，而最核心的症结往往指向同一个词——hydration（注水）。

如果你曾经在性能监控后台看到过这样的数据：TTFB（首字节时间）只有 300ms，但 TTI（可交互时间）却需要恐怖的 6 秒钟，那么你已经直观地遭遇了 hydration 瓶颈。页面的 HTML 已经呈现给用户，视觉上完全可读，但点击按钮毫无反应，表单无法输入，就像一张精美的照片却无法走进其中。这不是网络慢的问题，而是 JavaScript 在客户端重新执行一遍组件树导致的“二次渲染”灾难。

今天，我想和你深入探讨流式渲染（Streaming Rendering）如何从架构层面根治这个顽疾。这不是一个简单的 API 替换，而是一套将“等待”变为“渐进”的思维革命。

hydration 为什么成为性能杀手

要理解流式渲染的价值，我们必须先清楚传统 SSR 的完整链路。在旧的模型下，无论使用 Next.js Pages Router 还是自定义 Node.js 服务器，流程都是线性的：服务器获取数据 → 渲染整个应用程序的 HTML 字符串 → 一次性发送给客户端。客户端收到后，浏览器解析 HTML 并进行绘制，然后下载所有 JavaScript 包，最后在内存中重新创建整个组件树，将事件监听器绑定到 DOM 节点上——这个过程就是 hydration。

听起来似乎没问题？问题出在三个层级。

第一，瀑布式请求。服务器渲染 HTML 前，必须等所有数据就绪。如果你的页面里有一个获取用户信息的组件，另一个获取产品列表的组件，还有一个获取评论的组件，那么服务器需要依次等待这三个请求全部完成，才能拼装出完整的 HTML。这相当于把三个网络请求串行化，用户的浏览器只能在一无所知的状态下干等。

第二，全有或全无的阻塞。因为服务器输出的是完整 HTML 字符串，所以哪怕只有底部的一个评论组件拖慢了速度，整个页面的首字节都会延迟。用户什么都看不到，直到最慢的那个数据源响应。这在移动端低网速环境下表现得尤为致命——一个超时的第三方接口就能拖垮整个页面。

第三，重复执行代价。客户端接收到的 HTML 已经是完整的视觉内容，但为了让它“活过来”，浏览器必须重新执行一遍 JavaScript。这意味着，所有被服务端渲染过的组件，在客户端都要再执行一次渲染逻辑。这种重复工作是纯粹的浪费。更糟的是，hydration 是一个同步的、不可中断的过程，一旦开始，主线程就会被占满，期间任何点击、滚动、输入事件都被迫排队等待。

2024 年之前，我们通常把上述问题归咎于“包太大”或者“需要做代码分割”。但试想：即使你把首屏 JavaScript 体积砍到 100KB，hydration 依然存在，只是时间缩短了，但并没有解决“等待所有组件就绪”和“同步阻塞”这两个结构性缺陷。而流式渲染，正好改变了这两个前提。

流式渲染的三种形态与核心思想

流式渲染并非一个新概念，但它在 Web 前端的最佳实践在 2025、2026 年迎来了爆发期。核心思想非常简单：把整个页面的渲染过程拆分成多个可独立完成的 chunk（块），服务器每准备好一块就发送一块，客户端每收到一块就立即展示一块，而不是等全部完成后统一交付。

目前业界常见的流式渲染有三种形态，理解它们的区别至关重要。

形态一：基于 HTTP 分块传输编码的 HTML 流（Streaming HTML）。这是最基础也最广泛的形态。Node.js 中的 renderToPipeableStream（React 18+）就是典型代表。服务器先发送页面的公共部分——比如导航栏和首屏框架——同时让耗时的组件在后台慢慢解析数据。当某个组件的数据就绪，服务器将其 HTML 片段作为额外的流块推送给客户端。浏览器会逐步更新 DOM，用户看到的不是空白，而是内容逐段浮现。

形态二：选择性 hydration（Selective Hydration）。这是针对交互能力的流式升级。结合 React Suspense，当流式输出的 HTML 块到达客户端后，React 可以立即对该块中已经加载好的组件进行 hydration，而无需等待其他尚未传输完成的块。换句话说，优先注水用户会先看到的区域，这是打破同步阻塞的关键。2026 年，React 19 的并发特性让选择性 hydration 成为了默认行为，而不是需要手动优化的进阶技巧。

形态三：岛屿架构（Islands Architecture）与部分 hydration（Partial Hydration）。这是比选择性 hydration 更彻底的方案，以 Astro、Qwik 和 Fresh 为代表。它的理念是：大部分页面组件本来是静态的，只需要渲染成 HTML 然后永不再需要 JavaScript。仅将那些真正需要交互的交互岛（如搜索框、购物车按钮、轮播图）在客户端独立 hydrate。2026 年的最佳实践已经明确：与其优化 hydration 速度，不如直接消灭不必要的 hydration。一个典型的博客详情页，可能 90% 的内容（正文、标题、图片）都无需 hydration，只有评论区和分享按钮是岛屿。

三种形态并不互斥，你可以组合使用。一个大型数据密集型的 SaaS 后台，适合流式 HTML + 选择性 hydration；一个内容营销网站，适合岛屿架构。流式渲染制胜的关键不是技术本身，而是根据页面属性选择合适的“渐进交付策略”。

实战：用 Suspense 拆解瀑布式请求

纸上谈兵没有意义，我们用代码说清楚流式渲染如何解决真实问题。假设我们正在用 Next.js App Router（2026 年已稳定支持 React 19）构建一个商品详情页，页面包含三个异步组件：商品基本信息（快）、个性化推荐（慢，依赖 A/B 测试服务）、用户评论（较慢，依赖第三方商家 API）。

在非流式 SSR 的旧模式下，页面组件会这样写：

export default async function ProductPage({ params }) {
  const [product, recommendations, reviews] = await Promise.all([
    fetchProduct(params.id),
    fetchRecommendations(params.id),
    fetchReviews(params.id),
  ]);
  return (
    <main>
      <ProductInfo data={product} />
      <RecommendationList data={recommendations} />
      <ReviewList data={reviews} />
    </main>
  );
}

看似用了 Promise.all 是并行请求，但浏览器的 TTFB 依然要等到最慢的推荐接口（可能长达 2 秒）结束后才能收到任何 HTML。这就是全有或全无的弊端。

使用流式渲染后，代码变成：

export default function ProductPage({ params }) {
  return (
    <main>
      {/* 这个组件在服务器端一有数据，立即作为流输出 */}
      <Suspense fallback={<ProductSkeleton />}>
        <ProductInfo promise={fetchProduct(params.id)} />
      </Suspense>

      <Suspense fallback={<RecommendationSkeleton />}>
        <RecommendationList promise={fetchRecomm(params.id)} />
      </Suspense>

      <Suspense fallback={<ReviewSkeleton />}>
        <ReviewList promise={fetchReviews(params.id)} />
      </Suspense>
    </main>
  );
}

关键在于，React 19 中支持即将 promise 作为 prop 传入 Suspense 包裹的边界组件。服务器会立刻渲染 <main> 的框架和第一个 Suspense 边界的 fallback 骨架屏，并把它作为第一个流 chunk 发送给浏览器。随后，当商品基本信息数据到达，服务器渲染出真实的 <ProductInfo> HTML，作为第二个 chunk 紧跟着发送。浏览器收到后，用真实内容替换掉骨架屏。推荐和评论部分同理，谁先准备好就先发送谁。

这个改动带来的性能提升是立竿见影的：TTFB 从“最慢接口耗时”降低为“页面框架耗时”，通常能减少 300ms 到 1.5s。用户大概在首屏 0.6s 就能看到页面的标题和商品简介骨架，1s 时看到了商品详情，推荐区则可能在 1.8s 后慢慢浮现。这比白屏 2 秒的体验强上一个数量级。

但我们注意，这仅仅是流式 HTML，hydration 还没开始。在客户端，React 需要在流块到达时逐步 hydrate。React 19 的选择性 hydration 会按照 Suspense 边界来决定优先级：离视口近的边界先 hydrate，用户正在交互的边界会紧急提升优先级。这就是从“全量同步”到“按需渐进”的优雅转变。

岛屿架构与 0 JavaScript 默认值

如果你觉得上述方案依然太“重”——毕竟每个商品组件在客户端还是会执行一次 JavaScript——那么 2026 年最值得尝试的实践就是岛屿架构。Astro 在 2024 年 5.0 之后已经将“默认零 JS”做成服务端渲染的标配，而 Qwik 的 resume 技术则进一步消灭了 hydration 的重复执行。今天，这套方案已完全成熟，可应用于生产环境。

在岛屿架构中，服务端返回的 HTML 是整个页面的最终状态，其中只有带 client:visible 或 client:idle 指令的组件会被异步加载对应的 JavaScript 并在浏览器端独立初始化。以 Astro 为例，下面是一段典型代码：

---
import ProductGallery from '../components/ProductGallery.astro';
import AddToCartButton from '../components/AddToCartButton.jsx';
import ReviewSection from '../components/ReviewSection.jsx';

// 服务端请求数据
const product = await fetchProduct(Astro.params.id);
const reviews = await fetchReviews(Astro.params.id);
---

<main>
  <!-- 纯静态组件，直接输出 HTML，客户端零 JS 开销 -->
  <ProductGallery images={product.images} />

  <!-- 这是交互岛：仅当用户滚动到按钮可见时才加载 JS 并初始化 -->
  <AddToCartButton client:visible productId={product.id} />

  <!-- 这是第二个交互岛，懒加载评论区的展开交互 -->
  <ReviewSection client:visible reviews={reviews} />
</main>

在构建产物中，你会发现 AddToCartButton 的 JavaScript 被单独提取成了极小的 chunk，而大型的评论交互 JS 则会按需加载。页面初始 HTML 里根本没有整页的 hydration 脚本。用户的浏览器在加载完 HTML 和必要的 CSS 后，主线程几乎是空闲的——这意味着用户可以立即滚动、点击甚至输入，没有任何等待事件绑定的过程。

我把这称为“HTML 优先，JS 兜底”。2026 年的浏览器对 HTML 解析和 CSS 渲染有着极致的优化，静态内容是信息传递的主要载体。岛屿架构把动态交互视为少数特例，用“增强”而非“重建”的方式来对待——这是思维上的根本方向修正。

如果你正在维护一个内容量巨大的老项目，不妨从购物按钮、评论区、导航菜单这类独立组件开始迁移，逐步把你应用中的“海洋”变成“岛屿”。你不需要重写所有页面，只需要对那些交互性极低的模板页面采用岛屿策略。

调试流式渲染：如何量化并改进性能

流式渲染虽然强大，却给性能测量和调试带来了新挑战。传统的 Lighthouse 分数在流式页面面前已经不够准确——因为它测量的是“最终稳定状态”，而流式体验更强调“渐进式呈现”。

2026 年的最佳实践是追踪四个核心指标：

首字节时间（TTFB）：流式渲染显著降低了这个值，但注意，不要只关注平均值。你应该监控不同网络条件下 TTFB 的分布，尤其是 p75 和 p95 分位。因为流式渲染鼓励的是尽早发送，如果 TTFB 依然很高，说明你的服务端仍存在阻塞渲染的关键路径——比如某个同步操作或不可延后的数据库查询。

最大内容绘制（LCP）：流式下 LCP 的测量变得微妙。最大内容元素可能是首屏的产品图，也可能是流式加载的商品详情文字。关键是确保你最重要的内容分块尽快出现在流的前端。你可以使用 server-timing 响应头来标记每个 chunk 的时间戳，从而定位内容到达时间。

首个交互延迟（INP）：这是衡量 hydration 后交互体验的核心指标。流式渲染的目标应当是把 INP 控制在 200ms 以内。如果你的 INP 超标，说明选择性 hydration 的优先级策略没有生效。检查是否误将大量非关键组件包在同一个 Suspense 边界里，导致它们被作为一个整体阻塞了主线程。

网络面板的 chunk 时间线：这是我最推崇的调试手段。打开 Chrome DevTools 的 Network Tab，勾选“Show Streaming”，你会看到响应体是一块一块到达的。你可以直观地看到第一个 chunk（通常是导航栏）到达的时间，以及最后一个 chunk（可能是评论）到达的时间差。理想情况下，时间差不超过 2s。如果某个 chunk 延迟异常，那么对应的数据源请求一定存在瓶颈。

另外，2026 年的浏览器已经开始支持“流式 HTML 的可视化覆盖层”，它在 Performance 面板中用不同颜色的条带标识每个 HTML chunk 的解析和绘制区间。这比早年看瀑布图要直观得多。

最后提醒一个容易踩的坑：谨慎使用缓存。流式渲染与 CDN 边缘缓存的互操作需要仔细设计。虽然 HTML 流可以被 CDN 缓存，但个性化用户信息（如推荐购物车）不应该被缓存。最佳实践是在流中拆分两个部分：公共部分（可缓存）和个性化部分（动态流）。Next.js 中可以使用 experimental.partialPrerendering（PPR）启用部分预渲染，或者手动用 next: { headers } 来控制缓存策略。

2026 年的工具链与未来展望

到 2026 年，前端生态几乎已经与流式渲染同构。React 19 的 renderToPipeableStream 早已成为 createServerRouter 内部默认选项；Next.js 15 之后的版本已经默认启用流式渲染并结合 React 编译器自动优化 re-render；更值得一提的是，Vue 3.5+ 也提供了 renderToWebStream，配合 defineAsyncComponent 可以实现类似的渐进交付。

此外，边缘运行时（Edge Runtime）如今已成为流式渲染的最佳拍档。Cloudflare Workers、Vercel Edge Functions 天然支持流式响应体，你可以将页面框架的渲染放到距离用户最近的边缘节点，再通过内网快速回源到容器化服务器获取数据。TTFB 可以被压缩到极低的水平——这也是我们团队在 2026 年将服务从单体 Node.js 迁移到边缘计算架构的核心原因。

但这不意味着流式渲染没有代价。它的复杂性主要在于错误处理和运行时不确定性。例如，在流已经发送一部分后，如果某个后端数据源抛错，你无法返回一个错误的状态码（如 404），因为响应头已经发出去了。你需要一种“Suspense 边界错误恢复”策略，通常是在前端显示错误 UI，而将状态码保留为 200。这要求后端有更健全的监控和告警，而不是依赖 HTTP 状态来判断成功与否。

流式渲染还迫使工程团队重新思考 QA 策略。以往自动化测试可以等到整个 DOM 加载完毕后进行断言。现在你需要轮询检查特定的 HTML 片段是否出现在流中——好在 Playwright 和 Cypress 都已支持流式响应断言。我们的经验是，编写 E2E 测试时，使用 page.waitForSelector 并指定可见状态，而不要依赖 DOMContentLoaded 事件。

展望未来的 18 个月，我看到了一个更令人兴奋的趋势：流式渲染与本地优先（Local First）架构的结合。既然服务端可以将内容实时推送，那么客户端是否也可以流式同步本地数据库的数据？想象一下，当用户在商品详情页快速滚动时，缓存的数据流与服务器流式推送的交织，会让页面几乎像一个原生应用那样即时响应。已有包括 ElectricSQL 在内的项目在实验这个方向。

更进一步，AI 驱动的动态个人化流式渲染也值得关注。2026 年的边缘智能网关已经可以根据用户的实时行为（如鼠标悬停、滚动速度）动态决定下一个 HTML chunk 是渲染推荐列表还是展开文档目录。流式不再只是一个性能优化手段，它正在变成一种“按需实时生成”的内容分发机制。

结语

从“一次性交付整个页面”到“边计算边交付”，流式渲染带给我们的不只是几毫秒的性能提升，而是重新定义了 Web 应用的体验模型。它承认了网络的不可靠和设备的多样性，用渐进的方式匹配现实的复杂。

如果你还在被 hydration 的规模拖累，不妨从今天开始做三件事：第一，挑选你项目中最慢的、数据依赖最重的一个页面，接入 Suspense 流式渲染并观察 TTFB 变化。第二，审视你所用的前端框架是否提供了开箱即用的流式支持——如果没有，切换或扩展它。第三，向团队普及“HTML 优先”的架构理念，因为未来的 Web 性能竞争，不再取决于你写了多少代码，而取决于你如何聪明地省略不必要的传输与执行。

流式渲染不是银弹，但它无疑是我们手中最锋利的一把掘进工具。告别 hydration 瓶颈，就是把用户体验从“等待中”解放，让美好分段抵达。