ページ数が数百ある企業サイトをNext.jsで触っていると、開発機のファンが回りっぱなしになります。npm run dev を立ち上げて、いくつかのページを行き来しながら作業していると、時間が経つほどメモリが膨らみ、保存してからブラウザに反映されるまでが遅くなる。再起動するとしばらく快適で、また同じことが起きる。
原因ははっきりしていて、Turbopackが訪れたルートのキャッシュをメモリ上に持ち続けていたためです。ページ数が多く、作業中に行き来する範囲が広いサイトほど不利になる設計でした。
2026年8月3日にリリースされたNext.js 16.3で、この部分が変わりました。
何もしなくても効く変更と、設定が要る変更を先に分ける
16.3の変更を読むときに最初にやるべきなのは、「アップデートするだけで効くもの」と「設計判断が要るもの」を分けることです。ここを混ぜて読むと、移行工数の見積もりが実態から離れます。
| 変更 | 何をすれば効くか |
|---|---|
| 開発サーバーのメモリ最大90%削減 | バージョンを上げるだけ |
| 本番ビルドのキャッシュ | バージョンを上げるだけ |
| 負荷時のリクエスト処理量が約22%向上 | バージョンを上げるだけ |
| インスタントナビゲーション | 設定フラグ + ルートごとの設計判断 |
上の3つは既存アプリに無改修で効きます。メモリ削減は、Turbopackがキャッシュをディスクへ退避できるようになり、ディスクキャッシュとメモリ退避が既定で有効になったことによるものです。長時間の開発セッションで効いてくる種類の改善なので、体感しやすいのはむしろ「夕方になっても朝と同じ速度で動く」という形になります。
CIのビルド時間が課金に直結するホスティングを使っている場合、本番ビルドのキャッシュも見逃せません。ビルド時間そのものがコストになる構造の整理はDockerビルドの高速化とCIコストでも触れています。
インスタントナビゲーションは「速くなる機能」ではなく「選ばせる機能」
16.3の目玉として紹介されるインスタントナビゲーションは、名前から受ける印象と中身が少しずれます。リンクをクリックしたときにネットワークを待って画面が固まる問題に対して、待ち方を選べるようにしたものです。有効化には設定の cacheComponents フラグが必要で、そのうえでルートごとに3つの振る舞いから選びます。
<Suspense>でストリーミングする。クリックした瞬間にローディングの骨組みが出て、中身は後から流れ込みます'use cache'でキャッシュを見せる。前に取得したUIを再利用して即座に表示しますexport const instant = falseで従来どおりにする。サーバーの応答を待ってから遷移します
3番目が用意されていることが、この機能の性格を表しています。すべてのページを即座に表示するのが正解ではない、という前提に立っているわけです。
受託で作るサイトなら、どのルートに何を割り当てるか
ここは実務の判断が要ります。企業サイトやオウンドメディアで、ざっくり次のように整理できます。
ローディングの骨組みを出してよいところは、一覧・検索結果・ダッシュボードのように、表示に時間がかかることを利用者が予期している画面です。ここはストリーミングが素直に効きます。
キャッシュを見せてよいところは、更新頻度が低く、少し古い内容が出ても実害がない画面です。会社概要、サービス紹介、過去記事など。
従来どおりにしたほうがよいところは、中途半端な状態を見せると信用を落とす画面です。記事本文がその代表で、ローディングのスケルトンが一瞬出てから文章が現れるより、少し待って完成形が出るほうが読み手の印象はよくなります。フォームの確認画面や、在庫・価格のように「古い値を見せると事故になる」ページも同じです。
判断基準は表示速度ではなく、「その画面で嘘をついてよいか」です。キャッシュを見せるということは、一瞬だけ過去の状態を表示するということなので、そこに耐えられる画面かどうかで振り分けます。体感速度と実際の速度の関係はストリーミングSSRと体感速度で整理しています。
上げる前に確認しておきたいこと
無改修で効く部分があるとはいえ、稼働中のサイトをそのまま上げてよいわけではありません。確認しておく点を挙げます。
cacheComponentsを有効にするかどうかを先に決める。有効にしないままでもメモリとビルドの改善は受けられます。まず上げるだけ上げて、インスタントナビゲーションは別作業にするのが安全です- ディスクキャッシュが増える分の容量。メモリからディスクへ移した以上、CIの実行環境やコンテナのディスク割り当てを見ておく必要があります
- 16.2からの移行で溜めてある宿題。バージョンを飛ばしている場合は、Next.js 16.2でのビルド高速化と移行で扱った変更点を先に消化しておくと切り分けが楽になります
なお、そもそもNext.jsが要るのかという問いは別にあります。更新頻度が低く、動的な要素がフォームだけのコーポレートサイトなら、静的サイトジェネレーターのほうが運用コストは下がります。判断材料はNext.js と Astro の比較にまとめてあります。
次にやること
稼働中の案件があるなら、まずステージング環境で16.3に上げて、npm run dev を数時間回したときのメモリの推移を見てください。開発体験の改善は測りにくい割に、日々の作業時間に直結します。インスタントナビゲーションの設計はそのあとで構いません。
サイトの構成見直しやフレームワークの選定を含めて相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
