完整水合的问题

水合是指 React 接收服务器渲染的 HTML，并为其附加 JavaScript 事件监听器的过程。服务器先发送初始 HTML（速度很快），然后浏览器下载 JavaScript 代码包，React 再对静态 HTML 进行“水合”，使其具备交互能力。在水合完成之前，页面看起来像是可以交互的，实际上却无法交互。

传统单页应用会将整个 JavaScript 代码包发送到浏览器。React 必须下载、解析并执行它，然后为组件树中的每个组件附加事件监听器。对于大型应用，这个过程在中端移动设备上可能需要数秒。

可交互时间表示用户需要等待多久才能与页面交互。水合会直接阻塞 TTI：页面可能看起来已经准备就绪（服务器渲染的 HTML 已经可见），但按钮和表单要等到 React 完成事件监听器的附加后才会响应。较高的 TTI 数值意味着糟糕的用户体验。

以一个营销页面为例：页面中 80% 的内容是不会变化的静态文本、图片和标题，只有 20% 涉及新闻订阅表单或视频播放器之类的交互式组件。传统 SPA 的水合仍然会处理整个页面，也就不必要地处理了静态组件。

Chrome DevTools 的性能分析可以揭示水合成本。在主线程瀑布图中，您可以将“React 水合”任务识别为首次绘制后的一段较长 JavaScript 执行区块。这段区块越长，主线程被占用的时间就越多，页面的响应能力也越差。

React 组件树越大，水合所需的工作就越多。React 必须访问每个组件，将服务器渲染的 HTML 与组件实际会渲染的内容进行比较，并附加事件监听器。即使设备运行速度很快，包含数百个组件的复杂页面也可能产生可测量的水合开销。

React 18 引入了并发水合，使 React 可以将水合拆分为更小的区块，并在区块之间将执行权交还给浏览器。这样可以避免大型组件树水合期间浏览器看起来完全卡住。不过，并发水合只能降低影响，并不能消除这一根本成本。

选择性水合（通过 Suspense）允许 React 按优先级顺序为组件进行水合：用户交互会触发相关组件立即进行水合。这可以改善响应能力，但仍然运行在同一个 React 树中：树中的所有组件最终都会完成水合。

岛屿架构背后的根本洞察是：典型页面中的大部分内容根本不需要 JavaScript。导航栏、主视觉区域、页脚链接、博客文章文本和产品描述都只是用于呈现内容。强制让这些内容参与水合，从定义上来说就是浪费。

网页性能团队的研究表明，在移动设备上，JavaScript 的解析和执行时间是主要成本。一个 300kb 的 JavaScript 代码包在普通 Android 手机上需要 2 至 3 秒才能完成解析。与任何 React 内部优化相比，减少发送到浏览器的 JavaScript 能带来大得多的性能收益。

React 应用每增加一千字节的 JavaScript，就会增加水合工作量。即使某个组件只是装饰性的，只要它位于 React 树中，就会参与水合。这种“水合税”会随着应用规模扩大而增加，使应用越大，越难维持良好的 TTI 数值。

React 水合与可交互时间（TTI）之间是什么关系？

传统 React 水合会处理整个组件树，包括不需要任何 JavaScript 的静态内容。这会阻塞可交互时间，并且随着应用规模扩大而表现不佳。React 18 的并发水合和选择性水合改进可以降低影响，但无法消除这一根本成本。根本洞察是：大多数页面内容根本不需要 JavaScript，因此完整水合是一种浪费。