私はどのようにして軽量なNextJSランタイムの構築に失敗したのか

目標

本番運用中の NextJS アプリケーションを、重量級の Node.js standalone ランタイムから軽量なアーキテクチャへ移行しようと試みた。目的は、NextJS の output: 'export' を用いて静的アセットを生成し、それらを同じ Docker イメージにバンドルした軽量なカスタム Go サーバーで配信することだった。

そのアプリは、8 つのロケールをサポートする複雑な国際化対応サイトだった。主要要件はユニバーサルビルドを維持することだった。つまり、再ビルドなしで各ステージにデプロイできるよう、Docker イメージは環境変数に依存しない（アグノスティックである）必要があった。主目的は、重量級の NextJS ランタイムによる RAM 消費を取り除くこと。NodeJS/Bun のランタイムは、standalone モードで ~ 200-450MB の RAM、静的エクスポートで ~140MB を消費していた。

技術的実装

ユニバーサルビルドを実現するため、ビルド工程から環境変数を取り除いた。API エンドポイントを静的フロントエンドに焼き込む代わりに、/api/graphql のような静的パスを用いた。これらのリクエストの処理はバンドルした Go サーバーに任せ、実行時の環境変数で定義された適切なバックエンドサービスへプロキシとして転送させた。

画像最適化も同様に NextJS ランタイムから切り離した。専用の CDN パスへ書き換えるカスタム画像ローダーを実装し、静的エクスポートが画像処理ロジックに依存しないようにした。

課題：動的パス

スラッグでアクセスするブログ記事のような動的ルートの扱いに大きな障害があった。NextJS の Static Export では、ビルド時にすべてのパスを定義するため generateStaticParams が必要になる。あらゆるブログ記事を事前レンダリングする非効率を避けるため、動的ルートセグメントの代わりにクエリパラメータを使うようアーキテクチャを変更した。これにより、すべてのコンテンツ要求に対して汎用の静的 HTML ファイルを 1 つだけ配信し、クライアント側アプリがその後に個別のデータで埋める方式にできた。

致命傷：カノニカル URL

このプロジェクトは最終的に、SEO（検索エンジン最適化）、とりわけカノニカル URL メタデータの要件に関する解決不能な衝突のために断念した。

多くのメタデータは静的のままでも大きな影響はないが、カノニカルタグは正しく機能させるためにドメインを含む絶対 URL が必要だ。NextJS の app ディレクトリでは、メタデータは または静的な エクスポートで定義する必要があり、静的エクスポートではどちらもビルド時にしか実行されない。Node.js サーバーなしに、これを実行時へ委ねる組み込みの仕組みはない。したがって、ユニバーサルな静的エクスポートではビルド時にドメイン名を知ることができない。