SSRがSSGより優れている理由

Jun 30, 2024

SSR だけで十分な理由

SSR（サーバーサイドレンダリング）とは、サーバー上で実行時にページをレンダリングし、それをフロントエンドに送信することを指します。SSG（スタティックサイト生成）とは、HTML などの静的ファイルを事前にコンパイルし、ユーザーがリクエストしたときに直接フロントエンドに送信することを指します。

これらの定義が明確になれば、SSR は動的なロジックを埋め込むことができますが、常にサーバーを実行する必要があり、SSG は CDN に配置できる静的なコンテンツにより適していることが容易に理解できます。有名な NextJS フレームワークは SSR と SSG の両方をサポートしています。しかし、新しい Remix フレームワークは SSG を完全に放棄し、このアプローチに十分な利点があると考えています。私の経験では、現代の CDN のサポートにより、このアプローチは理にかなっています。

Cloudflare や Vercel などの現代の CDN はサーバーレス環境をサポートしており、NodeJS アプリケーションのデプロイは静的ファイルのデプロイとほぼ同じくらい簡単です。
SSG の主な利点は、静的ファイルを CDN に直接デプロイしてサーバーリソースを節約することです。しかし、SSR も適切なCache-Controlヘッダーを設定することで、コンテンツを CDN に簡単にキャッシュできます。これにより、SSR サーバーは最初のリクエスト時のみ実行され、静的ファイルとほぼ区別がつかなくなります。
静的コンテンツを変更するたびに再コンパイルや再デプロイが不要です。
NextJS のような SSG と SSR を区別するアプローチを放棄すると、精神的な負担が大幅に軽減されます。キャッシュ設定はCache-Controlなどの HTML 標準に完全に依存し、追加のインターフェースを学ぶ必要がありません。キャッシュの問題のデバッグもはるかに簡単になります - ブラウザがキャッシュすべきでないリクエストをキャッシュした場合、Response設定を確認するだけで済みます。

例

実際、Remix の公式ウェブサイトは優れた例です。彼らのドキュメントは SSR を使用して生成されています。多くの人は、ドキュメントは単なる静的テキストなので、SSG が最適だと思うかもしれません。Remix チームは説明しています。

彼らのドキュメントは Remix のソースコードリポジトリに保存されており、公式ウェブサイトに直接書かれているわけではありません。このドキュメントをソースコードと一緒に保持するアプローチには、いくつかの利点があります：

コードを読む際により参照しやすい
コードを変更する際にドキュメントを簡単に更新できる
Git が自動的にドキュメントの変更を追跡し、ソースコードバージョンと紐付けます

公式ウェブサイトのサーバーは Remix のソースコードリポジトリから読み取り、SSR を通じてドキュメントページを生成します。このアプローチには、いくつかの利点があります：

ドキュメントを変更するたびにウェブサイト全体を再コンパイルして再デプロイする必要がありません
ソースコードリポジトリから任意の Remix バージョンのドキュメントに直接アクセスでき、dev ブランチの最新のドキュメントにもアクセスできます。これにより、公式ウェブサイトは任意の Remix バージョンに対応するドキュメントを表示できます。

ドキュメントはリアルタイムデータではないため、いくつかのキャッシュ最適化を実装しています：

lru-cacheを使用してドキュメント結果をキャッシュします。キャッシュはサーバーサイドにあるため、すべてのクライアントが恩恵を受けます。
- タイムアウトを 5 分に設定
Cache-Controlをstale-while-revalidateに設定。これにより CDN キャッシュが可能になります：
```
return json(
  { doc },
  {
    headers: {
      "Cache-Control": "max-age=300, stale-while-revalidate=604800",
    },
  }
);
```
これにより、ドキュメントが変更された場合、公式ウェブサイトは最大 5 分（max-age=300）の遅延で変更を表示します。