发布于 由admin

解析 ‘Streaming SSR’ 中的 HTML 注入排序：React 如何决定 CSS、JS 和数据流的先后顺序？

在高性能Web应用的构建中，服务器端渲染（SSR）扮演着至关重要的角色。它不仅能显著提升首次内容绘制（FCP）和最大内容绘制（LCP），还能改善搜索引擎优化（SEO）。然而，传统的SSR模式，如React的renderToString，存在一个固有缺陷：它必须等待整个应用的数据加载和组件渲染完成后，才能将完整的HTML字符串一次性发送给客户端。这对于数据密集型或包含复杂组件树的应用而言，意味着较长的首字节时间（TTFB），从而影响用户体验。

React 18引入的Streaming SSR（流式SSR）彻底改变了这一局面。通过renderToPipeableStream API和内置的Suspense组件，React能够将HTML响应分解成多个块，并在服务器上异步生成这些块，然后以流的方式逐步发送给客户端。这种方式允许浏览器在接收到完整HTML之前就开始解析和渲染部分内容，显著提升了用户体验。

然而，Streaming SSR的强大之处也带来了新的复杂性：当HTML内容、CSS样式、JavaScript逻辑和初始数据以非原子化的方式注入到文档中时，它们的先后顺序变得至关重要。不恰当的注入顺序可能导致闪烁未样式内容（FOUC）、交互延迟或甚至功能错误。本文将深入探讨React在Streaming SSR模式下，如何精心设计CSS、JS和数据流的注入排序策略，以及其背后的性能考量和实现机制。

一、传统SSR的局限与Streaming SSR的崛起

在深入Streaming SSR之前，我们首先回顾一下传统SSR的运作方式。

1.1 传统SSR：一次性交付的瓶颈

在React 18之前，典型的SSR流程通常使用ReactDOMServer.renderToString或renderToStaticMarkup。

// server.js (Traditional SSR)
import React from 'react';
import ReactDOMServer from 'react-dom/server';
import App from './App'; // 假设这是你的根组件

// ...其他设置，如Express

app.get('/', (req, res) => {
  // 1. 获取数据 (假设是同步或通过await等待)
  const initialData = fetchDataSynchronouslyOrAwait();

  // 2. 渲染整个应用到HTML字符串
  const appHtml = ReactDOMServer.renderToString(<App initialData={initialData} />);

  // 3. 构建完整的HTML响应
  const html = `
    <!DOCTYPE html>
    <html>
      <head>
        <title>Traditional SSR App</title>
        <link rel="stylesheet" href="/styles.css">
        <script>window.__INITIAL_DATA__ = ${JSON.stringify(initialData)};</script>
      </head>
      <body>
        <div id="root">${appHtml}</div>
        <script src="/bundle.js"></script>
      </body>
    </html>
  `;

  // 4. 一次性发送完整的HTML响应
  res.send(html);
});

这种模式的缺点显而易见：

  • 瀑布式数据获取： 服务器必须等待所有数据加载完毕，才能开始渲染。如果应用中某个组件的数据获取耗时较长，整个SSR过程都会被阻塞。
  • 整体性渲染： 整个组件树被一次性渲染成HTML字符串。
  • 长TTFB： 用户必须等待整个HTML响应到达并被浏览器解析，才能看到任何内容。对于复杂的应用，这可能导致较长的白屏时间。
  • 不可中断： 一旦渲染开始，直到生成完整的HTML字符串，服务器无法提前发送任何内容。

1.2 Streaming SSR：分块交付的艺术

React 18的renderToPipeableStream旨在解决上述问题，它与Suspense组件紧密结合，允许服务器逐步发送HTML。

// server.js (Streaming SSR)
import React from 'react';
import ReactDOMServer from 'react-dom/server';
import App from './App'; // 假设这是你的根组件
import { Writable } from 'stream'; // Node.js stream

// ...其他设置，如Express

app.get('/', (req, res) => {
  res.setHeader('Content-Type', 'text/html');
  res.setHeader('Transfer-Encoding', 'chunked'); // 明确告知浏览器是分块传输

  let didError = false;

  const { pipe } = ReactDOMServer.renderToPipeableStream(<App />, {
    onShellReady() {
      // 当"shell"（即没有被Suspense包裹的初始HTML）准备好时
      // 我们可以发送HTML的头部和初始的body内容
      res.statusCode = didError ? 500 : 200;
      res.write(`
        <!DOCTYPE html>
        <html>
          <head>
            <title>Streaming SSR App</title>
            <link rel="stylesheet" href="/styles.css">
            <script src="/bundle.js" defer></script>
          </head>
          <body>
            <div id="root">
      `);
      pipe(res); // 开始将HTML流式传输到响应
      res.write(`
            </div>
          </body>
        </html>
      `);
    },
    onShellError(err) {
      // 处理shell渲染错误
      didError = true;
      console.error(err);
      res.statusCode = 500;
      res.send('<h1>Something went wrong on server shell.</h1>');
    },
    onAllReady() {
      // 当所有Suspense边界都已解决，所有内容都已发送时
      // 通常用于结束响应，但pipe(res)本身会处理
      // console.log('All content streamed.');
    },
    onError(err) {
      // 处理任何Suspense边界内的错误
      didError = true;
      console.error(err);
    }
  });
});

关键概念：

  • Shell (外壳): 指的是应用中不被Suspense包裹的部分。这部分内容会首先被渲染并发送。
  • Suspense 边界: Suspense组件创建了内容加载的边界。当Suspense的子组件正在加载数据时，fallback内容会被渲染并作为占位符发送。
  • 异步填充: 当Suspense边界内的数据加载完成后，React会生成包含实际内容的额外HTML块，并通过流发送给客户端，替换掉之前的fallback占位符。
  • 可中断性: 服务器不再需要等待所有数据加载完成。它可以在数据加载的同时，将已就绪的HTML部分发送出去。

二、HTML文档结构与React的注入策略

在Web标准中，一个典型的HTML文档结构如下：

<!DOCTYPE html>
<html>
  <head>
    <!-- 元数据、标题、CSS、预加载提示等 -->
  </head>
  <body>
    <!-- 页面内容、JavaScript脚本等 -->
  </body>
</html>

React Streaming SSR的注入策略，就是围绕这个标准结构，根据性能优先级和用户体验目标，动态地插入CSS、JS和数据。

2.1 注入点与性能考量

不同的资源类型，其最佳注入位置和方式各有不同，主要受以下因素影响：

  • 渲染阻塞： <script>标签（不带defer或async）会阻塞HTML解析和渲染。<link rel="stylesheet">也会阻塞渲染直到CSS文件加载并解析完成。
  • 首次内容绘制 (FCP)： 用户看到页面上任何内容的时间。为了快速FCP，关键CSS应尽早提供。
  • 最大内容绘制 (LCP)： 页面中最大的内容元素渲染完成的时间。
  • 首次输入延迟 (FID) / 交互时间 (TTI)： 用户能够与页面交互的时间。JavaScript的加载和执行会直接影响TTI。
  • 闪烁未样式内容 (FOUC)： HTML内容在CSS加载之前显示，导致页面短暂地以无样式状态呈现。

React通过以下机制在Streaming SSR中管理注入：

  1. 初始HTML Shell： onShellReady 回调触发时，React会发送一个包含HTML骨架、<head>内容（元数据、关键CSS链接）以及<body>中非Suspense包裹部分的HTML。这部分HTML中会包含特殊的注释标记作为Suspense占位符。
  2. 异步流式更新： 当Suspense边界内的异步操作完成时，React会生成包含实际内容的新HTML片段，并将其包装在<script>标签中，发送到客户端。这些脚本会在客户端执行，替换掉相应的占位符。

三、CSS注入的策略与排序

CSS的注入目标是确保页面尽早呈现正确的样式，避免FOUC，并优化FCP。

3.1 关键CSS (Critical CSS)

  • 定义： 渲染首屏内容所需的最小CSS集合。
  • 注入点： <head>标签内的<style>块。
  • 优先级： 最高。
  • 原因：
    • 内联CSS不涉及额外的网络请求，能最快地被浏览器解析。
    • 放置在<head>中可以确保在HTML内容开始渲染之前，样式就已经就位，有效防止FOUC。
    • 浏览器在解析到<style>标签后会立即应用样式，从而加速FCP。

示例：

<!DOCTYPE html>
<html>
  <head>
    <title>Streaming SSR App</title>
    <!-- 关键CSS：内联到 <head> 中 -->
    <style>
      body { font-family: sans-serif; margin: 0; padding: 0; }
      #header { background-color: #f0f0f0; padding: 1rem; }
      /* ... 更多首屏关键样式 ... */
    </style>
    <!-- ... 其他元数据 ... -->
  </head>
  <body>
    <!-- ... -->
  </body>
</html>

在实际应用中，关键CSS通常通过构建工具（如Webpack配合mini-css-extract-plugin和critters或critical库）在服务端构建时提取并内联。React本身并不直接处理关键CSS的提取，这需要开发者的构建流程配合。

3.2 非关键CSS

  • 定义： 渲染非首屏内容或完整页面所需的CSS。
  • 注入点：
    • <head>标签内的<link rel="stylesheet" href="...">。
    • 通过preload和onload属性实现异步加载的<link>。
    • 对于Streaming SSR，可能在<body>内通过流式HTML块注入的<style>标签。
  • 优先级： 中到低。

示例：

<!DOCTYPE html>
<html>
  <head>
    <title>Streaming SSR App</title>
    <style> /* Critical CSS */ </style>
    <!-- 非关键CSS：通过 <link> 引入，放置在 <head> 中 -->
    <link rel="stylesheet" href="/main.css">
    <!-- 或者，为了更快的非阻塞加载 -->
    <link rel="preload" href="/defer.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="/defer.css"></noscript>
  </head>
  <body>
    <!-- ... -->
  </body>
</html>

Streaming SSR对CSS注入的影响：

React Streaming SSR的独特之处在于，它允许组件在Suspense边界内异步加载并渲染。如果一个组件引入了新的、未包含在初始关键CSS中的样式，这些样式可以作为后续的HTML流的一部分被发送。

例如，假设一个ProductDetails组件被包裹在Suspense中，并且它有自己独立的CSS-in-JS样式。当ProductDetails的数据加载完毕后，React会发送一个包含该组件的HTML以及其所需样式的块。这些样式通常会以新的<style>标签的形式，直接注入到<body>中（或者通过JavaScript注入到<head>中，这取决于具体的CSS-in-JS库及其SSR实现）。

<!-- Initial HTML Shell -->
<!DOCTYPE html>
<html>
  <head>
    <title>Streaming SSR App</title>
    <style>/* critical styles */</style>
    <link rel="stylesheet" href="/main.css">
  </head>
  <body>
    <div id="root">
      <div id="header">Welcome</div>
      <!-- Suspense fallback for ProductDetails -->
      <div id="spinner">Loading product...</div>
      <!-- React internal marker for Suspense boundary -->
      <!--$?S:0-->
    </div>
    <!-- Hydration script placeholder -->
    <script src="/bundle.js" defer></script>
  </body>
</html>

<!-- Later streamed chunk when ProductDetails resolves -->
<script>
  // This script is executed on the client
  // It replaces the fallback content with actual content
  // and injects new styles if needed.
  // The actual mechanism uses ReactDOM.render/hydrate internally
  // to process the new HTML and potentially CSS.
  // Example of what React might send for a CSS-in-JS library like Styled Components:
  // It might send a new <style> tag or a CSS string to be appended to an existing one.
  const styleTag = document.createElement('style');
  styleTag.textContent = `.ProductDetails-root { border: 1px solid #eee; padding: 10px; }`;
  document.head.appendChild(styleTag); // Or document.body.appendChild(styleTag)
  const fallback = document.getElementById('spinner'); // Or a more precise marker
  if (fallback) {
    fallback.outerHTML = '<div class="ProductDetails-root"><h2>Awesome Product</h2><p>Description...</p></div>';
  }
</script>
<!--$S:0-->
<div class="ProductDetails-root"><h2>Awesome Product</h2><p>Description...</p></div>
<!--/$-->

总结CSS注入策略：

样式类型 注入方式 注入位置 优先级 目的
关键CSS <style> 内联 <head> 高 防FOUC，加速FCP
非关键CSS <link rel="stylesheet"> <head> 中 正常加载页面样式
异步CSS <link preload> + JS <head> 中 非阻塞加载，但仍能尽早获取
组件级CSS <style> (通过流式JS) <body> 或 <head> 低 随组件内容异步加载，避免初始渲染阻塞

四、JavaScript注入的策略与排序

JavaScript的注入目标是尽快实现页面的交互性（TTI），同时避免阻塞初始渲染。

4.1 核心应用Bundle (Hydration Script)

  • 定义： 包含React运行时、应用逻辑以及用于客户端“水合”（Hydration）的JavaScript代码。
  • 注入点： 通常在<body>标签的底部，紧邻</div>之前，或者使用defer属性在<head>中。
  • 优先级： 高（对于交互性）。
  • 原因：
    • 非阻塞渲染： 将脚本放在<body>底部（或使用defer）可以确保浏览器在下载和执行JS之前，已经解析并渲染了大部分HTML。这对于FCP至关重要。
    • DOM就绪： 水合过程需要完整的DOM树才能正确地挂载事件监听器和恢复组件状态。放在底部或defer可以保证DOM在脚本执行时已经准备就绪。

示例：

<!DOCTYPE html>
<html>
  <head>
    <title>Streaming SSR App</title>
    <style>/* ... */</style>
    <!-- 推荐方式：在 <head> 中使用 defer -->
    <script src="/bundle.js" defer></script>
  </head>
  <body>
    <div id="root">
      <!-- SSR渲染的HTML内容 -->
    </div>
    <!-- 另一种方式：在 </body> 结束前 -->
    <!-- <script src="/bundle.js"></script> -->
  </body>
</html>

defer vs. async vs. 底部：

  • defer: 脚本在HTML解析完成后，但在DOMContentLoaded事件触发前执行。保持脚本的相对执行顺序。非常适合依赖DOM且不应阻塞渲染的应用脚本。
  • async: 脚本下载完成后立即执行，不阻塞HTML解析，也不保证执行顺序。适用于不依赖DOM且独立性强的脚本（如分析脚本）。
  • <body>底部 (无属性): 脚本会在下载和执行期间阻塞HTML解析。不推荐用于大型应用脚本。

React的renderToPipeableStream默认会在onShellReady回调中建议将主脚本标记为defer。

4.2 数据序列化脚本 (Initial Data / State)

  • 定义： 包含服务器在SSR过程中获取到的初始数据，用于客户端水合时恢复组件状态或填充Redux/Context store。
  • 注入点： 在<body>中，位于水合脚本 (bundle.js) 之前。
  • 优先级： 高（对于水合）。
  • 原因：
    • 水合前可用： 客户端的水合脚本在执行时需要这些初始数据来使React组件与其服务器渲染的状态匹配。如果数据在水合脚本之后才可用，会导致水合失败或警告。
    • 内联： 通常以内联<script>标签的形式注入，避免额外的网络请求。

示例：

<!DOCTYPE html>
<html>
  <head>
    <title>Streaming SSR App</title>
    <style>/* ... */</style>
    <script src="/bundle.js" defer></script>
  </head>
  <body>
    <div id="root">
      <!-- SSR渲染的HTML内容 -->
    </div>
    <!-- 初始数据脚本，在 hydration 脚本之前 -->
    <script>
      // 假设服务器获取的用户数据
      window.__INITIAL_DATA__ = { user: { id: 1, name: "Alice" } };
      // 或者 React 内部用于 Context 的序列化数据
      window.__REACT_CONTEXT_VALUE__ = { /* ... */ };
    </script>
  </body>
</html>

React 18的Streaming SSR特别强调了这种数据流的注入。对于Suspense边界内的数据，当数据加载完成时，React会发送一个包含额外<script>标签的块。这个脚本不仅会注入实际的HTML内容，还可能包含该组件所需的任何新的客户端状态。

<!-- Later streamed chunk when ProductDetails resolves -->
<script>
  // 这段脚本由 React 自动生成并流式发送
  // 它的作用是：
  // 1. 将新的HTML内容注入到DOM中，替换掉之前的fallback。
  // 2. 如果ProductDetails组件使用了 React Context，这里可能会包含更新 Context Provider 的数据。
  // 3. 如果ProductDetails组件内部有 useState，这里可能会包含该 useState 的初始值，以确保正确水合。
  // 例如，它可能调用 ReactDOM.createRoot().render() 或 ReactDOM.hydrateRoot() 内部机制
  // 来处理这个局部更新。
  // 具体的实现细节在 React 运行时内部，会利用特定的标记 (`<!--$S:0-->`) 来定位和替换内容。

  // 假设的简化演示，实际机制更复杂且由 React 内部处理
  const targetId = 'S:0'; // 对应 Suspense 边界的ID
  const newHtml = '<div class="ProductDetails-root"><h2>Awesome Product</h2><p>Description...</p></div>';
  // React 内部会找到 <!--$S:0--> 标记并进行替换
  // 假设这是 React 内部机制调用的函数
  // __webpack_modules__[0].default.resolveSuspenseChunk(targetId, newHtml, new_state_if_any);
</script>

这种动态注入的脚本，允许页面在初始shell水合完成后，继续进行局部水合（或客户端渲染），而无需重新加载整个页面。

4.3 异步/延迟加载的JavaScript

  • 定义： 非核心功能、按需加载的模块或第三方脚本（如分析、广告）。
  • 注入点： 灵活，通常在<head>中使用async或defer，或在<body>中按需动态加载。
  • 优先级： 低到中。
  • 原因： 不应阻塞关键渲染路径或水合过程。

示例：

<!DOCTYPE html>
<html>
  <head>
    <title>Streaming SSR App</title>
    <style>/* ... */</style>
    <script src="/bundle.js" defer></script>
    <!-- 第三方分析脚本，使用 async 不阻塞 -->
    <script async src="https://www.google-analytics.com/analytics.js"></script>
  </head>
  <body>
    <!-- ... -->
  </body>
</html>

Streaming SSR对JavaScript注入的影响：

除了主应用 bundle 和初始数据脚本外，Streaming SSR还允许在Suspense边界内部进行代码分割（Code Splitting）。当一个被React.lazy或动态import()加载的组件位于Suspense边界内时，只有当该边界的数据准备就绪时，对应的JS代码块才会被下载。

React会在流式响应中包含<script>标签，这些标签会触发浏览器下载并执行额外的JS模块。这些模块可能包含：

  • 组件代码： 实际的组件逻辑。
  • 依赖： 该组件特有的库或工具函数。

这种按需加载的机制进一步优化了TTI，因为浏览器不需要一次性下载所有JS，而是在需要时才获取。

总结JavaScript注入策略：

JS 类型 注入方式 注入位置 优先级 目的
水合脚本 <script defer> <head> 或 <body> 底部 高 使页面可交互，恢复React应用
初始数据脚本 <script> 内联 <body> (水合前) 高 为水合提供初始状态和数据
异步模块 <script> (流式) <body> (动态注入) 中 随异步组件加载，实现代码分割
第三方脚本 <script async/defer> <head> 或 <body> 低 非核心功能，不阻塞关键路径

五、数据流与状态注入的机制

数据是驱动React应用的核心。在Streaming SSR中，数据流的管理尤为复杂，因为它需要在服务器和客户端之间无缝衔接，并支持异步加载。

5.1 初始数据 (Initial Data)

  • 来源： 服务器在渲染初始shell时，同步或通过await获取的全局数据。
  • 注入方式： 如前所述，通过内联<script>标签，将数据序列化为JSON字符串，并挂载到window对象上。
  • 目的：
    • 同步水合： 确保客户端在水合时能立即访问到服务器渲染时所用的数据。
    • 避免二次请求： 客户端无需再次向API请求相同的数据。

示例：

<!DOCTYPE html>
<html>
  <head>...</head>
  <body>
    <div id="root">...</div>
    <script>
      // 服务器渲染时，从数据库或API获取的全局配置、用户信息等
      window.__INITIAL_DATA__ = {
        settings: { theme: 'dark' },
        currentUser: { id: 'user123', name: 'John Doe' }
      };
    </script>
    <script src="/bundle.js" defer></script>
  </body>
</html>

客户端的bundle.js在执行时，会读取window.__INITIAL_DATA__来初始化其Redux store、Context Provider或组件的内部状态。

5.2 Streaming Suspense Data

这是Streaming SSR最核心的数据流机制。当一个组件被Suspense包裹，且其内部通过异步方式（如fetch或Promise）获取数据时，React会采取以下步骤：

  1. 服务器端渲染：

    • 当遇到Suspense组件时，如果其子组件的数据尚未准备好，React会渲染fallback内容，并将其作为HTML shell的一部分发送。
    • 同时，React会在fallback的位置插入特殊的HTML注释标记，例如<!--$?S:0-->和<!--/$-->，这些标记作为未来内容填充的占位符。
    • 服务器会继续尝试在后台加载Suspense边界内的数据。

  2. 数据加载完成：

    • 一旦Suspense边界内的数据在服务器上加载完毕，React会渲染该边界的真实内容。
    • React将这段真实内容的HTML，以及任何必要的客户端状态更新，包装在一个<script>标签内。
    • 这个<script>标签会作为流式响应的一个新块发送到客户端。

  3. 客户端处理：

    • 浏览器接收到这个包含脚本的HTML块。
    • 脚本执行，它会查找之前由服务器发送的占位符（例如<!--$?S:0-->）。
    • 脚本将占位符替换为真实的HTML内容。
    • 如果该组件使用了useState或其他需要初始值的React特性，脚本还会确保这些状态在客户端被正确地初始化，从而实现无缝的水合。

React的内部机制（简化）：

React在服务器端会生成一个内部的ID（如S:0），用于标识Suspense边界。当数据加载完成时，它会发送一个类似以下的片段：

<!-- Initial shell containing fallback -->
<div id="root">
  <p>Loading...</p>
  <!--$?S:0--> <!-- Start of Suspense boundary 0 -->
  <!--/$-->   <!-- End of Suspense boundary 0 -->
</div>

<!-- Later, when data for S:0 is ready, this chunk is streamed -->
<script>
  // 这段脚本是 React 内部生成的，用于更新客户端 DOM
  // 它会查找对应的 Suspense 边界，并替换其内容
  // 具体的实现可能会涉及一个全局的 React DOM 方法
  // 类似于 ReactDOM.__patchStreamingHtml('S:0', '<p>Product: Awesome Gadget</p>');
  // 同时，如果 Product 组件内部有 useState('initial value')
  // React 也会确保这个 initial value 被正确设置，或者通过一个更复杂的机制进行同步。
</script>
<template id="S:0">
  <!-- 真实的 HTML 内容被包装在 <template> 标签中，客户端 JS 会提取并插入 -->
  <p>Product: Awesome Gadget</p>
  <div>Price: $99</div>
</template>

请注意，React实际的实现比这复杂得多。它不会直接将HTML字符串放入script标签，而是使用template标签和ReactDOM.preinit / ReactDOM.preload / ReactDOM.render 的组合，以更高效和安全的方式进行DOM更新和资源预加载。template标签的内容不会立即被渲染，而是由客户端的JavaScript来激活。

5.3 Context 数据流

如果应用使用React Context，并且 Context Provider 的值依赖于异步数据，那么在Streaming SSR中也需要特别处理。

  • 初始 Context 值： 对于在shell中使用的Context，其初始值需要在水合脚本之前通过window.__REACT_CONTEXT_VALUE__或类似的机制进行序列化和注入。
  • 异步 Context 值： 如果Context Provider位于Suspense边界内，并且其值依赖于异步数据，那么当该Suspense边界解决时，React会发送一个额外的脚本块。这个脚本会更新客户端的Context Provider，确保所有消费该Context的子组件都能获取到最新的值，并触发重新渲染。

总结数据流策略：

数据类型 注入方式 注入位置 优先级 目的
初始全局数据 <script> 内联 <body> (水合前) 高 为客户端应用提供启动数据
Suspense数据 <script> (流式) <body> (动态注入) 中 随异步组件加载，填充数据
Context数据 <script> 内联/流式 <body> (水合前/动态) 中 确保客户端Context状态与服务器端一致

六、React 18 Streaming SSR的注入排序逻辑：一个综合视图

综合来看，React Streaming SSR的注入排序是一个高度动态和优先级驱动的过程。它不仅仅是简单的“先CSS后JS”的规则，而是围绕着用户体验指标（FCP, LCP, TTI）和异步数据流而精心设计的。

6.1 初始HTML Shell的构建与发送

当onShellReady回调触发时，服务器会发送第一个HTML块，包含：

  1. <!DOCTYPE html>和<html>标签。
  2. <head>内容：
    • <meta charset="utf-8">, <meta name="viewport">等基本元数据。
    • <title>标签。
    • 关键CSS： 内联的<style>标签，确保首屏内容无FOUC。
    • 非关键CSS： <link rel="stylesheet">标签，通常不阻塞渲染。
    • 主应用JS Bundle： <script src="/bundle.js" defer></script>。虽然在<head>中，但defer属性保证其执行不会阻塞HTML解析，且在DOM准备好后才执行。
  3. <body>内容的开始：
    • <body>标签。
    • <div id="root">等主要应用容器。
    • 非Suspense包裹的初始UI内容。
    • Suspense占位符： 对于那些数据尚未加载的Suspense组件，会发送其fallback内容，并附带特殊的React内部注释标记（如<!--$?S:0-->）。

此阶段的优先级： 确保最快的FCP，提供基本可用（但可能不完整或不可交互）的UI骨架。

6.2 异步内容与资源的流式注入

一旦初始shell发送完毕，服务器会继续在后台处理Suspense边界内的数据加载和组件渲染。当任何一个Suspense边界的数据就绪时，React会生成一个包含以下内容的新HTML块，并通过流发送：

  1. 替换占位符的脚本： 一个内联的<script>标签，其作用是在客户端执行后，找到之前发送的Suspense占位符（如<!--$?S:0-->），并将其替换为真实的HTML内容。
  2. 真实的HTML内容： 被替换到占位符位置的实际UI。为了优化，这部分HTML可能被包装在<template>标签中，由客户端脚本激活。
  3. 新的CSS： 如果这个异步解析的组件引入了新的样式（例如，来自CSS-in-JS库），这些样式可能会作为<style>标签的一部分，嵌入到这个流式块中，由客户端脚本将其插入到DOM中。
  4. 新的JavaScript模块： 如果该组件是按需加载的（React.lazy），那么对应的JS模块的<script>标签也会被注入到流中，指示浏览器下载和执行该模块。
  5. 新的数据： 如果该组件需要特定的客户端状态，这些数据也可能被序列化并包含在注入的脚本中，用于客户端水合。

此阶段的优先级： 逐步填充UI，提高LCP，并为用户提供部分或全部交互性。

6.3 最终的JavaScript执行与水合

在所有HTML内容（包括流式异步内容）到达并被浏览器解析后，或者在defer脚本能够执行的时候：

  1. 初始数据脚本执行： window.__INITIAL_DATA__等脚本被执行，为客户端应用提供初始状态。
  2. 主应用Bundle执行： bundle.js（由于defer属性）开始执行。
  3. 水合过程： ReactDOM.hydrateRoot开始将React组件树与服务器渲染的HTML关联起来，挂载事件监听器，并使页面变得完全可交互。
  4. 异步模块的客户端激活： 如果流式注入的<script>标签触发了新的JS模块下载，这些模块会在下载完成后执行，进一步增强页面的功能。

此阶段的优先级： 达到完全交互时间（TTI），提供完整、流畅的用户体验。

6.4 注入排序概览表

资源类型 典型注入位置 注入时机 目的/优先级 React Streaming SSR 特性
元数据 <head> Shell Ready SEO，浏览器行为设置 固定
关键CSS <head> (<style>) Shell Ready 防FOUC，最快FCP 开发者手动提取和内联
非关键CSS <head> (<link>) Shell Ready 正常样式，非阻塞加载 固定链接，可配合 preload
主JS (Hydration) <head> (<script defer>) Shell Ready 尽快下载，DOM就绪后执行，实现可交互性（TTI） defer 属性保证非阻塞，onShellReady 触发
初始数据 <body> (内联 <script>) Shell Ready 为水合提供初始状态，避免二次请求 开发者手动序列化
Suspense Fallback <body> (HTML + <!--$?S:N-->) Shell Ready 提供占位符，避免白屏，指示内容加载中 React 自动生成占位符
异步HTML内容 <body> (内联 <script> + <template>) Suspense Resolve 逐步填充内容，加速LCP，提升感知性能 React 自动生成并流式发送
异步CSS <body> (内联 <script> + <style>) Suspense Resolve 随异步组件加载，避免FOUC，样式按需加载 CSS-in-JS 库配合 React 内部机制
异步JS模块 <body> (内联 <script> + <script src>) Suspense Resolve 按需加载，代码分割，优化TTI React.lazy 和动态 import() 配合 React

这个表格清晰地展示了Streaming SSR中资源注入的动态性和分层优先级。

七、优化策略与最佳实践

理解了注入排序后，我们可以采取一些优化策略来进一步提升Streaming SSR应用的性能：

  1. 关键CSS提取与内联： 使用工具（如critters, mini-css-extract-plugin）自动化关键CSS的提取和内联过程。
  2. 代码分割 (Code Splitting)： 充分利用React.lazy和Suspense进行组件级别的代码分割，确保只有在需要时才加载对应的JavaScript和CSS。
  3. 资源预加载 (Preloading)： 对于确定会很快需要的资源，使用<link rel="preload">或<link rel="prefetch">进行预加载，加速后续的下载。
  4. 数据预取 (Data Pre-fetching)： 尽可能在服务器端提前获取数据，减少Suspense边界的等待时间。
  5. 合理设置Suspense边界： 将Suspense组件放置在数据加载耗时较长的组件外部，但又不要过于粗粒度，以免一次性阻塞太多内容。
  6. CDN部署： 利用内容分发网络（CDN）分发静态资源（CSS、JS bundles），减少网络延迟。
  7. HTTP/2 或 HTTP/3： 现代协议可以更好地处理多路复用，使得同时传输多个资源流更加高效。

八、文末

React Streaming SSR通过其精妙的HTML、CSS、JS及数据流注入排序机制，成功地将Web应用的初始加载体验推向了一个新的高度。它将传统的“一次性交付”转变为“逐步增强”的范式，让用户能够更快地看到内容、更快地进行交互。理解并掌握这些注入策略，是构建高性能、用户友好型React应用的关键。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注