Next.js 9.0.7
投稿者: JJ Kasper @ _ijjk、Joe Haddad @ timer150、Luis Alvarez @ luis_fades、Lukáš Huvar @ huv1k、Tim Neutkens @ timneutkens
Next.js 9.0は約2ヶ月前にリリースされました。それ以来、私たちは7つの小さいながらも非常に重要なリリースに取り組んできました：9.0.1、9.0.2、9.0.3、9.0.4、9.0.5、9.0.6、そして9.0.7です。これらのリリースが、破壊的変更を一切加えることなく、あなたのウェブサイトやアプリケーションにもたらした内容を詳しく見ていきましょう。
主な改善点
- Windows環境での並行処理の改善:
next buildプロセスがWindowsでより信頼性が高くなり、作業をより効率的に並列化できるようになりました
- デフォルトでのGzip圧縮: 最適化ステップを削減するため、Gzip圧縮がデフォルトで追加されました
- アクティブなページのみでのTypeScriptレポート: 組み込みのTypeScriptサポートが拡張され、アクティブなページの変更のみを監視するようになり、より高速で信頼性が向上しました
- テレメトリ: Next.jsのどの部分を最適化すべきかに焦点を当て、最適化が意図した効果を持つかを検証するのに役立ちます
- next/head要素追跡の改善:
next-headクラスが削除され、実装を検証する特定のツールの実装が容易になりました
- pagesディレクトリでの非ページファイルの防止: 非ページファイルの偶発的な公開を防ぐことで、アプリケーションのセキュリティと
next build時間を最適化します
- ランタイムの改善: Next.jsの特定の部分（例：
next/dynamic）が使用されていない場合、ランタイムで不要になり、バンドルサイズが小さくなります
Windows環境での並行処理の改善
Next.jsはnext buildプロセス中の多くの場所で並行作業を行います。主な用途は、Terserを使用してビルド出力を並列で最小化することです。
以前は、この作業はworker-farmというパッケージを使用して多くのCPUで処理されていました。しかし、多くのWindowsユーザーがカスタムwebpack設定で最小化を無効にしていることに気づきました。
詳しく調査した結果、worker-farmがWindowsマシンで一貫して動作しないことがわかりました。この問題を解決するため、worker-farmからjest-workerに移行しました。これにより、macOS、Linux、Windowsマシンで一貫して信頼性の高いビルドが保証されます。
jest-workerは、その名前が示すように、Jestテストランナーの一部です。Jestがテストケースを並列化するために使用するパッケージです。つまり、このパッケージは非常に実戦でテストされ、信頼性が高く、メンテナンスされています。
jest-workerは、Node 12の新機能であるworker_threadsもサポートしています。child_processとは異なり、worker_threadsはメモリを共有できるため、新しいNodeバージョンでのビルド時間が短縮されます。
デフォルトでのGzip圧縮
企業がカスタムサーバーを使用する理由を調査したところ、最も多いのが圧縮のためでした。企業はcompressionというExpressミドルウェアを追加し、HTTPレスポンスのGzip圧縮を処理していました。
通常、これはNginxのようなリバースプロキシで処理されるべきです。リバースプロキシは、シングルスレッドのNodeプロセスからCPU集約的な作業を取り除きます。
しかし、Web上でのNext.jsの使用状況を調査したところ、多くの企業で圧縮が設定されていないことがわかりました。
Next.js 9.0.4以降、next startまたはカスタムserver.jsを使用する際に、gzip圧縮がデフォルトで含まれるようになりました。Node.jsがBrotliをネイティブサポートするようになったため、brotliサポートも近日中に提供予定です。
アクティブなページのみでのTypeScriptレポート
Next.js 9にはTypeScriptの組み込みサポートが含まれています。必要なのは、単一のページを.jsから.tsxにリネームするだけです。Next.jsが残りのセットアップを自動的に処理するか、ガイドします。
Next.js 9.0.4以降、Next.jsはオンデマンドエントリによってアクティブにコンパイルされているページのタイプエラーのみを報告するようになりました。これにより、特定のページセットに焦点を当てながら、多くのタイプチェックノイズが削減されます。
テレメトリ
Next.jsは約3年前にリリースされ、この3年間でフレームワークは大幅に成長しました。新機能から全ユーザー向けのより良いデフォルトまで、様々な改善が行われています。
この改善プロセスへのアプローチは、これまで非常に手動的なものでした。しかし、このアプローチには問題があります。それは、ユーザーのサブセットからのフィードバックしか収集できないということです。
この理由から、近い将来Next.jsをさらに改善できるよう、これらのフィードバックポイントを収集するための匿名で自動化されたアプローチを導入しました。
テレメトリについて詳しくは、nextjs.org/telemetryをご覧ください。参加したくない場合のオプトアウト方法も記載されています。
next/head要素追跡の改善
Next.jsは、アプリケーションのHTMLレンダリングを担当するため、<head>要素を管理する組み込み方法を提供しています。このAPIはnext/headモジュールを通じて公開されています。
以前は、Next.jsはnext/headによって提供されるすべての要素にクラス名を追加することで、これらの要素を追跡していました。しかし、要素の追加クラス属性により、外部サービスから追加されるスクリプトが検証されない場合があるという報告がありました。
Google ChromeチームのGerald Monacoが、要素にクラス名を必要とせずにクリーンアップ動作を保持する方法を考案しました。新しい動作では、Next.jsがレンダリングした要素数を保持する追加の<meta>タグを挿入します。
pagesディレクトリでの非ページファイルの防止
Next.jsを始める際、最初に行うのはpagesディレクトリの作成です。規約では、pagesディレクトリ内のすべてのファイルがアプリケーションのルートになります。
時間が経つにつれ、ユーザーがコンポーネント構造全体をpagesディレクトリに作成していることが判明しました。pagesディレクトリ内のすべてのファイルがページとして扱われるため、すべてのコンポーネントがアプリケーション内でページとしてコンパイルされていました。
Next.js 9では、pagesディレクトリ内のファイルがReactコンポーネントをエクスポートすることを検証するようになりました。実際には、Next.jsがpagesディレクトリで潜在的な非ページが見つかったことを警告するメッセージを表示します。
ランタイムの改善
Next.jsフレームワークは多くの部分で構成されています。その一つがクライアントサイドランタイムです。このランタイムは、ハイドレーション、クライアントサイドルーティングなどを処理します。
以前は、このランタイムは常にNext.jsランタイムバンドルに含まれていました。現在は、アプリケーションでnext/dynamicを使用する場合のみ含まれます。これは、next/dynamicを使用しないアプリケーションでは、ダウンロード、解析、実行されるJavaScriptが少なくなることを意味します。