Next.js 16.3・Astro 7・Nuxt 4.5で同じデザインのブログを組んで実測比較した
目次
Vercelは2026年8月3日（現地時間）、Next.js 16.3を公開した。
16.0以来最大の更新とうたっており、開発サーバーのメモリ削減とビルドキャッシュが目玉になっている。
主要フレームワークの新版はこの夏に揃って出ている。
AstroはVite 8とRust製コンパイラを載せた7.0が6月22日、7.1が7月16日。
Nuxtも4.5.0が7月18日に出たばかりだ。
Vite 8の中身は別記事に書いた → Vite 8.0、Rolldownでビルドを最大30倍高速化
バージョンの節目が重なったので、同じデザインのブログを3つのフレームワークでそれぞれ組み、手元のM4 Mac miniで同条件の実測をした。
見た目は3つとも同一に仕上がった。それでもビルドの速さからブラウザに届くJavaScriptの量まで、フレームワークごとに桁の違う数字が出た。
Next.js 16.3の主な変更
公式発表のうち、アップグレードするだけで既存アプリに適用される変更はこんな感じ。
| 変更 | 公式発表の数字 |
|---|---|
| dev時のメモリ削減（ディスクキャッシュ+メモリ退避が既定で有効） | 最大90%減。vercel.comの管理画面で21.5GB→2GB |
ビルドのファイルシステムキャッシュが next build でも既定で有効 | 一部プロジェクトのCIで5.5倍。nextjs.orgは21秒→9.2秒 |
| App RouterのSSRをWeb StreamsからNode.jsのネイティブストリームへ置換 | 負荷時に最大22%多くのリクエストを処理 |
TypeScript 7でのタイプチェックに実験的対応（experimental.useTypeScriptCli: true が必要） | TS7自体がネイティブ移植で10倍高速というMicrosoftの発表を受けたもの |
next dev がAIエージェント環境の検出時にAGENTS.mdを自動生成 | エージェントにバージョン一致のドキュメントを読ませる |
オプトインの新機能群はInstant Navigationsという名前でまとまっている。
next.config.ts で cacheComponents と partialPrefetching の2フラグを立てると、リンク先のローディングシェルを事前取得してSPAのような画面遷移にする。
遅いナビゲーションを自動検出するInstant Insights、ローディング状態を見るNavigation Inspector、遷移の即時性をテストするPlaywright用 instant() ヘルパーが付く。
ビルド時に事前生成しなかったURLへ最初の訪問者が来たとき、ローディングシェルを即返して裏で本体を生成するISR（Incremental Static Regeneration、アクセスに応じた段階的な静的化）の改善も入った。
実験扱いではRust版React Compilerが来た。
BabelではなくTurbopack（Next.js標準のRust製バンドラー）内で直接動かす方式で、v0のような大規模アプリで next dev からページ表示までがコールドで34%、ウォームで46%短くなったとしている。
比較の条件
計測環境は次の通り。
| 項目 | 値 |
|---|---|
| マシン | M4 Mac mini（メモリ16GB） |
| ランタイム | Node.js 25.3.0 / pnpm 10.27.0 |
| Next.js | 16.3.0（8月3日公開） |
| Astro | 7.1.6 |
| Nuxt | 4.5.1 |
サイトはヘッダー、記事一覧のトップページ、記事3本、フッターだけの小さいブログとした。
テンプレートやUIライブラリは使わず、3つとも同じHTML構造を手書きし、CSSファイルと記事データのJSONはバイト単位で同一の物を共有した。
実装量はNext.js 76行、Astro 74行、Nuxt 71行（共通CSSとJSONを除く）に収まった。
3実装のソースと計測スクリプトはGitHubに置いた → LiltingChannelLabo
3つの本番ビルドをそれぞれローカルで配信し、ヘッドレスChromeで同条件のスクリーンショットを取得したところ、3枚のPNGが1バイトも違わない同一ファイルになった（MD5ハッシュが一致）。
1ピクセルでも描画が違えばファイルのバイト列は変わるので、3実装の描画結果は完全に同じだ。同じ見た目のサイトを比べるという前提はここで揃った。
ビルド時間
キャッシュディレクトリを消してからのコールド、無変更で再実行したウォーム、ソースを1行変えた差分を測った。
| コールド | ウォーム（無変更） | 1行変更 | |
|---|---|---|---|
| Next.js | 3.3〜5.3秒 | 2.0秒 | 2.9秒 |
| Astro | 0.6〜2.3秒 | 0.5〜0.6秒 | 0.8秒 |
| Nuxt | 2.7〜4.9秒 | 2.4秒 | 3.4秒 |
コールドに幅があるのは、初回だけ遅いためだ。3つとも、初回実行には一度きりのセットアップ分が上乗せされていた。
16.3で既定になったビルドキャッシュで、Next.jsはコールド3.3秒がウォーム2.0秒、1行変更で2.9秒になった。
ただしこの規模だと短縮は1秒前後だった。公式の5.5倍は、ビルドに数十秒かかるプロジェクトをCIで繰り返し回したときの数字だ。
Astroはコンパイル本体が142msで終わり、キャッシュの有無による差がほとんど出なかった。
開発サーバー
起動から最初のHTTP 200まで、記事ページの初回アクセス、ウォームアップ後のメモリ使用量（RSS）を測った。
| 初回200まで | 記事ページ初回 | 2回目以降 | RSS | |
|---|---|---|---|---|
| Next.js | 1.4〜1.5秒 | 244ms | 11〜15ms | 513〜615MB（4プロセス） |
| Astro | 1.6秒 | 8ms | 2〜3ms | 288MB（1プロセス） |
| Nuxt | 2.9秒 | 8ms | 3〜4ms | 593〜607MB（5プロセス） |
Next.jsはページ単位の遅延コンパイルがあるため、未訪問ページの初回だけ244msかかる。
メモリはプロセス構成の差が出た。Astroは単一プロセスで288MB、Next.jsとNuxtはワーカーを分ける構成で500〜600MB台になる。
公式の最大90%減は、多数のルートをコンパイルした開発セッションで、ディスクキャッシュとメモリ退避を有効にして測った値だ。手元の6ページではそもそも退避するほどのルート数がなく、この削減は確認できなかった。
もうひとつ、手元で next dev を起動するとプロジェクト直下にAGENTS.mdが生成された。
AIコーディングエージェントの環境を検出したときに書き込む仕組みで、設定の agentRules: false で無効化できる。
中身は “This is NOT the Next.js you know” という見出し（生成されたAGENTS.mdより）で始まり、学習データより新しいAPIがあるからnode_modules内の同梱ドキュメントを読め、とエージェントへ指示する内容になっている。
削除しても再生成されるからコミットに含めろ、という案内までファイル自身に書いてある。
公式は同時に、最新ドキュメントを配るためだけに存在していた旧Skills群をこの仕組みで廃止した。
ページの重さ
本番ビルドをローカル配信し、トップページをgzip有効で取得して、HTMLと参照アセットの転送量を合計した。
| HTML | 外部JS（gzip後） | JSファイル数 | |
|---|---|---|---|
| Next.js | 7.9KB | 564KB（172KB） | 6 |
| Nuxt | 2.9KB | 58KB（21.5KB） | 1 |
| Astro | 2.9KB | 0 | 0 |
今回のサイトにクリックで動く要素はひとつもない。
それでもNext.jsはReactランタイムとルーターを含む6ファイル、gzip後172KBを配信する。全ページが静的生成（SSG）扱いでも、クライアント側のページ遷移機構が常に含まれるためだ。
HTMLが7.9KBと大きいのは、React Server Componentsの再構築用データがインラインで埋まっているからだ。
NuxtはVueランタイム込みで21.5KB、Astroは外部JSどころかCSSリクエストも消える。今回のCSSは1.6KBと小さいため、Astroが <head> 内へインライン化してHTML 1リクエストだけのページにした。
インストールと出力の規模はこんな感じ。
| node_modules | パッケージ数 | ビルド出力 | |
|---|---|---|---|
| Next.js | 317MB | 24 | .next 18MB（next start で配信） |
| Astro | 137MB | 197 | dist 16KB（HTML 4枚、静的置き場に直置き可） |
| Nuxt | 185MB | 564 | .output 2.4MB（Nitroサーバー同梱） |
Next.jsはパッケージ数が24と最少なのに、SWCとTurbopackのネイティブバイナリを本体へ同梱するためサイズは最大になる。
Astroは静的ファイル、NuxtはNode.jsサーバー一式、Next.jsはビルド成果物と実行環境がセットの構成で、出力の形も揃っていない。
lilting.chはAstroで運用していて、今回の実測でも乗り換えを考える理由は見つからなかった。
一方でNext.js 16.3の改善は、今回のサンプルよりずっと大きい規模を対象にしている。公式のメモリ測定は50ルートをコンパイルした後の値、Rust版React Compilerの数字はv0での値だ。
CloudflareがNext.jsをVite上に再実装した話も別記事に書いた → CloudflareがAIで1週間でNext.jsをVite上に再実装、vinextが本番稼働