Turbopack 開発版が安定版に

長い道のりでしたが、next dev --turbo が安定版となり、開発体験を高速化できることを発表できることを嬉しく思います。私たちは Vercel.com をはじめ、多くのアプリケーションで Turbopack を使用しており、素晴らしい結果を得ています。

8 年前にリリースされて以来、Next.js は週末の趣味プロジェクトから洗練されたエンタープライズアプリケーションまで、あらゆるものを構築するために使用されてきました。Next.js が最初にリリースされたとき、webpack はフレームワークのバンドリング基盤として明らかに最良の選択肢でしたが、時間の経過とともにモダンな Web 開発者のニーズについていくのが困難になってきました。コミュニティは、ルートの読み込み、コード変更の反映、本番ビルドのデプロイを待つ間に、痛いほど遅いイテレーションに悩まされるようになりました。

webpack の最適化に多大な時間と労力を費やしましたが、ある時点から、費やした労力に見合うだけの改善が得られないと感じるようになりました。React Server Components のような将来のイノベーションだけでなく、今日すでに本番環境にある多くの Next.js アプリケーションをサポートできる新しい基盤が必要でした。

これらの要件が、この新しいバンドラに求められるものでした。

• 最小限の破壊的変更
• App Router と Pages Router の両方をサポート
• あらゆるサイズのコードベースでのコンパイル時間の短縮
• 本番環境に近い開発ビルド
• 高度な本番環境最適化（例：モジュール内のツリーシェイキング）
• Node.js やブラウザのような複数の環境をサポートするモジュールグラフ
• メンテナンス担当者および上級ユーザー向けの完全なオブザーバビリティ

当時の既存のソリューションをすべて評価しましたが、それぞれに要件や目標と一致しないトレードオフがあることがわかりました。Next.js が現在必要としているものを正確に accomplish するようにゼロから設計し、将来必要となるもの（Tomorrow's needs）を構築・実験できるようにロードマップを所有するのが理にかなっていました。これが、Turbopack を作成した動機です。

開発体験の最適化から始め、本日安定版としてリリースされるものです。Vercel のアプリケーションで Turbopack を広範にドッグフーディングしており、開発者のイテレーション速度を大幅に向上させています。例えば、vercel.com という大規模な Next.js アプリケーションでは、以下の改善が見られました。

• ローカルサーバー起動時間が最大 76.7% 高速化。
• Fast Refresh によるコード更新が最大 96.3% 高速化。
• キャッシュなしでの初回ルートコンパイルが最大 45.8% 高速化（Turbopack はまだディスクキャッシュをサポートしていません）。

この記事では、これらの結果をどのように達成したか、その他のハイライトについても説明します。また、このリリースで何が期待できるか、そして次に何が期待できるかのロードマップも明確にします。

ハイライト

初回ルートコンパイルの高速化

コミュニティから寄せられる最大の課題の1つは、開発時のルート読み込みに時間がかかりすぎるという点でした。これは webpack のコンパイル速度に起因していました。Next.js はオンデマンドでルートをコンパイルするため、必要になる前にすべての可能なルートをコンパイルする必要がなく、初回起動を高速に保ち、メモリ使用量を低く抑えていますが、それでも単一のページが読み込まれるのを待つ間、足踏みしてしまうことがありました。

公平に言えば、webpack のようなバンドラは裏で多くのことを行っています。ルートを初めてコンパイルする際、バンドラは「エントリポイント」から始まります。Next.js の場合、これは page.tsx と、そのルートに関連する layout.tsx や loading.tsx などのすべてのファイルとの組み合わせです。これらのエントリポイントは、インポートとして解決される import 文を見つけるために解析され、それらはエントリポイントと同じように処理され、これ以上のインポートが見つからなくなるまでこのサイクルが続きます。このプロセスはモジュールのグラフを構築しますが、これは TypeScript/JavaScript モジュール（node_modules を含む）だけでなく、CSS ファイル（グローバルおよび CSS モジュール）や、next/image のインポートされた画像のような静的ファイルで構成されることもあります。

すべてのモジュールが収集された後、モジュールグラフを使用して JavaScript のバンドル（「チャンク」とも呼ばれます）が作成されます。これらのチャンクは、サーバー（ビルド時または実行時）またはブラウザで実行されるコンパイラの出力です。

webpack は複数の環境に対する出力を生成するグラフの作成をサポートしていないため、Next.js では webpack を使用する場合、サーバー用とブラウザ用の少なくとも 2 つの別々のコンパイラを実行する必要があります。"use client" へのすべての参照を見つけることができるように、まずサーバーのモジュールグラフをコンパイルする必要があります。サーバーがビルドされたら、そのグラフをたどってブラウザコンパイラ用の関連エントリポイントを作成します。これは別の webpack コンパイラであるため、クライアントとサーバーで同じコードを 2 回解析するなど、このプロセスにはいくつかのオーバーヘッドがあります。

Turbopack では、複数のコンパイラを実行し、それらを連携させるオーバーヘッドを排除することを目指しました。その解決策は、コンパイラに複数の異なる出力ターゲットを認識させることでした。内部的には、これらはターゲット「トランジション」と呼ばれます。サーバーからブラウザへの、あるいはブラウザからサーバーへのトランジションとしてインポートをマークすることができます。これにより、Turbopack はサーバーコンポーネントとクライアントコンポーネント、およびクライアントコンポーネントからインポートされたサーバー関数を効率的にバンドルできるようになります。

パフォーマンスの向上に加えて、単一のパスで複数の環境を処理できる単一のコンパイラを持つことは、信頼性とデバッグの面でもメリットがあります。Next.js で 2 つの別々のコンパイラプロセスを連携させる必要がなくなるためです。

webpack と Turbopack のもう 1 つの大きな違いは、Turbopack が複数の CPU で並列処理できるのに対し、webpack では SWC を使用した TypeScript/JavaScript の変換ステップのみが並列化されることです。

webpack は、効果的に並列化するためにはデータがスレッド間で簡単にアクセスできる必要があるため、CPU 間での並列化をサポートしていません。webpack は、大きな JavaScript オブジェクトに大きく依存する形で構築されており、高価なシリアライゼーションとデシリアライゼーションなしではスレッド間で簡単に共有できません。このオーバーヘッドにより、複数の CPU を活用してもパフォーマンスの向上は相殺されることがよくあります。Turbopack は Rust で記述されており、同様の制約がなく、最初から並列化を考慮して構築されています。

また、ファイルシステムの読み書きの高速化、モジュール解決の高速化、そして副作用のないモジュールをスキップすることによってもパフォーマンスの向上が実現しました。

Vercel.com で Turbopack を使用すると、大規模な Next.js アプリケーションで webpack を使用した Next.js と比較して、初回コンパイル時間が最大 45.8% 高速化しました。

Fast Refresh の高速化

Fast Refresh は、バンドラがブラウザで現在見ているルートへの変更を伝播させるシステムであり、ホットモジュールリプレイスメント（HMR）とも呼ばれます。

Next.js は、Fast Refresh を React に接続するより深い統合を備えており、コンポーネントを変更しても React が状態を失わないようにしています。

webpack では、JavaScript モジュール数が一定数を超えると Fast Refresh のパフォーマンスに限界があることがわかりました。webpack はグラフのトラバースを行い、変更されていないモジュールに対しても出力を生成する必要があり、JavaScript モジュールの量に比例してスケールします。

約 30,000 モジュールを超えると、コード変更が処理されるのに少なくとも 1 秒のオーバーヘッドがかかることがわかりました。変更が小さい場合でも同様です。例えば、CSS ファイルの色を変更しても、画面に表示されるまでに 1 秒かかることがあります。

このパフォーマンスは許容できるものではありませんでした。インクリメンタルビルドは、ルートやアプリケーションのサイズではなく、ローカル変更のサイズにのみスケールするべきだと考えています。button.tsx が変更された場合、コンパイラは、その変更の影響を受けない他のモジュールや出力ファイルを再計算する必要なく、そのファイル変更に関連する作業のみを実行する必要があります。これを克服するために、Turbopack の基盤として、非常にきめ細かく作業を再計算できるものに重点を置きました。

この取り組みは、基盤となるライブラリであるTurbo Engine につながりました。これは、大規模な Next.js および React アプリケーションのインタラクティブなホットリローディングを数十ミリ秒で提供する、自動的なデマンド駆動型インクリメンタル計算アーキテクチャを使用しています。このアーキテクチャは、10 年以上にわたる研究と、webpack、Salsa、Parcel、Adapton、そしてRustコンパイラのクエリシステムなどの先行研究に基づいています。

現在、Turbopack では、Fast Refresh の速度が変更のサイズにスケールするようになり、vercel.com のような大規模な Next.js アプリケーションで、Fast Refresh によるコード更新を 96.3% 高速化することができました。

高度なトレース

長年にわたり Next.js の採用が拡大するにつれて、GitHub で報告された問題、特にコンパイラパフォーマンスとメモリ使用量に関連する問題を再現することがますます困難になりました。これは、ほとんどの人がアプリケーションコードを共有できない、またはコードを共有しても、データベースやその他のセットアップが必要なためアプリケーションが実行できないためです。

この問題に対処するために、Next.js の内部にトレースを追加しました。これらのトレースは .next フォルダ内のファイルに書き込まれ、アプリケーションコードは含まれていません。コンパイラがそれに費やした時間、個々の変換などのその他のタイミングのみが含まれます。しかし、webpack では、コンパイラのメモリ使用量と、フレームワークやアプリケーションコードのメモリ使用量を明確に区別する良い方法がありませんでした。なぜなら、それらはすべて同じ Node.js インスタンスで実行されるからです。

Turbopack では、最初からインストルメンテーションを考慮して設計することができました。Turbo Engine にインストルメンテーションレイヤーを実装し、個々の関数のタイミングを収集できるようにしました。これらのトレースを、各関数のメモリ割り当て、解放、および永続的なメモリを追跡できるように拡張しました。

この新しい高度なトレースにより、コードベース全体ではなくトレースのみで、スローダウンやメモリ使用量を深く調査するために必要なすべての情報が得られます。

これらの新しいトレースを処理するために、アプリケーションとトレースのサイズに関係なくパフォーマンスを維持できるカスタムトレースビューアを実装しました。これは、Turbopack のスローダウンとメモリ使用量を調査するために特別に構築されたトレースビューアであり、フィードバックループを短縮することで、多くの早期導入アプリケーションのパフォーマンスを最適化することができました。

トレースビューアは当初内部使用のために構築されました（そして、深い技術的な分析が必要な状況を対象としています）が、Next.js で自分で実行するために必要な要素を整備しました。Turbopack トレースは、これらの指示を使用して生成できます。トレースが生成されたら、next internal turbo-trace-server .next/trace-turbopack を使用して、トレースを検査できるサーバーを起動できます。トレースビューアの簡単なビデオ概要は、こちら で利用可能です。

コンパイル時間の不安定性の低減

Next.js を webpack と共に使用する場合、コンパイル時間はしばしば十分に透明ではありません。ある場合、ページを開くのに 10 秒かかることもあれば、別の場合は 20 秒かかることもあります。キャッシュが存在する場合でも、一貫した結果を生み出すのに十分な影響がないことがあります。キャッシュなしのコンパイルでも、ある程度のばらつきが見られます。

Turbopack の基盤となるアーキテクチャにより、コンパイル時間のばらつきははるかに一貫したものになります。ルートのコンパイル時間は数パーセントしか変動しないため、コンパイラパフォーマンスを継続的に最適化できます。

本番環境に近い開発ビルド

コンパイル速度を最適化するために webpack では、開発環境と本番環境が異なるトレードオフを受け入れる必要がありました。そのトレードオフの例として、style-loader を使用しています。これはスタイルをページにインジェクトし、ページをリロードせずに Fast Refresh することを可能にします。しかし、これは開発中にスタイルが JavaScript によってインジェクトされることを意味し、スタイルが適用されていないコンテンツがフラッシュすることがあります。このフラッシュは回避しており、表示されないようにしています。別の例として、webpack を使用した Next.js は eval-source-map を使用しています。これは、すべてのコードが eval でラップされ、ソースマップがその中に含まれることを意味します。これにより、開発中にソースマップが利用可能になりますが、バンドルされたコードの検査とデバッグが難しくなるという代償を伴います。webpack は source-map オプションを使用して完全なソースマップを出力することをサポートしていますが、コンパイル時間とメモリ使用量に過大な影響を与えます。

Turbopack では、eval を使用せずに CSS ファイルとソースマップを出力することを目指しました。Turbopack は、ソースマップ仕様の比較的新しい部分であるsections ソースマップ を活用しています。これにより、ソースマップの出力をより効率的にマージできます。以前はすべてのマッピングを 1 つの場所に生成する必要がありましたが、今ではよりきめ細かく生成・キャッシュできるようになりました。

Turbopack の CSS 処理は常に CSS ファイルを出力し、JavaScript 処理と同様に、Turbopack 開発ランタイムの一部であるメカニズムによってブラウザをリフレッシュせずに CSS ファイルを更新できます。

開発時に Turbopack で機能するものは、本番環境でも機能し、同じように動作すると自信を持って言えるようになりました。

最初の安定版リリース

2 年前、Next.js 13 で Turbopack をアルファ版として導入し、そのパフォーマンスの可能性をプレビューしました。初期の結果は有望でしたが、基本的な使用法しかサポートしておらず、basePath のような多くの Next.js 機能はまだ実装されていませんでした。

翌年、欠けていた Next.js およびバンドリング機能の追加に注力しました。コミュニティからのフィードバックに基づき、最も一般的なイテレーション速度の不満を解消するために、next dev 体験に完全に焦点を当てることにしました。昨年の Next.js Conf までには、開発テストの 90% が合格し、Vercel の開発者はすでに日常的な開発で Turbopack を使用していました。

4 月には、Next.js 14.2 を発表し、テストの 99.8% が合格し、すぐに 100% に達しました。それ以来、GitHub で報告された問題、特に npm パッケージ、Fast Refresh、エラー場所の精度に関する問題を解決してきました。

確かに、安定版への道のりは長かったですが、それは主に Next.js の広範なテストスイートによるもので、安定性に対して高い基準を設定しています。8 年かけてエッジケースを発見し、Turbopack でも合格する必要がある 6,599 の開発テストを追加しました。もう 1 つの要因は、webpack とは完全に異なるアーキテクチャで Turbopack を設計したことです。単純に webpack を Rust に移植する方が簡単だったでしょうが、達成したいパフォーマンスの向上は得られなかったでしょう。

Turbopack がすべてのテストに合格し、主要な npm パッケージで検証され、早期導入者からのフィードバックが対応されたため、安定版としてスタンプを押す準備ができました。

正確には何が安定版ですか？

これは過去に混乱の元となっていたため、このセクションで、このリリースが Next.js コミュニティにどのようなメリットをもたらすかを明確にします。

このリリースでは、具体的に next dev --turbo コマンドが安定版としてマークされました。本番ビルド（next build --turbo）はまだサポートされていませんが、進捗状況については読み進めてください。将来的には、Next.js 外での Turbopack のスタンドアロンバージョンのリリースを計画していますが、まず Next.js コミュニティの体験を向上させることで、その価値を証明したいと考えています。

次のセクションで説明するサポートされていない機能を除き、Turbopack は Next.js のすべての安定機能で動作するはずです。明確にするために、Turbopack は App Router と Pages Router の両方をサポートしています。実験的な機能は Turbopack で動作する場合としない場合がありますが、安定版としてマークされるまでには確実に動作するようになります。

アプリケーションに webpack カスタマイズがあるが、webpack ローダーのみを追加している場合、Turbopack 用にローダーを設定することで、すでに Turbopack を使用できる可能性があります。Turbopack での webpack ローダーのサポートについては、ドキュメントをお読みください。

Turbopack で動作することが確認されている webpack ローダーのリストを以下に示します。

• @svgr/webpack
• babel-loader
• url-loader
• file-loader
• raw-loader
• tsconfig-paths-webpack-plugin — プラグインなしでそのままサポートされます。
• ほとんどの他のローダーも動作します。webpack ローダー API のサブセットをサポートしているためです。

ほとんどの CSS および CSS-in-JS ライブラリがサポートされています

• サポート
  • Tailwind CSS
  • @emotion/react
  • Sass
  • styled-components
  • Bootstrap
  • Antd
  • node-sass
  • JSS
  • Emotion
  • theme-ui (Emotion を使用)
  • @chakra-ui/core (Emotion と共に)
  • aphrodite
• 現在サポートされていないもの
  • Less — less-loader を追加できます。webpack を使用した Next.js も Less を標準でサポートしていません。
  • @vanilla-extract/css — カスタム webpack プラグインを使用しています — 将来的に必要なフックをサポートするために調査します。
  • StyleX — Babel トランスフォームと data: 属性のサポートが必要です — next build --turbo が安定版になった後に StyleX のサポートを検討します。

パフォーマンス

今日リリースされたバージョンは webpack よりも大幅にパフォーマンスが向上していますが、これは最終的なパフォーマンス数値ではありません。私たちは、Kent Beck の有名な公式「Make it work. Make it good. Make it fast.（動くようにする。良くする。速くする。）」に従っています。これまでのところ、Next.js と webpack は約 10 年間成熟しているので、そのスコープに追いつくために、私たちの労力の大部分は「動くようにする」段階に費やされてきました。

Turbopack は、キャッシングインフラストラクチャに大きく賭けていますが、ご存知のように、キャッシュはソフトウェア開発における 2 つの難しいことのうちの 1 つです。経験から、明示的に構築されていないアーキテクチャにキャッシュを追加すると、望ましくない結果につながる可能性があることを知っていたため、最も細かい関数にもキャッシュを有効にしました。これは、再構築は非常に速いものの、コールドビルドとメモリ使用量にはコストがかかることを意味します。より良いバランスを目指して取り組んでいます。興味深いのは、前述の高度なトレースを使用して非効率性を特定し、どの関数がキャッシュする価値が最も高いかをプロファイルできることです。

過去 3 か月間で、すでにかなりの改善が行われています。Next.js 15 RC 2 の Turbopack と 15 RC 1 の Turbopack を比較すると、これらの最適化の結果が見られます。

• メモリ使用量が平均 25-35% 削減。
• 数千モジュールを持つ大規模ページでの初回コンパイルが 30-50% 高速化。

Turbopack の安定版にはインメモリキャッシュが含まれていますが、これは開発サーバーの各再起動時に再構築する必要があり、大規模なアプリケーションでは 10 秒以上かかることがあります。私たちが非常に興奮しているのは、ディスク永続キャッシュのテストで得られている大きな成果です。これは、この記事の後半で詳しく説明します。

破壊的変更

独自のバンドラを構築した大きな動機は、webpack の既存の動作を可能な限り一致させる必要性でした。これは、当時どの既存のソリューションでも保証できなかったことです。これには、ファイルの解決方法や、一部の npm パッケージが使用する webpackIgnore コメントのような webpack の小規模な機能も含まれます。

残念ながら、Turbopack と関連する Next.js 実装を将来にわたって維持するために、いくつかの機能を削除せざるを得ませんでした。これらの機能は、webpack を使用する際には引き続きサポートされます。

変更が必要だった理由をいくつか紹介します。

webpack() 設定はサポートされていません。 Turbopack は webpack ではなく、設定オプションの構造は同じではありませんが、同じ機能の多くをサポートしています。具体的には、webpack ローダーと解決エイリアスのサポートを実装しました。コードを変換するほとんどの webpack ローダーは、そのままサポートされています。webpack 子コンパイラやファイル発行のようなエキゾチックなことを行う一部の webpack ローダーはサポートされていません。

.babelrc はコードを自動的に変換しません。 Turbopack はデフォルトで SWC を活用します。必要に応じて babel-loader を追加することはできますが、デフォルトが常に高速であり、アーキテクチャ的にも理にかなっていることを保証しています。他の最適化を処理するためには、.babelrc を設定していても、常に SWC を実行する必要があります。これは、webpack が常に acorn パーサーを実行してさらなる最適化を行うのと似ています。Turbopack で Babel の代わりに SWC を使用する場合、一度解析すれば、Turbopack 全体で同じ抽象構文木（AST）を活用できます。

一部のあまり使用されない CSS Modules の機能。 CSS の処理を PostCSS から Lightning CSS に切り替えました。Lightning CSS は、CSS トランスフォーム、ミニフィケーション、CSS Modules を標準でサポートする、大幅に高速な CSS コンパイラです。トレードオフとして、一部のあまり使用されない機能はサポートされていません。具体的には、:global および :local の擬似セレクタ（それらの関数形式 :global() および :local() は引き続き機能します）、@value、および :import / :export ICSS ルールです。また、他の CSS パーサーよりも厳格であり、コードのエラーを無視するのではなく、エラーを指摘します。

Lightning CSS の追加プロセスで、プロジェクトに貢献しました。例えば、CSS グリッドのプレフィックスを無効にするための CSS Modules のきめ細かなオプションや、CSS Modules の pure モードを実装しました。これにより、webpack の css-loader から移行する際に、CSS Modules の Lightning CSS を採用しやすくなります。また、サポートされていない CSS Modules 機能のエラーも改善しました。

Lightning CSS の作者でありメンテナーであるDevon Govett 氏 に、プロジェクトでの継続的な協力に感謝します。

実験的な機能。 Next.js での Turbopack の安定性に注力しているため、まず Next.js で利用可能な安定機能に焦点を当てることにしました。

完全なリストについては、ドキュメントページをご覧ください。

ロードマップ

Turbopack は長い道のりを歩んできましたが、まだ多くの作業が残っています。パイプラインにある 2 つのエキサイティングな機能は、永続キャッシュと本番ビルドです。ロールアウトは以下のような順序になると予想されます。

• 永続キャッシュ — 今後のマイナー
• ビルドベータ — 今後のマイナー
• ビルドリリース候補 — 今後のマイナー
• ビルド安定版 — 今後のマイナー
• 新しいアプリケーションの create-next-app で推奨 — 今後のマイナー
• Next.js のデフォルト（カスタム webpack 設定がない場合）— 今後のメジャー

webpack は Next.js に引き続き搭載されますが、Turbopack のメリットにより、ほとんどの Next.js アプリケーションがそれを使用したいと予想しています。Turbopack の本番ビルドが完了したら、一般的に使用されている webpack プラグインのサポートを開始します。

それ以降の Turbopack については、大まかな計画がありますが、この記事では、今後数年間で自信を持ってリリースできるものに限定しておきたいと思います。2 つの機能についてしか話していませんが、それらには多くのことが含まれているため、詳しく説明する価値があります。

永続キャッシュ（再起動を跨いだ Fast Refresh）

永続キャッシュとは、コンパイラが行った作業を、開発サーバーの再起動や複数の本番ビルドを跨いで再利用できるように保存することです。

要するに、Turbopack は同じ作業をやり直すことを避けます。再起動しても同様です。

Fast Refresh の高速化セクションで述べたように、Turbo Engine を構築して、作業を並列化およびキャッシュできるようにしました。これにより、ファイルが変更されたときに、そのファイル変更に関連する作業のみを実行すればよくなります。再起動やルートを開く際にも、この体験が得られたらどうでしょうか？以前の開発セッションですでに完了したコンパイル作業をやり直す必要がなくなります。Fast Refresh のメリットを、以前の開発セッションでコンパイルされたルートを開く場合や、next build を使用した複数のビルドを跨いで利用できるとしたらどうでしょうか？

まさに私たちが取り組んできたことです。Turbo Engine の新しいストレージレイヤーは、コンパイルされた作業をディスクに永続化し、開発サーバーの起動時またはビルド時に復元することをサポートします。

webpack は Next.js でデフォルトでディスクキャッシュが有効になっていますが、かなりの制限があります。キャッシュのかなりの部分をディスクから復元してメモリに読み込む必要があることが注目に値します。きめ細やかなキャッシュが十分にあるとは感じられませんでした。例えば、Vercel で大規模なアプリケーションを使用していたところ、キャッシュが十分に大きくなると、webpack のディスクキャッシュはすべてをゼロから行うよりも遅くなることがわかりました。

webpack の既存のディスクキャッシュとは異なり、Turbopack の永続キャッシュは、再起動を跨いで Fast Refresh するような体験を提供します。初回コンパイルに 10 秒以上かかったルートも、一度コンパイルされたらキャッシュから復元するのに 500ms 未満で済みます。

Turbopack を使用した next build でも同様の結果が見られ、変更されたファイルのみが再コンパイルされ、それ以外はそのままです。next build が行う複数のステップにおいて、時間の大部分はコンパイルとバンドリングの実行から TypeScript の型チェックの実行へと移行します。

永続キャッシュは現在進行中の作業であり、まず内部の Next.js アプリケーションで検証したいと考えています。初期結果は非常に有望であり、これらのホットパスを最適化し続けるにつれて、パフォーマンスはさらに向上します。

永続キャッシュが安定したら、デフォルトで有効になります。永続キャッシュを有効にしても、コードベースの変更は必要ありません。

永続キャッシュのテストに興味がある場合は、お問い合わせください！

本番ビルド

Turbopack による本番ビルドの安定化に向け、大幅な進捗があったことをお知らせできることを嬉しく思います。現在、本番テストの 96% が合格しており、これは大きな前進です。しかし、大規模な本番環境で Turbopack を自信を持って推奨できるようになるまでには、まだ作業が必要な領域があります。

本番ビルドは、開発とは異なる独自の課題を伴います。それらの課題に取り組んでいます。以下に、すでに最適化されたものと、まだ進行中のものについて説明します。

本番最適化

正確性

信頼性の高い本番ビルドには、正確性の確保が不可欠です。現在の状況は以下の通りです。

• CSS チャンキング: 進行中。この機能は、CSS をより小さなチャンクに分割するために重要であり、アプリケーションの各部分に必要な CSS のみロードできるようにすることで、ロード時間の短縮と CSS ルールの正確な順序付けを支援します。
• 本番 JS ランタイム: 完了。これにより、JavaScript ランタイムが本番環境で期待どおりに動作し、信頼性と安定性が提供されます。
• コンテンツベースのファイル名ハッシュ: まだ実装されていません。コンテンツベースのハッシュにより、コンテンツに基づいてファイル名を生成できるようになり、ブラウザでの長期キャッシュがより効率的になります。

UX パフォーマンス最適化

UX パフォーマンスは、高速なロード時間と効率的なリソース使用量を提供するための鍵となります。以下は、現在取り組んでいることです。

• JS ミニファイ: 完了。Next.js 13 以降、webpack と共に Next.js で既に利用されている SWC Minify を実装しました。
• CSS ミニファイ: 完了。Lightning CSS による CSS ミニファイは、スタイルシートのサイズを縮小するために重要です。
• グローバル情報（アプリケーション全体最適化）: 完了。Turbopack は、モジュール ID ハッシュなど、アプリケーション内のすべてのルートに関するデータが必要な最適化を適用できます。
• ツリーシェイキング: 部分的に完了。進行中。ツリーシェイキングのサポートは部分的ですが、未使用のコードを排除し、バンドルサイズを削減するのに役立ちます。しかし、ツリーシェイキングがまだ完全には効果的でないシナリオもあります。
  • 動的インポート: next/dynamic のような動的インポートのツリーシェイキングは制限されています。
  • 複雑なエクスポート: export { foo as "string name" } のような特定の種類の exoprt。
  • 非 ES モジュール: CommonJS モジュールはツリーシェイキングできません。
  • バレルファイル: バレルファイルからの再エクスポートは非効率的であり、副作用のないモジュールをスキップする際に制限があります。
  • フラグメンテーション: 場合によっては、ツリーシェイキングが過剰なフラグメントを作成し、非効率なバンドルにつながることがあります。
• モジュール ID ハッシュ（部分）: 進行中。モジュール ID ハッシュは部分的に実装されていますが、パフォーマンスの向上に取り組んでいます。完全に有効になると、最終的なバンドルサイズを削減するのに役立ちます。
• エクスポート名マンブリング: 進行中。これは、最終的なバンドルサイズを削減するためにエクスポートされた名前のサイズを縮小することを含みます。
• スコープホーイスティング: まだ実装されていません。スコープホーイスティングは、小さな JavaScript モジュールを単一のスコープにマージすることでバンドルサイズを削減し、オーバーヘッドを削減してパフォーマンスを向上させます。
• 本番最適化 JS チャンク: まだ実装されていません。JavaScript をチャンク化して重複を最小限に抑えることは、特に大規模なアプリケーションでのロードパフォーマンスを向上させるために不可欠です。

続報をお楽しみに

next dev --turbo を自信を持って推奨できることを嬉しく思います。これが開発体験をどのように向上させるか、皆様からのフィードバックをお待ちしております。ぜひ今すぐ試して、パフォーマンスの向上を実感してください。

これは始まりに過ぎません。永続キャッシュと本番ビルドが間もなく登場し、ワークフローにさらにスピードと信頼性をもたらします。

正確性の確保と、これまで以上に大規模なアプリケーションをシームレスに処理するためのパフォーマンス最適化に向けて、進捗状況を共有していきます。Turbopack を開発ビルドと本番ビルドの両方にとって最良のソリューションにするために、今後のリリースと改善にご期待ください。

コントリビューター

Turbopack のベータ版およびリリース候補段階で、テスト、問題報告、修正の検証に参加してくださった数千人の開発者に感謝いたします。

このリリースは、以下の方々によってもたらされました。

• Turbopack チーム: Alex、Benjamin、Donny、Justin、Leah、Maia、Niklas、OJ、Tim、Tobias、そしてWill。
• Next.js チーム: Andrew、Hendrik、Janka、Jiachi、Jimmy、Jiwon、JJ、Josh、Sam、Sebastian、Sebbie、Shu、そしてWyatt、Zack。
• Next.js Docs チーム: Delba、Rich、Ismael、そしてLee。