パフォーマンス

概要

Fumadocs MDX はバンドラープラグインです。つまり、パフォーマンスのボトルネックの上限は高く、基盤となるバンドラーに左右されます。

Turbopack や Vite などの一般的なバンドラーであれば、MDX ファイルが 500 件を超えるような大規模なドキュメントサイトにも十分対応でき、ほぼすべてのユースケースをカバーできます。

Fumadocs MDX はバンドラーと連携して動作するため、MDX ファイル内でクライアントコンポーネントを含むあらゆるファイルをインポートできます。これにより高い柔軟性が得られ、すべてがデフォルトで最適化されます。

次の2つのカテゴリーに分けられます。

Lazy: Vite などのバンドラーや、Node.js や Bun などのランタイム側のローダーは、モジュールがリクエストされた時点(例: await import() の呼び出し時)で MDX ファイルをオンデマンドにコンパイルできます。そのため、MDX ファイルの数が開発サーバーのパフォーマンスに大きく影響することはありません。

ただし、遅延コンパイルを機能させるには、遅延読み込みを必ず有効にしてください。
Precompiled: Webpack と Turbopack は開発モードでの遅延コンパイルに対応していないため、すべての MDX ファイルを事前にコンパイルしておく必要があります。プリコンパイルする MDX ファイルの数によっては、開発サーバーが遅くなる場合があります。

これはバンドラー側の制約ですが、速度が気になる場合は代替手段としてローカル Markdown をおすすめします。バンドラー層を経由せず、MDX ファイルをランタイムで読み込んでコンパイルします。詳細はリンク先の紹介ページをご覧ください。

Fumadocs MDX は、Remark Image を使って画像を静的インポートに変換します。そのため、画像はお使いの React フレームワークに合わせて自動的に最適化されます(例: Next.js Image API)。

![Hello](./hello.png)

または public フォルダー内の画像の場合

![Hello](/hello.png)

出力結果:

import HelloImage from './hello.png';

<img alt="Hello" src={HelloImage} />

バナー

本番ビルドで最も負荷が大きくなりやすいのは、通常、TypeScript の docgen(tsgo を使わない場合、TypeScript Compiler は低速です)と、個々は些細でもすべての MDX ファイルで積み重なる処理です。

キャッシュがない場合、MDX ファイルが大量にあると、ビルド中のメモリ使用量が極端に増えることがあります。その理由は次のとおりです。

MDX ファイルが JavaScript にコンパイルされた後、バンドラーは出力された JavaScript ファイルもバンドルする必要があります。
各 MDX ファイルのコンパイル時間はわずかでも、合計すると遅くなることがあります。たとえば約 2500 ファイルで、1 ファイルあたり 25ms と仮定すると、コールドビルドには最大 62.5 秒かかります。

主な解決策は、コンパイルをオンデマンドで行い、リクエストされたときにのみコンテンツを読み込むようにすることです。

開発サーバーのセクションでも紹介したとおり、ローカル Markdown は追加のコンパイル処理を必要とせず、ランタイムだけで動作するため、有力な代替手段となります。

リモートからコンテンツを読み込む、独自のコンテンツソースを作成できます。

コンテンツソースでコンテンツファイルを事前にコンパイルする必要がない場合は、SSG でオンデマンドに処理できるため、ビルド速度を向上できます。 ただし、ビルド時の最適化 (バンドルなど) は利用できません。

カスタムソースの実装方法については、カスタムソースを参照してください。