2024年10月21日月曜日
Turbopack開発環境が安定版になりました
投稿者
長い道のりでしたが、`next dev --turbo` が安定版となり、開発エクスペリエンスを高速化できるようになったことを発表できることを嬉しく思います。私たちはこれを vercel.com
8年前のリリース以来、Next.jsは週末の趣味プロジェクトから高度なエンタープライズアプリケーションまで、あらゆるものを構築するために使用されてきました。Next.jsが最初にリリースされたとき、webpackはフレームワークのバンドル基盤として明らかに最良の選択肢でしたが、時間の経過とともに、最新のWeb開発者のニーズに追いつくのに苦労するようになりました。私たちのコミュニティは、ルートの読み込み、コード変更の反映、本番ビルドのデプロイを待つ間、反復処理が非常に遅いことに気づき始めました。
webpackの最適化に多くの時間と労力を投資しましたが、ある時点で、費やした労力に見合うだけの改善が得られていないと感じました。React Server Componentsのような、既に本番環境にある多くのNext.jsアプリケーションと、私たちが計画していた将来のイノベーションをサポートできる新しい基盤が必要でした。
これらがこの新しいバンドラーの要件でした
- 破壊的変更を最小限にする
- App RouterとPages Routerの両方をサポートする
- あらゆる規模のコードベースのコンパイル時間を短縮する
- 本番環境とほぼ一致する開発ビルド
- 高度な本番環境の最適化（例：モジュール内ツリーシェイキング）
- Node.jsやブラウザなど、複数の環境をサポートするモジュールグラフ
- メンテナーと上級ユーザーのための完全な可観測性
私たちは当時存在するすべてのソリューションを評価しましたが、それぞれに私たちの要件と目標に合致しないトレードオフがあることがわかりました。Next.jsが今日必要とするものを正確に達成し、ロードマップを所有して、明日必要となるものを構築し、実験できる、ゼロから何かを設計することは理にかなっていました。これがTurbopackを作成する動機でした。
私たちはまず開発エクスペリエンスの最適化から始めました。それが今日、安定版としてリリースしているものです。VercelのアプリケーションでTurbopackを広範囲にわたってドッグフーディングしており、開発者のイテレーション速度が著しく向上しています。たとえば、大規模なNext.jsアプリである`vercel.com`では、次のような結果が得られました。
- ローカルサーバーの起動が最大**76.7%高速化**。
- Fast Refreshによるコードの更新が最大**96.3%高速化**。
- キャッシュなしの初期ルートコンパイルが最大**45.8%高速化**（Turbopackはまだディスクキャッシュを備えていません）。
この記事では、これらの結果をどのように達成したか、その他のハイライトとともに説明します。また、このリリースで何が期待できるかを明確にし、次に何が期待できるかのロードマップを提供します。
ハイライト...(以下省略：SVG情報は省略)
ルートの初期コンパイルの高速化...(以下省略：SVG情報は省略)
コミュニティから寄せられた最大の懸念事項の1つは、ルートの開発時の読み込みに時間がかかりすぎることでした。これはwebpackのコンパイル速度に起因していました。Next.jsは、必要なすべてのルートをコンパイルする前にコンパイルする必要がないように、ルートをオンデマンドでコンパイルします。これにより、初期起動が高速になり、メモリ使用量が削減されますが、それでも、1つのページが読み込まれるのを待つ間、イライラする可能性があります。
公平を期すために言うと、webpackのようなバンドラーは内部で多くのことを行っています。ルートを初めてコンパイルするとき、バンドラーは「エントリポイント」から開始します。Next.jsの場合、これは`page.tsx`と、`layout.tsx`や`loading.tsx`など、そのルートに関連するすべてのファイルの組み合わせです。これらのエントリポイントは解析され、ファイルに解決される`import`ステートメントが検出されます。これらのファイルはエントリポイントと同じように処理され、インポートが見つからなくなるまでこのサイクルが続きます。このプロセスにより、モジュールのグラフが構築されます。これは、TypeScript / JavaScriptモジュール（`node_modules`を含む）だけでなく、CSSファイル（グローバルとCSSモジュールの両方）、および`next/image`のインポートされた画像などの静的ファイルで構成されます。
すべてのモジュールが収集された後、モジュールグラフを使用して、多くの場合「チャンク」と呼ばれるJavaScriptのバンドルが作成されます。これらのチャンクは、サーバー（ビルド時またはランタイム）またはブラウザで実行されるコンパイラの出力です。
webpackは、複数の環境の出力を生成するグラフの作成をサポートしていないため、Next.jsでは少なくとも2つのwebpackコンパイラ（サーバー用とブラウザ用）を別々に実行する必要があります。 "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で大規模なNext.jsアプリケーションでTurbopackを使用すると、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を使用していることが挙げられます。これは、スタイルをページに挿入し、ページをリロードせずに高速リフレッシュを可能にします。 しかし、これは開発環境ではスタイルがJavaScriptによって挿入されることを意味し、スタイルが適用されていないコンテンツが一瞬表示される原因となります。 このスタイルが適用されていないコンテンツのフラッシュを回避するために、対策を講じています。 もう1つの例は、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をアルファ版として導入し、そのパフォーマンスの可能性をプレビューしました。初期の結果は promising でしたが、基本的な使用方法のみをサポートしていました。basePathなどの多くのNext.js機能はまだ実装されていませんでした。
翌年には、不足しているNext.jsとバンドル機能の追加に注力しました。コミュニティからのフィードバックに基づき、最も一般的なイテレーション速度の不満に対処できるように、next devエクスペリエンスに完全に焦点を当てることにしました。昨年のNext.js Confまでに、開発テストの90％が合格し、Vercelの開発者はすでに日常の開発でTurbopackを使用していました。
4月には、テストの99.8％が合格したNext.js 14.2を発表し、その後すぐに100％に達しました。それ以来、GitHubで報告された問題、特にnpmパッケージ、高速リフレッシュ、エラー位置の精度に関する問題に対処してきました。
確かに、安定版への道のりは長い時間がかかりましたが、それは主にNext.jsの広範なテストスイートによるものであり、安定性について高いハードルを設定しています。私たちは8年間かけてエッジケースを発見し、Turbopackでも合格する必要がある6,599の開発テストを追加しました。もう1つの要因は、webpackとはまったく異なるアーキテクチャでTurbopackを設計したことです。 webpackをRustに移植する方が簡単でしたが、私たちが達成したいパフォーマンスの向上は実現できませんでした。
Turbopackがすべてのテストに合格し、主要なnpmパッケージで検証され、アーリーアダプターからのフィードバックが対処されたため、安定版として認定する準備が整いました。
安定版とは正確には何ですか？。
Turbopackで動作することが確認されているwebpackローダーのリストを以下に示します
@svgr/webpackbabel-loaderurl-loaderfile-loaderraw-loadertsconfig-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のサポートについて調査する予定です。
パフォーマンス のTurbopackと 15 RC 1 のTurbopackを比較すると、これらの最適化の結果がわかります。
- **メモリ**使用量が平均25〜35％削減されました。
- 数千のモジュールを含む大きなページの**初期** **コンパイル**が30〜50％高速化されました。
Turbopackの安定バージョンには、開発サーバーを再起動するたびに再構築する必要があるメモリ内キャッシュが含まれており、大規模なアプリケーションでは10秒以上かかる場合があります。私たちが非常に興奮しているのは、オンディスク永続キャッシングをテストしたときに大きな成果が見られることです。これについては、この投稿の後半で説明します。
破壊的変更
独自のバンドラーを構築する大きな動機は、webpackの既存の動作に可能な限り一致させる必要があったことです。これは、当時の既存のソリューションでは保証できなかったことです。これには、ファイルの解決方法と、webpackの小さな機能（一部のnpmパッケージで使用されているwebpackIgnoreコメントなど）が含まれます。
残念ながら、Turbopackと関連するNext.jsの実装を将来にわたって活用するために、いくつかの機能を削除する必要がありました。これらの機能は、webpackを使用する場合でも引き続きサポートされます。
いくつかのハイライトがあります。変更が必要だった理由を詳しく見ていきましょう。
**webpack()設定はサポートされていません。** Turbopackはwebpackではなく、同じ構成オプション構造を持っていませんが、同じ機能の多くをサポートしています。具体的には、webpackローダーと解決エイリアスのサポートを実装しました。コードを変換するほとんどのwebpackローダーは、そのまま使用できます。webpackの子コンパイラやファイルの出力など、特殊な処理を行うwebpackローダーはサポートされていません。
**.babelrcはコードを自動的に変換しません。** TurbopackはデフォルトでSWCを活用しています。必要に応じてbabel-loaderを追加することはできますが、デフォルトが常に高速であり、アーキテクチャの観点からも理にかなっていることを確認しています。他の最適化を処理するために、.babelrcを構成した場合でも、常にSWCを実行する必要があります。これは、webpackがさらに最適化を行うために常にacornパーサーを実行する必要があるのと似ています。Babelの代わりにSWCをTurbopackで使用すると、一度解析して、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で推奨—将来のマイナーバージョン
- カスタムwebpack構成がない場合のNext.jsのデフォルト—将来のメジャーバージョン
webpackはNext.jsに残りますが、Turbopackの利点により、ほとんどのNext.jsアプリケーションがTurbopackを使用することを期待しています。本番ビルド用のTurbopackが完成したら、一般的に使用されるwebpackプラグインのサポート作業を開始します。
それ以降のTurbopackについては、大まかな計画がありますが、この投稿は近い将来に確実に提供できる内容に限定したいと思います。2つの機能についてのみ説明していますが、多くのことが含まれているため、詳しく調べてみる価値があります。
永続キャッシング（再起動時の高速リフレッシュ）
永続キャッシングとは、開発サーバーの再起動または複数本番ビルドにわたって再利用できるように、コンパイラによって行われた作業を保存することを意味します。
つまり、Turbopackは再起動しても同じ作業を繰り返すことを回避します。
「高速リフレッシュ」セクションで述べたように、Turbo Engineを構築して、作業を並列化およびキャッシュできるようにしました。そのため、ファイルを変更するたびに、そのファイル変更に関連する作業のみを実行する必要があります。再起動時やルートを開くときに、このエクスペリエンスを提供できるとしたらどうでしょうか。以前の開発セッションで行われたコンパイル作業をやり直す必要はありません。以前の開発セッションでコンパイルされたルートを開いたり、next buildで複数のビルドを実行したりする場合に、高速リフレッシュの利点を得ることができるとしたらどうでしょうか。
まさに、私たちが取り組んできたのは、Turbo Engineの新しいストレージレイヤーであり、コンパイル作業をディスクに永続化し、開発サーバーの起動時または再ビルド時に復元することをサポートします。
webpackはNext.jsでデフォルトでディスクキャッシングが有効になっていますが、かなりの制限があります。キャッシュの大部分をディスクから復元してメモリに読み込む必要があることに注意してください。きめ細かいキャッシュがあるとは感じられませんでした。たとえば、Vercelの大規模なアプリケーションでは、キャッシュが十分に大きくなった場合、webpackディスクキャッシュが最初からすべての作業を行うよりも遅くなることさえあることがわかりました。
Webpackによる既存のディスクキャッシュとは異なり、Turbopackの永続キャッシュは、再起動後もFast Refreshのように感じられます。初回のコンパイルに10秒以上かかるルートは、一度コンパイルされると、キャッシュからの復元に500ミリ秒未満しかかかりません。
Turbopackを使用したnext buildでも同様の結果が得られました。変更されたファイルのみが再コンパイルされ、他のすべてはそのままです。next buildの複数の手順において、これにより、コンパイルとバンドリングの実行に費やされる時間のほとんどが、TypeScriptの型チェックの実行に移行します。
永続キャッシュは現在開発中であり、最初に社内のNext.jsアプリケーションを使用して検証したいと考えています。初期の結果は非常に有望であり、これらのホットパスを最適化し続けるにつれて、パフォーマンスは時間の経過とともにさらに向上します。
永続キャッシュが安定したら、デフォルトで有効になります。永続キャッシュを有効にしても、コードベースを変更する必要はありません。
永続キャッシュのテストにご興味がある方は、ご連絡ください！
本番ビルド
Turbopackによる安定した本番ビルドに向けて、大きな進歩を遂げていることをお知らせします。現在、本番テストの96%が合格しており、これは大きな前進です。ただし、Turbopackを大規模な本番環境に自信を持って推奨できるようになるまでには、まだ作業が必要な領域があります。
本番ビルドは、開発とは異なる独自の課題をもたらします。私たちはそれらに積極的に取り組んでいます。以下では、すでに最適化されているものと、まだ進行中のものについて説明します。
本番環境の最適化
正確性（SVG省略）
信頼性の高い本番ビルドには、正確性を確保することが不可欠です。現在のステータスは次のとおりです。
- CSSチャンキング：進行中。この機能は、CSSを小さなチャンクに分割するために不可欠であり、アプリケーションの各部分に必要なCSSのみを読み込むことができます。これにより、読み込み時間が短縮され、CSSルールの正しい順序が確保されます。
- 本番JSランタイム：完了。これにより、JavaScriptランタイムが本番環境で期待どおりに動作し、信頼性と安定性が提供されます。
- コンテンツベースのファイル名ハッシュ：未実装。コンテンツベースのハッシュを使用すると、コンテンツに基づいてファイル名を生成できるため、ブラウザでより効率的な長期キャッシュが可能になります。
UXパフォーマンスの最適化（SVG省略）
UXパフォーマンスは、高速な読み込み時間と効率的なリソース使用を実現するための鍵です。現在取り組んでいる内容は次のとおりです。
- JS縮小：完了。Next.js 13以降、webpackでNext.jsがすでに使用しているSWC Minifyを実装しました。
- CSS縮小：完了。スタイルシートのサイズを縮小するために重要なLightning CSSを使用したCSS縮小。
- グローバル情報（アプリケーション全体の最適化）：完了。Turbopackは、アプリケーションのすべてのルートに関するデータ（モジュールIDハッシュなど）を必要とする最適化を適用できます。
- ツリーシェイキング：部分的に完了。進行中。未使用のコードを削除し、バンドルサイズを削減するのに役立つツリーシェイキングを部分的にサポートしています。ただし、ツリーシェイキングがまだ完全には効果的でないシナリオがあります。
- 動的インポート：
next/dynamicを使用するなど、動的インポートのツリーシェイキングは制限されています。 - 複雑なエクスポート：
export { foo as "string name" }などの特定の種類のエクスポート。 - 非ESモジュール：CommonJSモジュールはツリーシェイクできません。
- バレルファイル：バレルファイルからの再エクスポートは非効率的であり、副作用のないモジュールをスキップする際に制限があります。
- 断片化：場合によっては、ツリーシェイキングによって断片が多すぎて、バンドルが非効率になる可能性があります。
- 動的インポート：
- モジュールIDハッシュ（部分的）：進行中。モジュールIDハッシュは部分的に実装されていますが、パフォーマンスの向上に取り組んでいます。完全に有効になると、最終的なバンドルサイズを削減するのに役立ちます。
- エクスポート名マングリング：進行中。これには、最終的なバンドルサイズを削減するために、エクスポートされた名前のサイズを削減することが含まれます。
- スコープホイスト：未実装。スコープホイストは、小さなJavaScriptモジュールを単一のスコープにマージすることにより、バンドルサイズを削減するのに役立ちます。これにより、オーバーヘッドが削減され、パフォーマンスが向上します。
- 本番環境向けに最適化されたJSチャンキング：未実装。重複を最小限に抑えるためにJavaScriptをチャンクすることは、特に大規模なアプリケーションの場合、読み込みパフォーマンスを向上させるために不可欠です。
乞うご期待（SVG省略）
next dev --turboを自信を持っておすすめします。開発エクスペリエンスがどのように向上するか、ぜひお聞かせください。今日試してみて、パフォーマンスの向上を自分の目で確かめてください。
これはほんの始まりです。永続キャッシュと本番ビルドが間近に迫っており、ワークフローの速度と信頼性がさらに向上します。
最大規模のアプリケーションでもシームレスに処理できるように、正確性を確保し、パフォーマンスを最適化するために、進捗状況に応じてさらに更新情報を共有します。今後のリリースと改善にご期待ください。私たちは、Turbopackを開発ビルドと本番ビルドの両方にとって最適なソリューションにするために取り組んでいます。
貢献者（SVG省略）
Turbopackのベータ版とリリース候補フェーズ全体で、テスト、問題の報告、修正の検証にご参加いただいた数千人の開発者の皆様に感謝申し上げます。
このリリースは、次の皆様によって実現されました。