長い道のりでしたが、next dev --turbo がついに安定版となり、開発体験を高速化する準備が整ったことを嬉しく思います。私たちはvercel.com、nextjs.org、v0 やその他のアプリケーションでこれを使用し、素晴らしい結果を得ています。
8年前のリリース以来、Next.js は週末の趣味プロジェクトから洗練されたエンタープライズアプリケーションまで、あらゆるものの構築に使用されてきました。Next.js が最初にリリースされたとき、webpack はフレームワークのバンドリング基盤として明らかに最良の選択でしたが、時間の経過とともに現代のウェブ開発者のニーズに追いつくのが難しくなりました。私たちのコミュニティは、ルートの読み込み待ち、コード変更の反映、プロダクションビルドのデプロイなどで、反復作業が非常に遅いと感じ始めていました。
私たちは webpack の最適化に多くの時間と努力を費やしましたが、ある時点で、投入した努力に対して十分な改善が得られていないと感じました。今日すでにプロダクションで稼働している多くの Next.js アプリケーションと、React Server Components のような将来のイノベーションをサポートできる新しい基盤が必要でした。
この新しいバンドラーに対する私たちの要件は以下の通りでした：
- 最小限の破壊的変更
- App Router と Pages Router の両方のサポート
- あらゆる規模のコードベースでの高速なコンパイル時間
- プロダクション環境に近い開発ビルド
- 高度なプロダクション最適化（例：モジュール内のツリーシェイキング）
- Node.js やブラウザなどの複数環境をサポートするモジュールグラフ
- メンテナーや上級ユーザー向けの完全な可観測性
当時利用可能なすべてのソリューションを評価しましたが、それぞれに私たちの要件と目標に合わないトレードオフがあることがわかりました。Next.js が今日必要とするものを正確に達成し、明日必要となるものを構築し実験できるようにロードマップを所有するため、一から何かを設計することが理にかなっていると判断しました。これが Turbopack を作成する動機となりました。
私たちは開発体験の最適化から始め、それが今日安定版としてリリースするものです。Vercel のアプリケーションで Turbopack を広範囲に使用し、開発者の反復速度が顕著に向上しました。例えば、大規模な Next.js アプリケーションである vercel.com では、以下の結果が見られました：
- ローカルサーバーの起動が最大 76.7% 高速化
- Fast Refresh によるコード更新が最大 96.3% 高速化
- キャッシュなしでの初期ルートコンパイルが最大 45.8% 高速化（Turbopack はまだディスクキャッシュを持っていません）
この記事では、これらの結果を達成した方法とその他のハイライトについて説明します。また、このリリースから何を期待すべきかを明確にし、今後のロードマップを提供します。
ハイライト
ルートの初期コンパイルの高速化
コミュニティから最も多く聞かれた問題の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つの別々のコンパイラ（サーバー用とブラウザ用）を実行する必要があります。まずサーバーモジュールグラフをコンパイルし、"use client" へのすべての参照を見つける必要があります。サーバーがビルドされると、そのグラフを走査してブラウザコンパイラの関連するエントリーポイントを作成します。これは別の webpack コンパイラであるため、クライアントとサーバー間で同じコードを2回解析するなどのオーバーヘッドがあります。
Turbopack では、複数のコンパイラを実行しそれらを調整するオーバーヘッドを削除することを目指しました。解決策は、コンパイラが複数の異なる出力ターゲットを認識できるようにすることでした。内部的には、これらはターゲット「トランジション」と呼ばれます。インポートをサーバーからブラウザへのトランジション、またはブラウザからサーバーへのトランジションとしてマークできます。これにより、Turbopack は Server Components と Client Components、および Client Components からインポートされた Server Functions を効率的にバンドルできます。
パフォーマンスの改善に加えて、単一のコンパイラで単一パスで複数の環境を処理できることは、信頼性とデバッグの利点もあります。Next.js で2つの別々のコンパイラプロセス間で調整する必要がなくなったからです。
webpack と Turbopack のもう1つの大きな違いは、Turbopack が複数の CPU 間で作業を並列化できることです。webpack では、SWC を使用した TypeScript/JavaScript 変換ステップのみが並列化されます。
webpack は CPU 間での並列化をサポートしていません。効果的に並列化するには、データがスレッド間で簡単にアクセス可能でなければならないためです。webpack は大きな JavaScript オブジェクトを多用する方法で構築されており、高価なシリアル化とデシリアル化なしではスレッド間で簡単に共有できません。このオーバーヘッドは、複数の CPU を活用するパフォーマンス改善をしばしば無効にします。Turbopack は Rust で書かれており、同じ制限がなく、最初から並列化を念頭に置いて構築されました。
また、ファイルシステムの読み書きの高速化、モジュール解決の高速化、副作用のないモジュールでの作業のスキップによってパフォーマンス向上を達成できました。
大規模な Next.js アプリケーションである vercel.com で Turbopack を使用すると、webpack を使用した Next.js と比較して初期コンパイルが最大 45.8% 高速化されました。
Fast Refresh の高速化
Fast Refresh は、バンドラーが現在ブラウザで表示しているルートへの変更を伝播するために使用するシステムで、Hot Module Replacement (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 アプリケーションのインタラクティブなホットリロードを数十ミリ秒で提供します。このアーキテクチャは、webpack、Salsa、Parcel、Adapton、Rust コンパイラのクエリシステム を含む10年以上の研究と先行技術に基づいています。
現在の 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 を使用してトレースを検査できるサーバーを起動できます。トレースビューアの簡単なビデオ概要はこちらで利用可能です。
コンパイル時間の不安定性の低減
webpack を使用した Next.js では、コンパイル時間が十分に透明でないことがよくありました。ある場合にはページを開くのに10秒かかり、別の場合には20秒かかることがあります。キャッシュが存在する場合でも、一貫した結果を生み出すのに十分な影響がないことがあります。キャッシュなしのコンパイルでも、ばらつきが見られました。
Turbopack の基礎となるアーキテクチャにより、コンパイル時間のばらつきがより一貫性を持つようになりました。ルートのコンパイル時間は数パーセントしか変動せず、コンパイラのパフォーマンスを一貫して最適化できます。
プロダクション環境に近い開発ビルド
webpack でコンパイル速度を最適化するためには、開発環境とプロダクション環境が異なるというトレードオフを受け入れる必要がありました。そのようなトレードオフの例として、style-loader を使用しています。これはスタイルをページに注入し、ページをリロードせずに Fast Refreshing できるようにします。しかし、これによりスタイルが JavaScript によって開発環境で注入されるため、スタイルが適用されていないコンテンツが一瞬表示される（FOUC）ことがあります。私たちはこの FOUC を回避するため、実際には表示されないようにしています。もう1つの例は、Next.js が webpack で 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 機能はまだ実装されていませんでした。
その後1年間、不足している Next.js とバンドリング機能の追加に注力しました。コミュニティのフィードバックに基づき、最も一般的な反復速度の不満に対処するため、next dev 体験に完全に焦点を当てることに決めました。昨年の Next.js Conf までに、開発テストの90%が合格し、Vercel の開発者はすでに日常的な開発で Turbopack を使用していました。
4月には、テストの99.8%が合格する Next.js 14.2 を発表し、すぐに100%に達しました。それ以来、GitHub で報告された問題、特に npm パッケージ、Fast Refresh、エラー位置の正確性に関する問題に対処しました。
確かに、安定化への道のりは長い時間がかかりましたが、それは主に Next.js の広範なテストスイートによるもので、安定性に対する高い基準を設けています。8年かけてエッジケースを発見し、Turbopack でも合格する必要がある6,599の開発テストを追加しました。追加の要因として、Turbopack を webpack とは完全に異なるアーキテクチャで設計したことが挙げられます。単純に 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/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が安定した後に対応予定。
パフォーマンス
今回リリースしたバージョンのパフォーマンスはwebpackよりも大幅に優れていますが、これが最終的な数値ではないことを強調しておきます。私たちはKent Beckの有名な格言「まず動くようにせよ。次に正しくせよ。最後に速くせよ」に従ってきました。これまで、Next.jsとwebpackの成熟した機能範囲に追いつく必要があったため、大部分の努力を「まず動くように」する段階に費やしてきました。
Turbopackはそのキャッシュインフラに大きく依存していますが、ご存知の通り、キャッシュはソフトウェア開発における2大難問の1つです。経験上、キャッシュ用に明示的に構築されていないアーキテクチャにキャッシュを追加すると望ましくない結果を招く可能性があるため、最も細かい関数レベルまでキャッシュを有効にしました。これは、コールドビルドとメモリ使用量を犠牲にしてリビルドを極めて高速化することを意味し、より良いバランスを目指して作業中です。興味深いことに、前述の高度なトレーシングを使用して非効率性を発見し、キャッシュする価値が最も高い関数をプロファイリングできます。
過去3ヶ月間で既に大幅な改善を行いました。Next.js 15 RC 2のTurbopackと15 RC 1の比較から、これらの最適化の結果がわかります：
- メモリ使用量が平均25-35%減少
- 数千のモジュールを持つ大規模ページでの初期コンパイルが30-50%高速化
Turbopackの安定版には、開発サーバーを再起動するたびに再構築が必要なメモリ内キャッシュが含まれており、大規模なアプリケーションでは10秒以上かかる場合があります。現在非常に期待しているのは、ディスク永続キャッシュのテストで見られる大きな成果で、この記事の後半で詳しく説明します。
破壊的変更
独自のバンドラーを構築する大きな動機となったのは、webpackの既存の動作を可能な限り再現する必要性でした。当時、既存のソリューションではこれを保証できませんでした。これにはファイルの解決方法や、一部のnpmパッケージが使用するwebpackIgnoreコメントのようなwebpackの小さな機能も含まれます。
残念ながら、Turbopackと関連するNext.js実装を将来にわたって堅牢にするため、いくつかの機能を削除する必要がありました。これらの機能はwebpackを使用する場合には引き続きサポートされます。
主な変更点とその理由を説明します：
webpack()設定はサポートされていません。 Turbopackはwebpackではなく、同じ設定オプション構造を持っていませんが、多くの同じ機能をサポートしています。具体的にはwebpackローダーとresolveエイリアスのサポートを実装しています。コードを変換するほとんどのwebpackローダーはそのままサポートされています。webpack子コンパイラやファイル出力など特殊な処理を行う一部のローダーはサポートされていません。
.babelrcは自動的にコードを変換しません。 TurbopackはデフォルトでSWCを利用します。必要に応じてbabel-loaderを追加することは可能ですが、デフォルト設定が常に高速であり、アーキテクチャ的にも理にかなっていることを保証しています。.babelrcを設定した場合でも、他の最適化を処理するためにSWCを実行する必要があります。これはwebpackがさらなる最適化を行うために常にacornパーサーを実行する必要があるのと似ています。TurbopackでBabelの代わりにSWCを使用すると、一度パースした抽象構文木（AST）をTurbopack全体でエンドツーエンドで活用できます。
一部の使用頻度の低いCSS Modules機能。 CSSの処理をPostCSSからLightning CSSに切り替えました。Lightning CSSは大幅に高速なCSSコンパイラで、CSS変換、ミニファイ、CSS Modulesをデフォルトでサポートしています。その代償として、一部の使用頻度の低い機能がサポートされていません。具体的には:globalおよび:local擬似セレクタ（関数形式の:global()と:local()は動作します）、@value、:import / :export ICSSルールです。また、他のCSSパーサーよりも厳格で、コードのエラーを無視せずに指摘します。
Lightning CSSの追加過程で、私たちはこのプロジェクトに貢献しました。例えば、CSSグリッドのプレフィックス無効化やCSS Modulesのpureモードのための細かいオプションを実装しました。これにより、webpackのcss-loaderから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が完成したら、一般的に使用されるwebpackプラグインのサポートに取り掛かります。
それ以降のTurbopackに関する大まかな計画はありますが、この記事では近い将来に確実に提供できる内容に限定したいと思います。2つの機能だけを話題にしているように見えますが、その裏には多くの作業が含まれているため、詳しく掘り下げる価値があります。
永続的キャッシュ（再起動を跨ぐFast Refresh）
永続的キャッシュとは、コンパイラが行った作業を保存し、開発サーバーの再起動や複数のプロダクションビルド間で再利用できるようにすることを意味します。
簡単に言えば、Turbopackは再起動後も同じ作業を繰り返す必要がありません。
「より高速なFast Refresh」セクションで述べたように、Turbo Engineを構築して作業を並列化およびキャッシュできるようにしました。これにより、ファイルを変更したときに、その変更に関連する作業のみを実行すればよくなります。この体験を再起動時やルートを開くときに提供できたらどうでしょうか？前回の開発セッションで既に行ったコンパイル作業を繰り返す必要がなくなります。next buildを使用した複数のビルド間や、前回の開発セッションでコンパイルされたルートを開くときにFast Refreshの利点を得られるとしたら？
まさにこれが私たちが取り組んでいる内容です：Turbo Engine用の新しいストレージレイヤーで、コンパイル作業をディスクに永続化し、開発サーバーを起動したり再度ビルドしたりするときに復元できるようにします。
Next.jsではwebpackのディスクキャッシュがデフォルトで有効になっていますが、いくつかの制限があります。特に、機能するためにはキャッシュの大部分をディスクから復元してメモリに読み込む必要があります。十分に細かいキャッシュがないと感じられることがよくあります。例えば、Vercelの大規模アプリケーションでは、キャッシュが十分に大きくなると、webpackのディスクキャッシュが最初からすべての作業を行うよりも遅くなることさえありました。
webpackの既存のディスクキャッシュとは異なり、Turbopackの永続キャッシュは真に再起動を跨ぐFast Refreshのような体験を提供します。初回コンパイルに10秒以上かかるルートも、一度コンパイルされればキャッシュから500ms未満で復元できます。
next buildでも同様の結果が見られ、変更されたファイルのみが再コンパイルされ、他のすべてはそのまま維持されます。next buildが行う複数のステップにおいて、これにより、コンパイルとバンドリングに費やされる時間の大部分がTypeScriptの型チェック実行に移行します。
永続的キャッシュは現在進行中の作業であり、まず内部のNext.jsアプリケーションで検証したいと考えています。初期結果は非常に有望で、これらのホットパスを最適化し続けることで、パフォーマンスはさらに向上していくでしょう。
永続キャッシュが安定したら、デフォルトで有効になります。永続キャッシュを有効にするためにコードベースの変更は必要ありません。
永続キャッシュを試してみたい方は、ぜひご連絡ください！
プロダクションビルド
Turbopackを使用した安定したプロダクションビルドに向けて大幅な進展があったことをお知らせできることを嬉しく思います。現在、プロダクションテストの96%が合格しており、これは大きな前進です。ただし、大規模なプロダクション環境でTurbopackを自信を持って推奨できるようになる前に、まだ作業が必要な領域が残っています。
プロダクションビルドは開発とは異なる独自の課題をもたらし、私たちはそれらに対処するために積極的に取り組んでいます。以下では、既に最適化された内容と、まだ進行中の内容について説明します。
プロダクション最適化
正確性
信頼性の高いプロダクションビルドには正確性の確保が不可欠です。現在の状況は以下の通りです：
- CSSチャンキング: 進行中。この機能はCSSを小さなチャンクに分割し、アプリケーションの各部分に必要なCSSのみをロードできるようにするために重要です。これによりロード時間が短縮され、CSSルールの正しい順序付けが保証されます。
- プロダクションJSランタイム: 完了。これにより、JavaScriptランタイムがプロダクション環境で期待通りに動作し、信頼性と安定性が提供されます。
- コンテンツベースのファイル名ハッシュ: 未実装。コンテンツベースのハッシュにより、コンテンツに基づいてファイル名を生成できるようになり、ブラウザでの長期的なキャッシュがより効率的になります。
UXパフォーマンス最適化
UXパフォーマンスは、高速な読み込み時間と効率的なリソース使用を実現するための鍵です。以下に私たちが取り組んでいる内容を示します：
- JSミニファイ: 完了。Next.js 13以降でwebpackと共に使用されているSWCミニファイを実装しました。
- CSSミニファイ: 完了。スタイルシートのサイズ削減に重要なLightning CSSによるCSSミニファイを実装。
- グローバル情報（アプリケーション全体の最適化）: 完了。Turbopackはアプリケーション内の全ルートに関するデータを必要とする最適化（例：モジュールIDハッシュ化）を適用可能。
- ツリーシェイキング: 一部完了。進行中。未使用コードの削減やバンドルサイズ縮小に役立つツリーシェイキングを部分的にサポート。ただし、以下のシナリオでは完全に効果的ではありません：
- 動的インポート:
next/dynamicのような動的インポートでは制限あり - 複雑なエクスポート:
export { foo as "string name" }のような特殊なエクスポート形式 - 非ESモジュール: CommonJSモジュールはツリーシェイク不可
- バレルファイル: バレルファイルからの再エクスポートは非効率で、副作用のないモジュールのスキップに制限あり
- フラグメンテーション: 場合によってはツリーシェイキングが過剰なフラグメントを生成し、非効率なバンドルを生むことがある
- 動的インポート:
- モジュールIDハッシュ化（一部）: 進行中。モジュールIDハッシュ化は部分的に実装済みですが、パフォーマンス改善を継続中。完全実装により最終バンドルサイズ削減が可能に。
- エクスポート名マングリング: 進行中。エクスポート名のサイズを縮小し、最終バンドルサイズを削減。
- スコープホイスティング: 未実装。小さなJavaScriptモジュールを単一スコープに統合することで、オーバーヘッド削減とパフォーマンス向上を実現。
- プロダクション向けJSチャンキング最適化: 未実装。重複を最小限に抑えたJavaScriptチャンキングは、特に大規模アプリケーションの読み込み性能向上に不可欠。
今後の展開にご期待ください
私たちは自信を持ってnext dev --turboの使用を推奨できることを嬉しく思っており、皆さんの開発体験がどのように改善されるかを楽しみにしています。ぜひ今日試して、パフォーマンス向上を実感してください。
これは始まりに過ぎません - 永続的キャッシュやプロダクションビルドが間近に迫っており、ワークフローにさらなる速度と信頼性をもたらします。
最大規模のアプリケーションでもシームレスに動作するよう、正確性の確保とパフォーマンス最適化に向けて進捗を続ける中で、さらなるアップデートを共有していきます。開発ビルドとプロダクションビルドの両方においてTurbopackを最適なソリューションとするため、今後のリリースと改善にご期待ください。
貢献者
Turbopackのベータ版およびリリース候補版のテスト、問題報告、修正検証に参加してくださった数千人の開発者の皆様に感謝申し上げます。
このリリースは以下のメンバーによってもたらされました：