Next.js 12
2021年10月26日(火)に投稿
投稿者:Connor Davis @ connordav_is、DongYoon Kang @ kdy1dev、Gerald Monaco @ devknoll、Javi Velasco @ javivelasco、Jiachi Liu @ huozhi、JJ Kasper @ ijjk、Kara Erickson @ karaforthewin、Maia Teegarden @ padmaia、Shu Ding @ shuding、Steven @ styfle、Tim Neutkens @ timneutkens、Tobias Koppers @ wSokra
Next.js Confで発表したとおり、Next.js 12は史上最大のリリースです:
- Rustコンパイラ:Fast Refreshが約3倍高速、ビルドが約5倍高速
- Middleware(ベータ版):設定よりもコードでNext.jsの完全な柔軟性を実現
- React 18サポート:ネイティブNext.js APIとSuspenseをサポート
<Image /> AVIFサポート:20%小さい画像をオプトイン
- Bot対応ISR Fallback:Webクローラー向けのSEO最適化
- ネイティブESモジュールサポート:標準化されたモジュールシステムとの整合
- URL Imports(アルファ版):任意のURLからパッケージをインポート、インストール不要
- React Server Components(アルファ版):SSRストリーミングを含む、今すぐお試しください
npm i next@latestを実行して今すぐアップデートしてください。
Rustコンパイラによる高速ビルドとFast Refresh
すべてのNext.jsアプリケーションの本番ビルドを高速化し、ローカル開発で即座にフィードバックを得られるようにしたいと考えています。
Next.js 12には、ネイティブコンパイレーションを活用する全く新しいRustコンパイラが含まれています。私たちのRustコンパイラは、次世代の高速ツールのためのオープンプラットフォームであるSWC上に構築されています。
バンドリングとコンパイレーションを最適化し、ローカルでのリフレッシュが約3倍高速、本番ビルドが約5倍高速になりました。
その他の改善と機能には以下が含まれます:
大規模なNext.jsコードベースでの新しいRustコンパイラの使用結果。
- 大規模コードベースのさらなる速度向上:世界最大級のNext.jsコードベースでRustコンパイラを検証しました。
- パフォーマンスの可視性向上:Next.jsは、コンパイルされたモジュールとファイルの数を含む、クライアントとサーバーの両方のコンパイレーションのFast Refreshタイミングをコンソールに出力するようになりました。
- 基盤となるwebpackの改善:Fast Refreshの最適化やオンデマンドエントリの信頼性向上など、webpackに多数の改善を加えました。
Rustを使用したコンパイレーションはBabelより17倍高速で、Next.js 12でデフォルトで有効になり、JavaScriptとTypeScriptファイルの変換を置き換えます。これは、Next.jsのBabel変換をRustに移植する必要があることを意味し、styled-jsx変換の実装に使用される全く新しいRust製CSSパーサーも含まれています。
新しいRustコンパイラは後方互換性があります。既存のBabel設定がある場合、自動的にオプトアウトされます。styled-components、emotion、relayなどの人気ライブラリの解析を近日中に移植する予定です。
カスタムBabelセットアップを使用している場合は、設定を共有してください。
Rustコンパイラをミニフィケーションにオプトインすることもできます。これはTerserより7倍高速です。ミニフィケーションは、数年にわたるインフラストラクチャを置き換えるため、十分に検証されるまではオプトインです。
module.exports = {
swcMinify: true,
};
SWCの作成者であるDongYoon Kangと、ParcelのコントリビューターであるMaia Teegardenの採用に加えて、Rustエコシステムへの投資を続けています。Rustでの作業経験がある方は、ぜひチームに参加してください。
詳細については、Next.js Confのデモをご覧ください。
Middlewareの紹介
Middlewareにより、設定よりもコードを使用できるようになります。これにより、リクエストが完了する前にコードを実行できるため、Next.jsで完全な柔軟性が得られます。
ユーザーの受信リクエストに基づいて、リライト、リダイレクト、ヘッダーの追加、さらにはHTMLのストリーミングによってレスポンスを変更できます。
MiddlewareはNext.js内で完全な柔軟性を提供します。
Middlewareは、一連のページでロジックを共有するあらゆることに使用できます:
- 認証
- Bot保護
- リダイレクト
- リライト
- フィーチャーフラグとA/Bテスト
- 高度なi18nルーティング要件
- その他多数!
Middlewareは、fetchなどの標準Web APIをサポートする厳密なランタイムを使用します。これはnext startを使用してそのまま動作し、Edge Middlewareを使用するVercelなどのEdgeプラットフォームでも動作します。
Next.jsでMiddlewareを使用するには、pages/_middleware.jsファイルを作成できます。この例では、標準Web API Response(MDN)を使用します:
export function middleware(req, ev) {
return new Response('Hello, world!');
}
詳細については、Next.js Confのデモをご覧いただき、ドキュメントをご確認ください。
React 18への準備
React 18では、Suspense、更新の自動バッチング、startTransitionなどのAPI、およびReact.lazyをサポートするサーバーレンダリング用の新しいストリーミングAPIなどの機能が追加されます。
FacebookのReactチームと密接に協力して、React 18が安定版リリースに向けて進む中、Next.jsをReact 18に対応させています。
Next.js 12では、実験的フラグの下でこれらの機能を今すぐ試すことができます。
npm install react@alpha react-dom@alpha
サーバーサイドストリーミング
React 18の並行機能には、サーバーサイドSuspenseとSSRストリーミングサポートの組み込みサポートが含まれています。これにより、HTTPストリーミングを使用してページをサーバーレンダリングできます。
これはNext.js 12の実験的機能ですが、有効にすると、SSRはMiddlewareと同じ厳密なランタイムを使用します。
有効にするには、実験的フラグconcurrentFeatures: trueを使用します:
module.exports = {
experimental: {
concurrentFeatures: true,
},
};
React Server Components
React Server Componentsにより、コンポーネント自体を含むすべてをサーバー上でレンダリングできます。これは、サーバー上でHTMLを事前生成するサーバーサイドレンダリングとは根本的に異なります。
Server Componentsでは、クライアントサイドJavaScriptが不要で、ページレンダリングが高速になります。これにより、サーバーレンダリングの最良の部分とクライアントサイドのインタラクティビティを組み合わせて、アプリケーションのユーザーエクスペリエンスが向上します。
module.exports = {
experimental: {
concurrentFeatures: true,
serverComponents: true,
},
};
Next.jsでは、すべてJSXとして表現されたコンポーネントレベルでのデータフェッチが可能になりました。React Server Componentsを使用することで、物事を簡素化できます。getServerSidePropsやgetStaticPropsなどの特別な関数はもう必要ありません。これは、データフェッチをコンポーネントと同じ場所に配置するReact Hooksモデルと整合します。
Next.jsページの名前を.server.jsに変更してServer Componentを作成し、Server Components内でクライアントコンポーネントを直接インポートできます。これらのクライアントコンポーネントはハイドレートされてインタラクティブになるため、アップボートなどの機能を追加できます。
現在、Next.jsでサーバーサイドSuspense、選択的ハイドレーション、ストリーミングレンダリングに取り組んでおり、今後のブログ投稿で進捗を共有します。
React 18とServer Componentsに関する作業について、Google AuroraチームのコラボレーターであるKara EricksonとGerald Monacoに特別な感謝を表します。
詳細については、Next.js Confのデモをご覧いただき、ドキュメントをご確認ください。
ESモジュールサポートとURL Imports
ESモジュールは、JavaScriptに公式の標準化されたモジュールシステムをもたらします。すべての主要ブラウザとNode.jsでサポートされています。この標準により、パッケージサイズとJavaScriptバンドルが小さくなり、最終的により良いユーザーエクスペリエンスにつながり、Webエコシステムが前進します。
JavaScriptエコシステムがCommon JS(古い標準)からESモジュールに移行する中、不要な破壊的変更なしに開発者がこれらの改善を段階的に採用できるよう支援することをお約束します。
Next.js 11.1から、CommonJSモジュールよりもESモジュールを優先する実験的サポートを追加しました。Next.js 12では、これがデフォルトになりました。CommonJSのみを提供するNPMモジュールのインポートは引き続きサポートされています。
URL Imports
Next.js 12には、URL経由でESモジュールをインポートする実験的サポートが含まれており、インストールや別のビルドステップは不要です。
URL importsにより、URLを通じて任意のパッケージを直接使用できます。これにより、Next.jsはリモートHTTP(S)リソースをローカル依存関係とまったく同じように処理できます。
URL importが検出されると、Next.jsはリモートリソースを追跡するためにnext.lockファイルを生成します。URL importsはローカルにキャッシュされ、オフラインでも作業できることを保証します。
Next.jsはクライアントとサーバーの両方のURL importsをサポートします。
オプトインするには、next.config.js内で許可されたURLプレフィックスを追加します:
module.exports = {
experimental: {
urlImports: ['https://cdn.skypack.dev'],
},
};
その後、URLから直接モジュールをインポートできます:
import confetti from 'https://cdn.skypack.dev/canvas-confetti';
Framerなどのノーコードやデザインツールを含む、ESモジュールを提供する任意のCDNが動作します:
- Skypack
- esm.sh
- jsDelivr
- JSPM
- unpkg
詳細については、Next.js Confのデモをご覧いただき、ドキュメントをご確認ください。
Bot対応ISR Fallback
現在、fallback: trueを使用したIncremental Static Regenerationは、まだ生成されていないページへの最初のリクエストで、ページコンテンツをレンダリングする前にフォールバック状態をレンダリングします。
ページの読み込みをブロック(サーバーレンダリング)するには、fallback: 'blocking'を使用する必要があります。
Next.js 12では、Webクローラー(検索ボットなど)はfallback: trueを使用してISRページを自動的にサーバーレンダリングし、非クローラーUser-Agentsには以前のフォールバック状態の動作を提供します。
これにより、クローラーが読み込み状態をインデックスすることを防ぎます。
AVIFを使用したより小さい画像
組み込みのImage Optimization APIがAVIF画像をサポートし、WebPと比較して20%小さい画像を実現します。
AVIF画像はWebPと比較して最適化に時間がかかる場合があるため、next.config.jsの新しいimages.formatsプロパティを使用してこの機能をオプトインにしています:
module.exports = {
images: {
formats: ['image/avif', 'image/webp'],
},
};
このフォーマットリストは、リクエストのAcceptヘッダーを使用してオンデマンドで最適化された画像フォーマットを決定するために使用されます。AVIFが最初にあるため、ブラウザがAVIFをサポートしている場合は提供されます。そうでない場合、ブラウザがWebPをサポートしていればWebPが提供されます。どちらのフォーマットもサポートされていない場合は、元の画像フォーマットが提供されます。
Output File Tracing
Next.js 8で、targetオプションを導入しました。これにより、ビルド中にwebpackを使用してすべての依存関係をバンドルすることで、Next.jsページをスタンドアロンJavaScriptバンドルとして出力できました。
これが理想的でないことをすぐに認識し、代わりに@vercel/nftを作成しました。@vercel/nftは、Vercelプラットフォーム上のすべてのデプロイメントで2年以上使用されています。
現在、これらの改善をすべてのデプロイメントプラットフォームでデフォルトでNext.jsフレームワークに直接組み込み、targetオプションよりも大幅に改善されたアプローチを提供しています。
Next.js 12は、@vercel/nftを使用して各ページとAPIルートで必要なファイルを自動的にトレースし、これらのトレース結果をnext build出力の隣に出力し、インテグレーターがNext.jsが自動的に提供するトレースを活用できるようにします。
これらの変更により、next startを使用するDockerなどのツールを使用してデプロイするアプリケーションも最適化されます。@vercel/nftを活用することで、将来的にNext.js出力をスタンドアロンにできるようになります。アプリケーションを実行するために依存関係をインストールする必要がなくなり、Dockerイメージサイズが大幅に削減されます。
@vercel/nftをNext.jsに組み込むことで、targetアプローチが置き換えられ、Next.js 12でtargetは非推奨になります。
詳細については、ドキュメントをご確認ください。
その他の改善
- アプリケーションに
pages/_app.jsまたはpages/_document.jsを追加すると、Next.js CLIの再起動を必要とせずに組み込みバージョンが自動的に置き換えられるようになりました。
- ESLint統合で、
--fileフラグを使用したnext lintでの単一ファイルリンティングがサポートされました。
- Next.js 12でカスタム
tsconfig.jsonパスの設定がサポートされました。
- 設定をESモジュールとして記述するための
next.config.mjsがサポートされました。
getStaticPropsのインフライトリクエストが重複排除されるようになりました。
- 静的ページのチェックが共有ワーカープールを使用して実行されるようになりました。
- Fast RefreshがEventSource接続の代わりにWebSocket接続を使用するようになりました。
破壊的変更
Next.js 11でwebpack 5をデフォルトにした後、webpack 4を正式に削除しました。webpack 5へのスムーズな移行を確保するため、コミュニティと密接に協力してきました。