PRNext 0.1.18 対 Next.js: CPU、RAM、およびスリープ

#一目でわかる結果

2 つの CPU と 1 GiB を使用すると、候補者は 100-row SSR ページで 142.97 と比較して 1 秒あたり 224.70 応答に達し、約 57% 高いスループットになります。同じ予算の 1,000-row ページでは、Next.js がリードしています。両方の VPS マシンで Next.js を使用すると、水分補給の測定も高速化されます。

小規模な VPS では、通常の SSR CPU のコストは約 37% 下がりますが、PRNext はより多くのメモリを使用します。ワーカーがスリープすると、目覚めが遅くなる代わりに RAM が解放されます。次のセクションでは、各シナリオのバージョン、測定値、制限事項について説明します。

CPU の予算、メモリ、シナリオごとに測定値を調べる

#数字の背後にある正確なバージョン

10 月の 29, 2026 の測定では、コミット 2856155. で 0.1.18-alpha 開発候補が使用されています。そのマニフェストには依然として内部バージョン 0.1.17-alpha が含まれていますが、そのコードと最適化は npm 0.1.17-alpha パッケージとは異なります。正確に測定されたソース ハッシュとアーティファクト ハッシュは、この記事の最後にリンクされています。

参照は、同じ React 19.3.1 ファミリとアプリケーション ソースを使用する Next.js 16.4.3, です。小規模 VPS は Node.js 22.23.4 を実行します。大きなマシンでは Node.js 24.22.1. が実行されます。各マシン内では、すべてのエンジンがまったく同じノード実行可能ファイルを使用します。ノードも変更されるため、マシン間の違いはハードウェアのみに起因するものではありません。

PRNext は、Balanced プロファイルとそのデフォルトの Web レンダラーを実行します。関連データには、完全な Linux バイナリと候補パッケージのハッシュ、修正前の結果、およびスループット範囲が含まれます。 10 月 30 に公開された npm 0.1.18-alpha リリースは、コミット 05a9ccd から来ており、追加のビルドおよび開発修正が含まれています。したがって、このキャンペーンでは、npm 0.1.17-alpha パッケージも最終的な 0.1.18-alpha アーカイブも測定されません。数値は、その後の変更に新しいベンチマークを割り当てることなく、特定された候補を表します。

#測定した内容

最初の VPS には 1 つの vCPU と約 1.9 GiB または RAM があります。 2 番目には 8 つの vCPU と約 23 GiB があります。ターゲット プロセスは、スワップなしで cgroup v2 CPU とメモリ制限を受け取ります。小型マシンは CPU と 700 MiB のうち 1 つの 70% に限定されます。大型マシンは 1 つの CPU と 384 MiB、2 つの CPU と 1 GiB、次に 4 つの CPU と 2 GiB でテストされます。

メイン マトリックスには、96 ウィンドウ (4 つの予算、4 つのシナリオ、3 つのバリアント、および 2 つの交互パス) が含まれています。バリアントは、修正前の PRNext、測定された PRNext 候補、および Next.js です。各ウィンドウには 5 秒間のウォームアップがあり、その後 16 個の接続と gzip を使用して 15 秒間測定されます。表では、候補と Next.js を比較し、各メトリックの 2 つのウィンドウの中央値を報告します。

シナリオは、動的な 100-row SSR ページ、1,000-row ページ、16 エントリの JSON API、および 40 ms サスペンス遅延のあるページです。新しい識別子と Cookie により、応答の正確性と分離性がチェックされます。スループットは、成功した検証済みの応答のみをカウントします。これは、CDN から提供される静的ページの比較ではありません。

p95 は、リクエストの 95% がウィンドウ内で終了するまでの期間です。 CPU は、遅延ではなく、成功した応答ごとの CPU 作業のミリ秒です。 RAM は、ネイティブ エンジンとノード ワーカーを含むターゲット プロセス ツリー全体の比例セット サイズ (PSS) の中央値です。応答には 100 ms かかる場合がありますが、CPU は数ミリ秒しか使用しません。

ロード ジェネレーターには個別の制限がありますが、小規模 VPS の単一の物理 CPU を共有します。高速 API シナリオは、特に小型マシンや 4 つの CPU シナリオでは上限に達する可能性があります。既存のサービスはアクティブなままです。クォータによってこれらの VPS 上の競合が解消されるわけではありません。 2 つの短いパスでは信頼区間は得られません。小さな違いがマーケティング上の約束になってはいけません。

#小規模 VPS: CPU が少なく、一般的な RAM の勝利はなし

0.7 CPU および 700 MiB では、PRNext は Next.js の 51. に対して 1 秒あたり 81.33 SSR の応答を提供します。その p95 は 420.90 ms に対する 264.25 ms です。 CPU のコストは応答あたり 13.39 から 8.46 ms に減少し、約 37% 減少します。ただし、メモリは 101.38 MiB に対して 113.88 MiB です。このページでは、PRNext が約 12% を使用します。

ストリーミングは、80.03, に対して 1 秒あたり 138.13 リクエストに達し、応答あたり 42% 少ない CPU になります。重いページは、1 秒あたりのリクエスト数が 10.33 であるのに対して 11.33 で、はるかに近いです。このキャンペーンでは API が PRNext に有利ですが、同じ物理的な CPU に対するジェネレーターの競合が依然として制限となっています。

このマシン上の 4 つのシナリオすべてで、PRNext は Next.js よりも多くの PSS を使用します。観察された利点は主に、通常の SSR およびストリーミングでの CPU の効率です。 RAM が低いという包括的な主張は、これらの結果を誤って伝えることになります。

#1 つの CPU と 384 MiB: 異なる制約とトレードオフ

1 つの CPU と 384 MiB に制限された大規模な VPS では、SSR ページは 59.90. に対して 1 秒あたり 99.77 リクエストに達します。CPU のコストは約 41% 低く、PSS は約 13% 低くなります。ストリーミングは、1 秒あたり 86.27 リクエストに対して 220.90 に達し、応答あたり 11.47 ms または CPU に対して 4.51 を使用します。

候補者のより厳しいメモリ ポリシーにより、以前の PRNext コードと比較して RAM も減少しますが、API はその以前のコードに対して約 13% のスループットを失います。この測定では、PRNext が依然として Next.js をリードしています。それは内部回帰を消去するものではありません。ガベージ コレクションとスループットのバランスを保つには、さらなる作業が必要です。

#2 つの CPU: 明確な SSR ゲインと重いレンダリング制限

2 つの CPU と 1 GiB を使用すると、100-row SSR ページは、Next.js の 142.97 に対して、PRNext では 1 秒あたり 224.70 リクエストに達します。つまり、スループットが 57% 増加し、応答あたりのスループットが 26% 減少し、CPU 減少し、PSS が 32% 減少します。 p95 は 154.60 ms に対する 89.80 ms です。

1,000-row ページでは、結果が逆転します。Next.js は、PRNext の 24, に対して、740.80 ms に対して 622.20 ms の p95 で、1 秒あたり 27.63 リクエストに達します。 PRNext は、応答ごとに RAM を少なくしますが、約 29% 多くの CPU を使用します。重い React レンダリングは依然として具体的な改善目標です。

ストリーミングでは、応答ごとに約 56% 多いスループットが維持され、約 30% 少ない CPU が減ります。これらの結果は、すべての React プロジェクトではなく、この動的なアプリケーション、プロファイル、予算に適用されます。

#4 つの CPU: トポロジーも重要

4 つの CPU と 2 GiB では、PRNext は 2 つのワーカーを使用します。 Next.js は、プライベート ノード プロキシの背後で 2 つのプロセスを使用します。そのプロセスには、CPU と RAM が含まれます。他の 3 つの予算では、直接サーバーを使用します。このトポロジの違いは結果の一部です。

この Next.js 参照について、PRNext は 247.13 に対して 1 秒あたり 383.30 SSR リクエストに達します。その PSS は 458.33 MiB に対する 206.60 MiB です。これでは、普遍的な 55% RAM 保存が確立されません。別のトポロジまたはプロキシでは結果が変わる可能性があります。 API は発電機の天井に届くこともあります。

この予算では、候補者は以前の PRNext コードと比較して、SSR スループットの約 10% を失い、重いページでは約 6% を失います。 CPU を増やしても、すべてのパスが改善されるとは限りません。ワーカー全体のスケーリングと高負荷のレンダリング割り当てにはまだ作業が必要です。

#ナビゲーション: 独自の回帰を修正する

最初の監査では、大きなページへの復帰が異常に遅いことが判明しました。ディファレンシャル・フライト輸送により、非常に多くの小さな破片が生成されました。候補境界の比較が機能し、利用可能なデータがグループ化され、差異に価値がない場合は完全な応答フォールバックが保持されます。目的は、将来のストリーミング チャンクを待たずに作業を削減することです。

Chromium 153, では、ラージ ページ、スモール ページ、ラージ ページに戻るという作業を繰り返しました。各行程では、3,000 の表示セル、カウンタの状態、およびドキュメントの ID がチェックされます。小規模な VPS では、PRNext のリターンは 1,475.6 から 307.2 ms に低下します。大きいものでは、932.1 から 228.6 ms までです。

およそ 4 倍から 5 倍のゲインは、Next.js ではなく、以前の PRNext コードに対するものです。候補者は、小規模 VPS でのこの行程では Next.js よりもわずかに遅れて残り、大規模 VPS では先に進みます。バリアントごとに 8 つのコンテキストがトンネルを介して PC 上で実行されます。これらは訪問者が収集した Core Web Vitals ではありません。

水分補給でも同様の改善は見られません。その中央値は、小規模 VPS では PRNext に対する 421.6 ms、Next.js に対する 349.8 ms、大規模 VPS では 399.2 に対する 299.1 ms です。転送バイト数を減らすだけでは、クライアントをより早くインタラクティブにするのに十分ではありません。

#スリープ モード: 訪問の合間に RAM を解放します

トラフィックの少ないサイトでは、一日中プロセッサーが飽和状態になることはありません。アイドル状態のメモリは、ピーク スループットよりも重要な場合があります。 PRNext は、Rust サーバーをリッスンし続けながら、アイドル期間の経過後にノード ワーカーをリタイヤさせることができます。次のレンダリング リクエストでは、必要なワーカーが再作成されます。

このメカニズムを、単純な SSR ページと加速された 2 秒のアイドルしきい値を使用して小規模 VPS でテストしました。従業員が退職した後に記憶が観察されますが、これには約 2 秒かかりました。保温コントロールは約 6 秒待ちます。これは、負荷テストや耐久テストとは別に、設定ごとに 1 つの機能プローブです。

このプローブでは、PSS は、保温時の 106.8 MiB に対して、従業員の退職後は約 10.5 MiB に低下します。コストはスリープ解除リクエストに表示されます: 22.6 ms に対して約 1.13 秒。 10.5 MiB 図は、VPS 全体やすべてのアプリケーションではなく、その状態でのこの単純なアプリケーションのプロセス ツリーを示しています。

--prewarm による起動プレウォーミングは、リクエストを受け入れる前にフレームワークを初期化します。その後のアイドル状態のリタイアメントは妨げられず、アプリケーション ページや API ハンドラーは呼び出されません。使用されているレンダー ホストを保持するには、明示的な設定は --worker-idle-seconds 0. です。したがって、プレウォーミングだけでは、スリープ後の復帰のコストは排除されません。

このプローブでは、同等の Next.js スリープ構成はテストされませんでした。外部インフラストラクチャが Next.js を停止または再起動できないということは確立されていません。

#共有ホスティングの間接的なメリット

異なる時間に訪問したいくつかの小規模プロジェクトの場合、非アクティブなワーカーのメモリを解放すると、アクティブなアプリケーションのためにより多くのスペースを残すことができます。 CPU の効率が向上すると、同じクォータ内でより有用な作業を残すことができます。これは、小規模な公開サイト、デモ、断続的な内部ツールに関係する可能性があります。

これは測定結果からの推論であり、ホスティング密度のベンチマークではありません。追加のプロジェクトがどれだけサーバーに収まるか、請求額やエネルギー節約量を測定したのかは不明です。オペレーティング システム、データベース、ゲートウェイ、同時バーストおよびウェイクアップもリソースを消費します。

このフレームワークには、アプリケーション全体をゲートウェイの背後でスリープ状態にできるローカル prnext host コマンドもあります。これは、ここで測定される労働者の退職とは別のものです。ゲートウェイはアクティブなままです。追跡されたリクエストと接続により進行中の作業が保護され、後でアクセスするとアプリケーションが起動される可能性があります。このキャンペーンでは、総コストは数値化されません。

スリープはプロセス内のみに保持されている状態を破棄します。永続的なデータはディスク上または適切なサービスに属します。追跡されていないバックグラウンド作業は、プロセスの存続に依存してはなりません。マネージド PRNext Host サービスもまた別のレイヤーです。この記事では、その価格設定や導入パフォーマンスを測定するものではありません。

#観察された安定性とテストの限界

6 回の 10 分間の混合負荷実行で、両方の VPS の 3 つのバリアントがカバーされます。各実行の後に、30 回のストリーミング キャンセルと 46 秒間の静かな時間が続きます。これらの最終キャンペーンでは、コンテンツの障害、ロード エラー、テスト対象サーバーのメモリ不足による強制終了は観察されませんでした。

最初の耐久性の試行では、テストされたサーバーではなく、ロード ジェネレーターのメモリ保持が明らかになりました。ツールを修正した後、同じ修正されたジェネレーターを使用して、6 回の最終実行をすべて繰り返しました。ツールのリンクは、測定されたエンジンのコミットとは別に、コミット fb59284 を指します。

メモリは依然として変動します。制約された大規模 VPS では、最初と最後の 1 分の間に PRNext が 119.0 から 130.4 MiB に移動します。その混合スループットは、その構成における以前の PRNext コードよりも約 12% 低くなります。 10 分では、漏れがないことも、数週間にわたる安定性も確立されません。

キャンセルして待機した後、PRNext のファイル記述子は 44. に戻ります。これだけでは、リークを宣言したり、長期間にわたってリークを除外したりするには十分ではありません。ブラウザ検証では、48 時間指定コンテキストと、強制フォールバックを含む 10 個の機能チェックが追加されます。すべての Next.js アプリケーションとの完全な互換性は実証されていません。

#これらの結果が PRNext にとって何を意味するか

最も有力な議論は、通常の SSR といくつかの制約された予算にわたるストリーミングに対する CPU の効率です。メモリも有利な場合がありますが、このキャンペーンでは物理的な小規模 VPS にはメモリがありません。スリープは、断続的なプロジェクトに別の選択肢を提供します。RAM をリリースするか、ウォーム レスポンスを保持します。

次の優先事項は、重いレンダリングの割り当て、ハイドレーション、一部の予算の下でのスループットの回帰、およびワーカー間のスケーリングです。このキャンペーンでのいくつかのビルド測定も、ビルドが高速になるという一般的な主張を裏付けるものではありません。

PRNext は実験的なものであり、その Next.js 互換性は部分的です。それがアプリケーションに適合するかどうかを判断するには、高価なルート、トラフィック、沈黙期間、および特定されたアーティファクトによるウェイクアップを再現します。これらの結果は、フレームワークの普遍的なランキングではなく、検証可能な出発点を提供します。

React SSR のパフォーマンスをベンチマークする方法

Next.js は VPS でどれくらいの RAM を必要としますか?

PRNext および Next.js: 互換性および移行ガイド