React 性能优化

React SSR 应用如何优化 hydration 性能和一致性？

SSR 只解决 HTML 到达和内容展示的一部分问题，hydration 仍可能成为交互就绪的主要成本。

适合阶段：高级前端 / React 全栈核心能力：SSR · Hydration · 一致性

面试官想考什么

• SSR 页面为什么仍然交互慢？ 考察 hydration 成本。
• hydration mismatch 如何产生？ 考察服务端/客户端一致性。
• 如何减少客户端 JS？ 考察组件边界和代码分割。
• 流式渲染如何和交互配合？ 考察现代渲染策略。

一句话回答

优化 hydration 要减少需要客户端接管的组件和 JS，保证首次服务端与客户端输出确定一致，并通过分割和渐进交互缩短可操作时间。

面试回答详解

1. SSR 和 hydration 的关系

服务端生成 HTML -> 浏览器展示
-> 下载 JS -> React 匹配树并绑定事件 -> 交互就绪

HTML 可见不代表组件已可交互；大客户端树、第三方库和复杂初始化会延长 hydration。

2. 优化方向

• 缩小 Client Component 边界。
• 只让交互岛加载客户端代码。
• 按路由和交互做代码分割。
• 延迟非关键组件和第三方脚本。
• 使用流式和 Suspense 让关键内容先到达。

3. 一致性

服务端和客户端首次输出不能依赖当前时间、随机数、浏览器 API、不同 locale 或不稳定数据。非确定性逻辑移到客户端 effect 或服务端统一生成。

4. 验证

关注 TTFB、LCP、hydration/JS 执行时间、INP、错误率和 mismatch 日志。不要用“HTML 出来了”作为完成标准。

可直接背诵的 30 秒回答

SSR 只让 HTML 更早到达，hydration 仍需要下载和执行客户端 JS。我的优化顺序是缩小客户端组件边界、代码分割、延迟非关键交互和第三方脚本，并用流式和 Suspense 优先展示关键内容。同时保证服务端和客户端首次输出在时间、随机数、locale 和数据上确定一致，最后用 TTFB、LCP、INP 和 hydration 时间验证。

扩展知识

SSR 性能指标

TTFB -> HTML/LCP -> JS 下载执行 -> hydration
-> INP -> 业务交互完成

面试官追问链

追问一：hydration mismatch 会影响性能吗？

• 考察点：是否理解错误恢复。
• 回答方向：会增加客户端修复、告警和不确定行为，甚至导致局部重建；应修复首次输出不一致，而不是只隐藏警告。

追问二：客户端组件越少越好吗？

• 考察点：是否会做平衡。
• 回答方向：要保留必要交互；过度服务端化会增加边界通信和交互复杂度，目标是最小但合理的客户端边界。

追问三：如何定位 hydration 慢？

• 考察点：工具使用。
• 回答方向：看 JS 下载、parse/compile、执行、React Profiler、Performance Long Task 和组件树，按 release 和设备分组。

推荐阅读

• React Server Components
• React Streaming Server Rendering
• web.dev Hydration
• React 性能优化