Remix と Next.js の選び方: SEOとログインの有無で変わる最適解

React を使用したプロジェクトで、どのフレームワークを選ぶべきか迷ったことはありませんか？特に **Remix** と **Next.js** は人気の選択肢ですが、サイトの性質や要件によって適切なフレームワークが異なります。この記事では以下のポイントに基づいて、それぞれのフレームワークの適性を比較します。

1. 通常のサイト（ログイン不要）の場合、Remix が適している理由  
2. ログインが必要なサイトで Next.js が優れている理由  
3. 両者の CDN キャッシュ活用の違いと Next.js の内部キャッシュ戦略  

---

### Remix: CDN と親和性が高いフレームワーク

**Remix** は、サーバーサイドレンダリング（SSR）とクライアントサイドの効率性を両立させたフレームワークです。その設計から、以下の理由で **「SEOが大事でログイン不要」** のサイトに適しています。

#### 特徴

- **静的コンテンツに強い設計**  
  Remix は、静的ファイルを効率的に CDN で配信できる構造を持っています。静的ページやユーザーごとに差異のないデータが主体のサイトでは、CDN キャッシュを最大限に活用可能です。

- **柔軟なキャッシュ戦略**  
  - HTTP ヘッダーで `Cache-Control` を設定することで、ブラウザやプロキシキャッシュを利用可能です。
  - Cloudflare Workers や Vercel Edge Functions を組み合わせれば、エッジでのキャッシュも簡単に設定できます。

#### 適用例

- 製品紹介ページやブログのように動的要素が少ないサイト
- 高速な配信が求められるグローバルな静的コンテンツ

---

### Next.jsのキャッシュ機能とRemixの対応

[Next.jsの4つのキャッシュ](https://zenn.dev/frontendflat/articles/nextjs-cache)

#### 1. **React Cache (クライアントコンポーネントのキャッシュ)**

どっちもReactを使っているので割愛

#### 2. **Data Cache (データフェッチのキャッシュ)**

- **Next.js**  
  `getServerSideProps`や`getStaticProps`で取得したデータをサーバーサイドでキャッシュし、API Routesでもデータキャッシュをサポートします。

- **Remixの対応**  
  `loader`関数でデータを取得しつつ、外部ツール（Redisなど）を利用したキャッシュ戦略を組み込めます。HTTPヘッダーで`Cache-Control`を設定することで、ブラウザキャッシュやプロキシキャッシュを有効活用可能です。

**評価:**  
Next.jsのキャッシュ機能は強力ですが、サーバー内部でのキャッシュ戦略が強制されるため、運用負担が増える場合もあります。一方、Remixはキャッシュを外部ツールに委ねる設計で、開発者に柔軟性を提供します。

#### 3. **Full Route Cache (静的ページのキャッシュ)**

- **Next.js**  
  `getStaticProps`や`ISR (Incremental Static Regeneration)`を利用して、静的ページをキャッシュします。特定の更新頻度に基づいて再生成も可能です。

- **Remixの対応**  
  静的生成の概念はなく、リクエストごとに動的にレスポンスを生成します。ただし、Cloudflare WorkersやVercel Edge Functionsを活用すれば、エッジキャッシュによる類似のパフォーマンス改善が可能です。

**評価:**  
静的ページを多用する場合はNext.jsの方が便利ですが、動的な要素が多いサイトではRemixのシンプルさが運用面で有利です。

#### 4. **Router Cache (ルーターによる遷移のキャッシュ)**

- **Next.js**  
  クライアントサイドルーティングの際にデータをキャッシュし、遷移速度を向上させます。プリフェッチ機能でさらに高速化が可能です。

- **Remixの対応**  
  `prefetch="intent"`で事前にデータをフェッチする設計が用意されています。また、既に取得済みのデータは再利用されるため、Reactのメモリ管理に依存しながらシンプルなキャッシュが行われます。

#### 適用例

- ログインやユーザーごとの動的コンテンツが主体のサイト
- 企業の大規模ウェブアプリケーション

---

### Remix と Next.js のキャッシュ比較

| 特性                          | Remix                                   | Next.js                               |
|-------------------------------|-----------------------------------------|---------------------------------------|
| **静的サイト（ログイン不要）** | CDN キャッシュを最大限活用             | 同様のキャッシュ構造は可能            |
| **動的サイト（ログインあり）** | キャッシュ管理を外部ツールに依存       | 内部キャッシュ機能が豊富              |

#### 比較ポイント

- **柔軟性と運用負担**  
  Remix はキャッシュ戦略を外部ツール（Redis など）に委ねる設計で、シンプルな運用が可能です。一方、Next.js は内部で一貫したキャッシュを提供しますが、設定が複雑になる場合があります。

- **静的 vs 動的**  
  静的ページが中心の場合、Remix の CDN キャッシュ活用が優れています。動的コンテンツが多い場合は Next.js の内部キャッシュが有利です。

---

### 結論: フレームワーク選びの指針

フレームワーク選定の際には、サイトの特性に合わせて以下のように選ぶとよいでしょう。

- **静的サイトやシンプルな構造のサイト**: Remix + 外部ツールでのキャッシュ運用が効率的。
- **動的サイトやログイン機能を伴う大規模プロジェクト**: Next.js のキャッシュ機能が適切。

---

特に、ログインが必要な場合は CDN キャッシュを避けるべき理由として以下が挙げられます。

- **ユーザーごとの動的データ**  
  CDN キャッシュは、ユーザーに応じたデータを提供するサイトでは適用が難しい。

- **キャッシュ不一致のリスク**  
  他のユーザーのデータが誤って表示されるリスク。

- **セキュリティリスク**  
  セッション情報や認証トークンがキャッシュされることで、不正アクセスの危険性が高まります。

---

フレームワークを選ぶ際には、性能や機能だけでなく、運用コストやサイトの特性に応じた柔軟性も考慮しましょう。

### 感想
vercelのビジネスモデル的にvercelを使ってほしくて
想像だとvercelはvercelでCDN対応しないと決め、CDNが不要なキャッシュを作ったと考える。