Next.js: 流渲染以减少 TTFB 和 CPU 负载

有一件事要提..

流渲染通常不会增加太多 CPU 改进，因为要完成的工作量是相同的。 但它会减少响应时间。

提供一种自定义 SSR 渲染系统的方法是一个不错的主意。 但我认为现在，我们将默认使用 React 的 renderToString() 方法。

这是我们在 2.0 之后可以做的事情。

流渲染通常不会增加太多 CPU 改进，因为要完成的工作量是相同的。

_来自aickin/react-dom-stream _

对 ReactDOM.renderToString 的一次调用可以控制 CPU 并使其他请求挨饿。 这在同时提供小页面和大页面的服务器上尤其麻烦。

通过异步和部分流式传输不会显着减少大页面的内存分配和 CPU 使用率吗？

认为这是沿着相同的路线。 有人试过https://github.com/FormidableLabs/rapscallion吗？

它提供了一个流接口，以便您可以立即开始向客户端发送内容。

文档中的其他功能：

• 渲染是异步和非阻塞的。
• Rapscallion 比 renderToString 快大约 50%。
• 它提供了一个流接口，以便您可以立即开始向客户端发送内容。
• 它提供了模板功能，因此您可以将组件的 HTML 包装在样板中，而不会放弃流式传输的好处。
• 它提供了一个组件缓存 API 来进一步加速渲染。

在#2279 中添加了 Rapscallion 的示例...可以确认 Rapscallion + Next 是疯了。 基于流式/promise 的渲染很棒，但组件级缓存对我们来说是一个游戏规则改变者... :godmode:

现在 React 16 有了自己的renderToNodeStream ，next.js 添加一个选项来使用它而不是renderToString将是一个巨大的优势。 你怎么看，@timneutkens？

它已经在我们要添加的东西清单上了👍

有这方面的消息吗？

https://github.com/zeit/next.js/pull/4074#issuecomment -466996162

任何新闻？

Next.js 需要公开自定义render （以renderToString作为默认渲染器），以便用户使用我认为的自定义异步渲染器。
缺乏这个功能迫使我使用razzle来使用异步渲染器 :( （它的 DX 远不及 NextJS，但我不得不接受它继续）。

我喜欢 Next.js 的一切，除了两件事：

• 自定义异步渲染器。
• 服务器和客户端的自定义 babel 配置。

任何支持流式渲染的路线图/计划？ 所以期望在 next.js 中有这个。

正在等待 React 团队实施 React Fizz / 他们的计划。

@timneutkens 有什么问题，公关要在这里跟踪吗？

来自 Facebook 的博客文章，发表于 2019 年 8 月 8 日
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

服务器渲染更新
我们已经开始了新的具有 Suspense 功能的服务器渲染器的工作，但我们不希望它为并发模式的初始版本做好准备。 但是，此版本将提供一个临时解决方案，让现有的服务器渲染器立即为 Suspense 回退生成 HTML，然后在客户端上渲染它们的真实内容。 这是我们目前在 Facebook 自己使用的解决方案，直到流式渲染器准备就绪。

对于仍在等待服务器流媒体支持的任何人:)

在 next.js 中是否有任何更新或任何其他方法来实现 renderToNodeStream ？

有更新吗？

<3

任何更新？

@StarpTech我对此进行了一些研究（对这个功能也很好奇！），看起来react-flight 的东西，这可能是我们在这里等待的流媒体解决方案的基础:)

反应飞行：

这是一个用于使用自定义 React 流模型的实验包。

相关 PR 对内部运作有所启发，由我解释（不是这方面的任何专家 🙈 ）
#17285 ：用于飞行的基本 api，服务器应该能够将所有内容作为字符串进行流式传输，但为在服务器上异步解析的块保留占位符。 一个关于 react 如何从流中知道它实际代表什么数据类型的不完整但有趣的语法就在这里。

#17398最近的 PR，为 Chunks 添加了一个 api，所以（如果你很幸运）你可以自己尝试一下。 不知道一切会如何结合在一起，但我很高兴看到所有这些工作都完成了:)

_这可能有点跑题，但希望订阅这个问题的人很有趣:)_

@pepf感谢您提供的信息！

嗯。 谢谢大家，有趣的信息。 我只是在想，为什么 NextJS 应该等待 React 支持 SSR 的悬念之类的东西，而不是现在只使用 streamAsString？

@arunoda我认为它会减少内存消耗，这对于低内存 lambda 函数或 Cloudflare Workers 非常重要。

有这方面的消息吗？

任何新闻？

大家有消息了吗？ :P

鉴于反应悬念感觉它可能永远不会出现，我们有什么办法可以重新审视它吗？ 我看到在相当通用的低内容页面（从 vercel 上的无服务器功能呈现）上的初始呈现时间为 800-1000 毫秒。 理论上，流式传输 HTML 可以提升最初的接触点，并导致更快的感知首次加载用户体验。

这是 Vercel 而不是 NextJS 的限制吗？ Vercel 是否会成为与 Lambda 相同的冷启动的受害者？ 我的团队运行着一堆内容繁重的网站，整个请求的时间在 50 毫秒以下。 我不认为流媒体在这里会成为灵丹妙药。

我不认为它是灵丹妙药，但它肯定会是一个受欢迎的改进。

与提到的冷启动时间相比，50 毫秒听起来微不足道，而且相对来说太微不足道，无法优化，但在使用 Cloudflare Workers 之类的东西在边缘渲染时却不是这样（它与对最近的 Cloudflare 边缘位置的 ping 一样多，或者至少一半)，Cloudflare Workers 在冷启动时响应非常快，通常在 5 毫秒以内。 相比之下，Lambda 和Lambda@Edge函数都可以从冷启动开始响应一秒钟。
我知道这对于 Varcel（它构建自己的 cdn）雇用 next.js 的开发人员来优先考虑这并没有更好的理由。

是否有任何文档或存储库可以让人们成功地将 next.js 部署到 cloudflare 工作人员？ 我做了一些谷歌搜索，找不到太多关于它的信息。 这将是惊人的。

从我的手机发送

2020 年 7 月 5 日下午 5:47，Wis [email protected]写道：

与提到的冷启动时间相比，50 毫秒听起来确实很低，而且对于优化而言相对微不足道，但是在使用 Cloudflare Workers 之类的东西在边缘渲染时，50 毫秒已经很多了（它与对最近的 Cloudflare 边缘位置的 ping 一样多，或者至少半），Cloudflare Workers 响应非常快，通常在 5 毫秒内，冷启动时。 相比之下，Lambda 和Lambda@Edge函数都可以从冷启动开始响应一秒钟。
我知道这对于 Varcel（它构建自己的 cdn）雇用 next.js 的开发人员来优先考虑这并没有更好的理由。

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看，或取消订阅。

与提到的冷启动时间相比，50ms 听起来微不足道，而且相对而言微不足道，无法优化

澄清一下，我并不是在抱怨我的 50 毫秒响应时间——我只是指出 NextJS 的 SRR 即使在 3k 请求/分钟以北的内容丰富的页面上也具有相对的性能，因此 Switz 的问题可能存在于其他地方。

是否有任何文档或存储库可以让人们成功地将 next.js 部署到 cloudflare 工作人员

我也会对此感兴趣。 我们目前正在 Fargate 中运行，但将我们的应用程序推向边缘将是下一个合乎逻辑的步骤。

我已经在我的 HTML 中进行了所有可能的改进，并且服务器响应时间非常快！ :(

@huggler您可以将此示例与cacheable-response结合使用。 您可以使用 Redis（或例如内存缓存）将 html 存储在缓存中。 它提高了服务器响应时间。

是否有任何文档或存储库可以让人们成功地将 next.js 部署到 cloudflare 工作人员？ 我做了一些谷歌搜索，找不到太多关于它的信息。 这将是惊人的。

@switz @tills13你检查过https://fab.dev/吗？ 我们在 2020 年初玩过它，它处于预发布状态，但它们似乎已经走了很远。 支持它们的限制之一是 Cloudflare 本身，但现在情况可能已经发生了变化。

好久没看不得不重新评价。 上次我查看时，有一些非常严重的权衡。

我也在关注https://github.com/flareact/flareact。

这事有进一步更新吗？