为什么选择 Pareto#

在我的工作中，经常困扰我的一个问题是：我们的团队不使用像 next.js 或 remix 这样的框架。相反，我们有自己用 webpack+react SSR 构建的应用程序。对于这些应用程序，集成 React 的流式渲染非常具有挑战性。我认为第一个问题在于 React 官方团队，因为他们没有明确的最佳实践来实现流式渲染。第二点是，在增强 SSR 应用程序时使用流式渲染，处理样式和资源，以及同步潜在的服务器端全局存储和客户端全局存储，确实非常复杂。

我为什么认为流式渲染很重要#

因为它是一个可以带来更好用户体验的改变者。

流式渲染可以显著减少您的 TTFB（首字节时间）、FCP（首次内容绘制）和 TTI（首次可交互时间）。这是如何实现的呢？让我们重新阅读一下这篇文章：https://github.com/reactwg/react-18/discussions/37。

首先，因为我们启用了流式渲染，我们可以在请求到达时立即发送页面所需的静态资源，如 js、css、图片、字体。因此，浏览器可以在您的服务器仍在进行 API 调用时预加载这些资源。我们将静态资源与后端 API 调用解耦，将我们的 TTFB 减少到单个往返时间（RTT）。

其次，对于那些响应时间较长的 API，我们不再需要等待它们完成后再返回页面内容。相反，我们可以首先从响应更快的 API 返回内容，同时发送一个骨架。当较慢的 API 返回时，我们用实际内容替换骨架。这种方法打破了瓶颈效应，显著改善了 FCP。

我们借用了 eBay 文章中的两幅图来更直观地说明这一点。

没有流式渲染#

有流式渲染#