• #nuxt
  • #nuxt-content
  • #performance
  • #開発環境
開発メモ

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ダンプファイルの処理見直しと開発時プリレンダリング無効化を検討するとよい。