開発メモ
Nuxt 4 + @nuxt/content の開発サーバー起動が遅い原因と対策
結論
376ファイルのコンテンツを持つNuxt 4プロジェクトで、開発サーバーの起動に7〜8秒かかるのは「ある程度は仕方ない」。ただし、SQLダンプの重複処理やプリレンダリングルートの設定次第で多少の改善は可能。
起動ログの分析
pnpm dev 実行時のログを確認すると、以下の処理に時間がかかっていた。
| 処理 | 時間 | 備考 |
|---|---|---|
| コンテンツ処理 | 4.4秒 | 376ファイル(373キャッシュ済み、3新規) |
| Nitroサーバービルド | 6秒 | 最も重い処理 |
| SQLダンプコンパイル | 1.3秒×複数回 | dump.pages.sql が繰り返し処理される |
| Viteクライアントビルド | 329ms | 比較的軽い |
| Viteサーバービルド | 181ms | 比較的軽い |
また、プリレンダリングルートとして coding-standards(158件)と J.League club(62件)が追加されていた。
避けられない遅延要因
- コンテンツファイル数: 376ファイルは多い。@nuxt/contentはすべてのファイルをインデックス化するため、ファイル数に比例して処理時間が増える
- Nitroビルド: Nuxt 4 + Nitroの組み合わせは初回ビルドが重い
- D1データベース切り替え: Cloudflare向け設定でD1への切り替え処理が発生
改善の余地があるもの
1. SQLダンプの重複処理
content/raw/dump.pages.sql が複数回コンパイルされている。このファイルが本当に必要なのか、監視対象から除外できるのか、確認する価値がある。
2. プリレンダリングルートの無効化(開発時)
開発時に220件以上のプリレンダリングルートは不要。nuxt.config.ts で開発環境向けに無効化できる。
// nuxt.config.ts
export default defineNuxtConfig({
nitro: {
prerender: {
// 開発時はプリレンダリングを減らす
routes: process.env.NODE_ENV === 'development' ? [] : [...]
}
}
})
3. キャッシュの活用
.nuxt ディレクトリを削除しなければ、2回目以降の起動はキャッシュが効いて速くなる。
まとめ
この規模のプロジェクトでは、7〜8秒の起動時間は許容範囲。HMR(ホットリロード)は高速に動作しているため、起動後の開発体験に問題はない。
どうしても速くしたい場合は、SQLダンプファイルの処理見直しと開発時プリレンダリング無効化を検討するとよい。