Next.js: TTFBとCPUの負荷を軽減するためのストリームレンダリング

言及する1つのこと..

実行する作業量は同じであるため、ストリームレンダリングでは、通常、CPUの改善はそれほど多くありません。 ただし、応答時間は短縮されます。

SSRレンダリングシステムをカスタマイズする方法を提供することはかなり良い考えです。 しかし、今のところ、デフォルトではReactのrenderToString（）メソッドを使用すると思います。

これは、2.0以降にできることです。

実行する作業量は同じであるため、ストリームレンダリングでは、通常、CPUの改善はそれほど多くありません。

_aickin / react-dom-streamから_

ReactDOM.renderToStringへの1回の呼び出しは、CPUを支配し、他の要求を枯渇させる可能性があります。 これは、小さいページと大きいページが混在するサーバーで特に厄介です。

ストリーミングは、非同期と部分的な両方を行うことで、大きなページのメモリ割り当てとCPU使用率を大幅に削減しませんか？

これは同じ線に沿っていると思いました。 誰かがhttps://github.com/FormidableLabs/rapscallionを試しましたか？

ストリーミングインターフェイスを提供するため、クライアントへのコンテンツの送信をすぐに開始できます。

ドキュメントの他の機能：

• レンダリングは非同期で非ブロッキングです。
• Rapscallionは、renderToStringよりも約50％高速です。
• ストリーミングインターフェイスを提供するため、クライアントへのコンテンツの送信をすぐに開始できます。
• テンプレート機能を提供するため、ストリーミングのメリットを放棄することなく、コンポーネントのHTMLを定型文でラップできます。
• レンダリングをさらに高速化するためのコンポーネントキャッシングAPIを提供します。

＃2279にRapscallionの例を追加しました... Rapscallion + Nextが非常識であることを確認できます。 ストリーミング/プロミスベースのレンダリングは素晴らしいですが、コンポーネントレベルのキャッシングは私たちにとってゲームチェンジャーです...：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のすべてが大好きですが、次の2つがあります。

• カスタム非同期レンダラー。
• サーバーとクライアントの両方のカスタムbabel構成。

ストリーミングレンダリングサポートのロードマップ/計画はありますか？ したがって、next.jsにこれがあると予想されます。

ReactFizzを実装するReactチーム/その計画は保留中です。

@timneutkens何の問題、ここで追跡するPR？

2019年8月8日に公開されたFacebookのブログ投稿から
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

サーバーレンダリングに関する最新情報
新しいサスペンス対応サーバーレンダラーの作業を開始しましたが、並行モードの初期リリースの準備ができているとは期待していません。 ただし、このリリースでは、既存のサーバーレンダラーがサスペンスフォールバック用のHTMLをすぐに発行し、クライアントで実際のコンテンツをレンダリングできるようにする一時的なソリューションを提供します。 これは、ストリーミングレンダラーの準備が整うまでFacebookで現在使用しているソリューションです。

サーバーストリーミングのサポートをまだ待っている人のために:)

next.jsにrenderToNodeStreamを実装するための更新やその他の方法はありますか？

更新はありますか？

<3

すべてのアップデート？

@StarpTech私はこれを少し調べました（この機能にも興味があります！）そして、reactチームはreact-flightと呼ばれるものに取り組んでいるようです。これはおそらく私たちがここで待っているストリーミングソリューションのベースになるでしょう:)

反応飛行：

これは、カスタムReactストリーミングモデルを使用するための実験的なパッケージです。

私が解釈した、内部の仕組みに光を当てる関連するPR（このいずれの専門家でもありません🙈）
＃17285 ：フライトの基本API。サーバーはすべてを文字列としてストリーミングできる必要がありますが、サーバー上で非同期的に解決されるチャンクのプレースホルダーは残しておきます。 ストリームからreactが実際に表すデータ型を知る方法についての不完全ですが興味深い構文は、ここにあります。

＃17398最近のPRでは、チャンク用のAPIが追加されているため、（運が良ければ）その部分を自分で試すことができます。 すべてがどのようにまとめられるかはわかりませんが、それでも、このすべての作業が行われているのを見るのはちょっと嬉しいです:)

_これは少し話題から外れているかもしれませんが、この問題を購読している人々にとってうまくいけば興味深いです：）_

@pepf情報をありがとう！

うーん。 みんなありがとう、面白い情報。 NextJSが、streamAsStringを使用するだけでなく、ReactがサスペンスなどのSSRをサポートするのを待つ必要があるのはなぜだろうと考えています。

@arunodaこれにより、メモリ消費量が削減されると思います。これは、低メモリのラムダ関数やCloudflareワーカーにとって非常に重要です。

これについて何かニュースはありますか？

連絡あった？

ニュースの人はいますか？ ：P

反応サスペンスは決して出てこないかもしれないと感じているので、これを再考する方法はありますか？ かなり一般的なコンテンツの少ないページ（vercelのサーバーレス関数からレンダリングされる）で800〜1000ミリ秒の初期レンダリング時間が表示されます。 理論的には、HTMLをストリーミングすると、最初の連絡先が増え、最初の読み込みのUXがはるかに速く認識される可能性があります。

それはNextJSではなくVercelの制限ですか？ VercelはLambdaと同じ種類のコールドスタートアップの犠牲になりますか？ 私のチームは大量のコンテンツの多いサイトを運営しており、リクエスト全体のタイミングは50ミリ秒未満です。 ここでは、ストリーミングが特効薬になるとは思いません。

特効薬になるとは思いませんが、確かに歓迎すべき改善です。

50msはごくわずかに聞こえ、前述のコールドスタート時間と比較して最適化するには比較的重要ではありませんが、Cloudflareワーカーのようなエッジでレンダリングする場合はそうではありません（最も近いCloudflareエッジの場所へのpingと同じか、少なくとも半分です）、Cloudflareワーカーは、コールドスタート時に、通常5ミリ秒未満で非常に迅速に応答します。 対照的に、Lambda関数とLambda @ Edge関数はどちらも、コールドスタートから応答するのに1秒以上かかる場合があります。
これは、next.jsの開発者がこれを優先するために採用したVarcel（独自のcdnを構築する）にとってより良いケースにはならないことを私は知っています。

人々がnext.jsをcloudflareワーカーに正常にデプロイしたドキュメントやリポジトリはありますか？ グーグルをしてみましたが、あまり見つかりませんでした。 それは素晴らしいでしょう。

私の電話から送信されました

2020年7月5日には、17:47で、ウィスコンシン州[email protected]書きました：

。
50msは非常に低く、前述のコールドスタート時間と比較して最適化するのは比較的重要ではありませんが、Cloudflareワーカーのようなエッジでレンダリングする場合は50msが多くなります（最も近いCloudflareエッジの場所へのpingと同じか、少なくとも半分）、Cloudflareワーカーは、コールドスタート時に、通常5ミリ秒未満で非常に迅速に応答します。 対照的に、Lambda関数とLambda @ Edge関数はどちらも、コールドスタートから応答するのに1秒以上かかる場合があります。
これは、next.jsの開発者がこれを優先するために採用したVarcel（独自のcdnを構築する）にとってより良いケースにはならないことを私は知っています。

—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、登録を解除してください。

50msはごくわずかに聞こえ、前述のコールドスタート時間と比較して最適化するには比較的重要ではありません

明確にするために、私は50ミリ秒の応答時間について不平を言っていませんでした-NextJSのSRRは、コンテンツの多いページに対して1分あたり3kリクエストの北でも比較的パフォーマンスが高いため、Switzの問題は他の場所にある可能性があることを指摘しました。

人々がnext.jsをcloudflareワーカーに正常にデプロイしたドキュメントやリポジトリはありますか？

私もそれに興味があります。 現在Fargateで実行していますが、アプリをエッジにプッシュすることが次の論理的なステップになります。

HTML内で可能な限りの改善を行いましたが、サーバーの応答時間は非常に長くなっています。 :(

@hugglerこの例をcacheable-responseと組み合わせることができます。 Redis（またはメモリ内キャッシュなど）を使用して、htmlをキャッシュに保存できます。 サーバーの応答時間を改善します。

人々がnext.jsをcloudflareワーカーに正常にデプロイしたドキュメントやリポジトリはありますか？ グーグルをしてみましたが、あまり見つかりませんでした。 それは素晴らしいでしょう。

@switz @ tills13 https://fab.dev/をチェックしましたか？ 2020年初頭に試してみましたが、プレリリース状態でしたが、かなり遠いところに来ているようです。 それらを取り戻す制限の1つはCloudflare自体でしたが、状況は今では変わっている可能性があります。

しばらく見ていない。 再評価する必要があります。 前回見たとき、かなり深刻なトレードオフがありました。

https://github.com/flareact/flareactにも注目してい

これに関する更新はありますか？