PRNext 0.1.21:Flight・キャッシュ・ビルドを改善

PRNext 0.1.21-alpha を npm で公開しました。????????、アプリケーションの描画結果を変えずに省ける処理を減らします。レンダリングホストは最初の動的リクエストより前にフレームワークを準備でき、ビルドは変更のないファイルを繰り返し解析する代わりに、検証済みの小さな要約を再利用します。キャッシュされたプリミティブ値にはコンパクトな内部形式を使い、複雑な React の値は公式 Flight デコーダーで処理します。

公開リクエスト、直接接続するプロキシ、ローカル制御サービスの境界も強化します。0.1.20 を基盤とする改善であり、ユーザー間で応答を共有するキャッシュを追加するものではありません。認可、データの有効期間、デプロイ手順は引き続きアプリケーション側が管理します。

最初の動的応答より前に各ホストを準備する

明示的な --prewarm はすべてのレンダリングホストを準備し、置き換えたプロセスやアイドル状態から復帰するホストにも同じ準備を適用します。初期の全体予算は 15 秒で、同時実行は最大 2 件です。小さな内部 RSC・HTML モデルで公式レンダラーを動かしますが、アプリケーションルートの import やアカウントデータの読み取りは行いません。

初期の準備完了判定はこの処理を待ちます。ただし、アプリケーションの import、データベース接続、リクエストデータは最初の実際の描画に追加の時間を要する場合があります。後続の置き換えで準備が完了しなければ診断を記録し、通常リクエストでの遅延読み込みを残します。遅延起動が引き続き既定で、失敗したアプリケーションリクエストを再実行しません。静的ファイルが返ることだけで React の準備完了を判断せず、起動から最初の動的応答までを測定してください。

Terminal
npx --no-install prnext start --workers 2 --prewarm

同じ Flight 応答の周囲で発生する割り当てを減らす

Flight のメッセージエンベロープと転送配列は、それぞれの応答内だけで再利用し、転送後は buffer への参照を解放します。大きなインライン起動スクリプトは上限付き buffer に直接エンコードします。ほかの構造も必要になるまで作成を遅らせ、通常の完全な HTML フラグメントには直接処理する経路を使います。

エンコード結果、base64、CSP nonce の意味は変わりません。キャンセル、読み取りクレジット、外部所有データの防御的コピー、応答の分離を維持します。引用符付き属性や曖昧な HTML は従来のパーサー経路を使います。この処理削減によって、個人向けの応答を別のリクエストに使い回すことはありません。

Flight のサイズとレンダリングの進行を観察する

明示的に有効にする検査機能は、Flight のバイト数、チャンク、結果をルートパターンと描画フェーズ別に集計します。完了、キャンセル、失敗、タイムアウトを区別し、観察できた場合はモデルとシェルの準備完了時点も表示します。RSC と SSR は同じペイロードを観察することがあるため、サイズやリクエスト数を合算してはいけません。

時間にはアプリケーション処理と非同期の待機を含み、エンコーダーやデコーダー単体の CPU 時間ではありません。欠測値はゼロに置き換えません。診断に本文、cookie、認可情報、未加工のクエリデータは保持しません。任意の GC、ヒープ、イベントループ診断も利用でき、無効時には GC オブザーバーを作成しません。V8 の既定プロファイルと運用者による明示的な設定は変わりません。

Terminal
npx --no-install prnext start . --inspect
npx --no-install prnext inspect --json

検証を残しながら小さなビルド情報を再利用する

繰り返すビルドでは、後続フェーズに必要なディレクティブやエクスポートを含む、型とサイズ制限のある Oxc 要約を再利用できます。不変の要約にソース本文、AST、アプリケーションのクロージャーは保持しません。識別情報と世代の検証により、記録が現在の入力に属することを確認します。欠損や不正な記録があれば通常の処理に戻ります。

ネイティブコードを含まないと確認できた依存グラフでは、ネイティブ依存の検出も範囲を限定した証明を再利用します。未知の副作用、独自 hook、入力の変更に対する検証は残り、不透明なグラフを無条件に再利用しません。参照アプリケーションとツールには選択的な依存更新も含まれ、Next 16.4.4、Better Auth 1.7.15、Redis クライアント 6.3.1 が参照基準になります。

ファイル処理を制限し、ビルドの内訳を示す

Standalone の追跡ファイルとフレームワークランタイムのコピーは、同時実行数、別名の処理順序、受け入れ予算を制御します。コピー途中のソース変更も検出できます。処理が失敗した場合は開始済みの書き込みを終えてから一時出力を破棄し、前回公開したビルドを保持します。Pages のサーバーチャンクと source map は最初の書き込みより前にメモリー上で書き換えます。

build --timings は React ビルドのフェーズを表示し、コンパイラーの遅い段階とファイル処理を区別します。合計には CLI モジュールの起動時間を含まず、入れ子のフェーズは重なるため、単純な足し算はできません。計測レポートはデプロイ用マニフェストやブラウザー向けアセットに含めません。

Terminal
npx --no-install prnext build --timings

キャッシュ値と PPR の継続処理を React に任せる

キャッシュのコールバックは、React.cache のコンテキストを含め、公式 React レンダラー内で引き続き一度実行されます。適格なプリミティブ値にはバージョン付きのコンパクトな内部形式を使います。オブジェクト、React ノード、関数、一時参照には正規の Flight 経路を残し、通常の複雑な値では元のバイトを使います。BOM、不正な UTF-16、描画上限に近い文字列や値にも公式 Flight の処理を使います。

リクエストごとのプライベートなスコープ、タグ、TTL、新しくデコードされたオブジェクトを維持します。変更は結果の codec であり、アカウント間のキャッシュを追加するものではありません。ネイティブ PPR の不変な解析結果とプレフィックス情報は、現在のアーティファクトのバイトと SHA を再検証してから、上限付きで再利用します。変更可能な継続状態はリクエストごとに複製します。入れ子や直接実行できない継続では、必要に応じて従来の正規化経路を維持します。

RSC エントリーのキー名前空間も変わります。更新後は旧結果を再利用せず、最初の呼び出しで対象キャッシュを再充填するため、ウォームアップの評価にこのコストも含めてください。

放棄された開発リクエストを待ち行列から外す

期限切れやキャンセル済みの開発リクエストは、待ち行列にある自身のコンパイル要求を維持しなくなります。ほかの呼び出し元が必要とする共有コンパイルは、そのライフサイクルを保持します。切断されたリクエストのためだけの処理を避けつつ、別のタブで必要な作業を取り消さないための区別です。

開発 RPC の通知は最初の公開が受理された後も正しい情報源になります。遅れて届いたファイルのスナップショットで、RPC がすでに消した診断を復活させません。RPC が確立するまではファイルのみの通知も使えますが、古い世代の状態を混在させません。

開発時には、連続したナビゲーションと Fast Refresh の Flight ストリームも連携します。応答がまだ完了していなくても、古いコンポーネントツリーに戻して共有 layout の状態を失うことなく、次のルートへ移れます。この変更は開発時のナビゲーション GET に限られ、更新処理を再送しません。本番の応答と Server Actions は厳密なデコードを維持します。navigationCache.authCookies にセッション cookie を設定している場合は再認可が優先され、あるユーザーの下書きを別のユーザーへ引き継ぐことはありません。

適用済みの更新を確認している間に、Server Action が表示だけを置き換えることもあります。Fast Refresh は、この表示変更と更新自体のキャンセルを区別するようになりました。実際のエラー、キャンセル、ネットワーク期限切れは引き続き失敗として扱い、Action を再送しません。

この開発向けの統合は、PRNext とともに検証した React のバージョンに依存します。Flight クライアントの実験的なオプションを使いますが、本番ではこの動作を有効にしません。

同じアーティファクトで Node 26 を検証する

Linux CI には Node 26 向けのランタイムと HTTP、Chromium、SaaS 利用側、パッケージインストールの検証が加わり、ホイストされた配置と入れ子の配置を対象にします。追加のブラウザー対象は Chromium です。Linux、macOS、Windows の主マトリクスを置き換えたり、デプロイ先の Node を自動選択したりはしません。

機能検証の範囲だけでは Node 26 のスループットは分かりません。ランタイムを変更するときは、同じアーティファクトと依存関係で比較し、自分のアプリの動作も確認してください。今回の計測は Node 22.23.4 を使っており、Node 26 の数値的な性能向上は主張しません。

各計測を実際の対象範囲で読む

公開済み 0.1.20 のソースと候補 7c15132a の比較は、Linux x64 と Node 22.23.4 で実行しました。ルートごとに十二組、合計 72 の計測区間を設け、二つの worker、可視の二 CPU と 5 GiB の上限、同じ二 CPU への affinity を使います。各区間は二秒のウォームアップ後に十五秒計測し、接続数は SSR が八、JSON API が二、ストリーミングが八です。

計測区間内に完了した有効な応答は 774,665 件、ドレインを含めると 775,089 件です。ドレイン中の 424 件はスループットに含めません。HTTP、転送、検証のエラー数はいずれもゼロでした。ウォームアップは別集計で、区間内が 51,123 件、ドレインを含めると 51,552 件です。

候補と基準のペア比較によるスループット比の中央値は、SSR が 0.9944、JSON API が 0.9941、ストリーミングが 0.9978 です。対応する p95 比は 1.0361、1.0056、1.0028 で、報告された区間はいずれも 1 を含みます。事前に固定したスループット低下 10% 以内、p95 増加 15% 以内の予算を満たしました。基準に近いこの結果は、一般的な高速化を示すものではありません。

基準の JavaScript アーカイブは公開済み 0.1.20 と完全に一致し、候補もこのソースの Linux 検証用アーカイブと一致します。ただし、両方のネイティブ実行ファイルは別途再ビルドされており、過去の公開ネイティブや release 検証済みネイティブと同一のバイト列ではありません。比較対象はソースに対応するこれらの組み合わせで、JavaScript の変更だけを分離した結果ではありません。

全 72 サンプルでカーネルとプロセスの観測が検証されています。メモリはサンプリング値であり、namespace に隠れた親の制限や runner の競合は検証範囲外です。その他のビルド依存や推移的依存も、すべてをバイト単位で認証しているわけではありません。三つの合成負荷から、CPU や RAM 全体の削減、本番容量、SLA は導けません。

公開オリジンとローカル制御の信頼境界を明確にする

保存した公開オリジンと信頼するプロキシのポリシーが、開発、永続プロセス、ネイティブの複数アプリケーション向け入口に適用されます。HTTP と WebSocket の転送も対象です。PRNext は実際の接続元を確認してから、転送されたホスト情報やプロトコルを受け入れます。明示した正規オリジンが優先されますが、プロキシを信頼してもクライアント IP の転送経路全体が認証されるわけではありません。

画像のフォールバック URL は各 URL 要素から組み立て、内部取得の例外を認める前に最終的な正規化オリジンを検証します。コンパイラーとスーパーバイザーの RPC は両端を認証し、新しい nonce と正確なコマンド・応答バイトを結び付けます。メッセージと期限の上限は維持します。このプロトコル変更により、更新前に旧スーパーバイザーを停止する必要があります。

CLI を置き換える前に旧スーパーバイザーを停止する

永続スーパーバイザーを使う場合は、パッケージを置き換える前に、まだインストールされている旧 CLI と同じ PRNEXT_PM_HOME で状態を確認して停止してください。pdown はそのスーパーバイザーと同じディレクトリーを共有する全管理アプリケーションに影響するため、まとめて保守を計画します。グローバル CLI の更新だけでは各アプリケーションのランタイムは置き換わりません。ソース、lockfile、設定、ビルド、互換性のあるデータベースバックアップを回復用に残します。

Terminal
npx --no-install prnext pstatus --json
npx --no-install prnext pdown
npm install @thomas.f/prnext@0.1.21-alpha
npx --no-install prnext check --production --json
npx --no-install prnext build

任意のネイティブ依存を有効なままにし、フレームワークとバージョンを合わせます。React、React DOM、react-server-dom-webpack は 19.3.1、対応 Node 範囲は ^22.23.4、^24.22.1、または >=26.12.1 です。目的のスーパーバイザーを再起動する前に、有効な各アプリケーションを新ランタイムでビルドし直します。新 CLI は互換性のない旧プロトコルを拒否し、黙って制御を引き継ぎません。

PRNext は引き続き alpha で、Next.js 互換性は部分的です。代表的なアプリケーションでの試行と独自の信頼性目標は別途検証が必要です。製品固有のログイン、アカウント切り替え、ナビゲーション、フォーム、ストリーミング、依存障害、ロールバックを確認してください。npm フレームワークの更新は PRNext Host や外部サービスをデプロイせず、コードのロールバックもデータベースへの書き込みを取り消しません。

技術資料

0.1.21-alpha の7つのパッケージは npm で入手できます。以下の実装ソースと制御比較では、変更点、適用条件、計測結果の限界を説明しています。

npm の PRNext 0.1.21-alpha

フレームワークの変更と実装

プロキシ、画像、ローカル RPC の保護

ナビゲーション、Fast Refresh、アップグレードの説明

ナビゲーションと Fast Refresh の信頼性

公開済みフレームワークのソース 7c15132a

0.1.20 との制御比較

ブログに戻る