Next.js と戦うのではなく、Next.js に適合するヘッドレス CMS
ドラフトモード、ISR、App Router、そしてレンダー層。ヘッドレス CMS を Next.js に配線するときに本当に重要なこと——そして失敗する 3 つのパターン。
このトピックに関する Google のオートコンプリートは、人々が何を求めているかについて異例なほど一貫しています。最もよく現れる 3 つの候補：
best headless cms for next jsfree headless cms for nextjsnextjs headless cms open source
無料で、オープンソースで、そして特に Next.js 向け。この記事は、その絞り込みリストができたときに候補を分けるものについてです——なぜなら、重要な違いは SDK ではなく、リクエストが到着したときにコンテンツがどこにあるかだからです。
2 つのアーキテクチャ、そして両者を分ける唯一の問い
アプリの中。 Payload は Next.js アプリケーション自体の中で実行されます。HTTP を完全にスキップするローカル API、コードとしての設定、そして 1 つのデプロイが得られます。単一の製品にとって優れた開発者体験です。
そのコストは結合です。CMS とウェブサイトがデプロイ、ランタイム、スケーリング単位を共有します。公開サイトのトラフィックの急増は、編集者が使っているものの急増であり、フロントエンドフレームワークの変更はもはやフロントエンドのプロジェクトではなくなります。
アプリの隣。 Strapi、Directus、Sanity、corpusctl。CMS は別のサービスです。ネットワーク経由でコンテンツを取得するので、あなたは今やキャッシングの決断を背負います。
そのキャッシングの決断こそが統合のすべてです：
訪問者がページをリクエストしたとき、コンテンツはどこから来るのか——そしてどれほど古くても許されるのか？
この記事の他のすべては、あなたの答えから導かれます。
チームが答える 3 つの方法
リクエストごとに取得。 シンプルで正しいですが、あなたの CMS は今やすべてのページロードのクリティカルパス上にあります。そのレイテンシはあなたの TTFB であり、そのダウンタイムはあなたのダウンタイムです。管理ダッシュボードには適していますが、マーケティングサイトには間違っています。
時間ウィンドウ付きの ISR。