SSGとSSRの6つの違い

SSGとSSRの最も大きな違いは、いつHTMLを生成するかにあります。

違い1. HTML生成のタイミング

• SSG (静的サイト生成)
  ウェブサイトをビルド（構築）するタイミングで、すべてのページを事前にHTMLファイルとして生成します。

• SSR (サーバーサイドレンダリング)
  ユーザーからリクエストがあるたびに、サーバーが動的にHTMLを生成します。

違い2. 表示速度

• SSG
  すでに完成しているHTMLを返すだけなので、表示は非常に高速です。

• SSR
  リクエストごとに生成処理が走るため、SSGと比較すると表示速度は遅くなる傾向があります。

違い3. コンテンツの更新

• SSG
  コンテンツの変更を反映させるには、サイト全体の再ビルドが必要です。

• SSR
  常に最新のデータソースからページを生成するため、いつでも最新の状態をユーザーに表示できます。

違い4. サーバー負荷

• SSG
  静的ファイルを配信するだけなので、サーバーへの負荷は低いです。

• SSR
  リクエストのたびにサーバーで処理が実行されるため、アクセスが集中するとサーバー負荷は高くなります。

違い5. パーソナライズ

• SSG
  すべてのユーザーに同じHTMLを返すため、単体でのパーソナライズには不向きです。（別途クライアントサイドでの処理が必要）

• SSR
  リクエスト情報に応じて内容を変えられるため、ユーザーごとのパーソナライズが得意です。

違い6. 適したサイト

• SSG
  ブログ、ドキュメントサイト、企業の公式サイトなど、内容の更新が頻繁ではない静的なサイトに適しています。

• SSR
  SNSのフィード、ECサイト、ユーザーダッシュボードなど、動的でリアルタイム性が求められるサイトに適しています。

最適なレンダリング手法の選び方

更新頻度が低い静的サイトならSSG

ブログ、企業のコーポレートサイト、製品のドキュメントなど、コンテンツの更新が頻繁でなく、全てのユーザーに同じ内容を表示するサイトにはSSGが最適です。圧倒的な表示速度、高いセキュリティ、低いサーバーコストというメリットを最大限に享受できます。

動的な機能やリアルタイム性が必要ならSSR

SNSのフィード、ECサイトのマイページ、ダッシュボードなど、ユーザーごとに表示内容が変わったり、リアルタイムで情報が更新されたりするサイトにはSSRが適しています。常に最新の情報を届け、パーソナライズされた体験を提供できます。

SSG（静的サイトジェネレーター）とは？

SSG（Static Site Generation）とは、ウェブサイトのコンテンツを事前にビルド（構築）し、完成したHTMLファイル群としてサーバーに配置する方式です。ユーザーがウェブサイトにアクセスした際には、既に生成済みのHTMLファイルがそのまま配信されるため、動的な処理を必要とせず、非常に高速な表示が可能です。

ブログやドキュメンテーションサイト、ポートフォリオサイトなど、コンテンツの更新頻度が比較的低い、あるいはリアルタイム性が求められないウェブサイトに適しています。

SSGの仕組み

SSGの仕組みは、ウェブサイトの公開前に、コンテンツ管理システム（CMS）やマークダウンファイルなどからデータを取得し、テンプレートエンジンを用いて各ページに対応するHTMLファイルを生成するというものです。この一連の処理は「ビルド」と呼ばれ、開発者のローカル環境やCI/CD（継続的インテグレーション/継続的デリバリー）パイプライン上で実行されます。

ビルドが完了すると、生成されたHTML、CSS、JavaScriptファイル、画像などの静的アセット群がウェブサーバーやCDNにデプロイされます。ユーザーからのリクエストに対しては、サーバーはこれらの静的ファイルを直接配信するため、データベースアクセスやサーバーサイドでの複雑な処理は発生しません。

SSGの3つのメリット

SSGを導入することによる主なメリットは、表示速度の向上、スケーラビリティの確保、そしてSEO対策の強化です。以下で詳細に説明します。

メリット1. 表示速度が向上する

SSGはパフォーマンスの観点から多くの利点を持ちますが、中でも特にユーザー体験に大きく影響するのが、表示速度の向上です。

各ページが事前にHTMLファイルとして生成されるため、サーバーは要求に応じて完成されたページを返す仕組みとなっています。これにより、サーバー側での複雑な処理やデータベースへの問い合わせが不要となるため、ページの初期表示にかかる時間が大幅に短縮され、ユーザーはコンテンツを快適に閲覧できます。

メリット2. スケーラビリティが高い

スケーラビリティ（拡張性）とは、アクセスが集中した場合でもサービスを安定して提供できる能力のことを言います。従来のウェブサイトではアクセスが集中すると、サーバー負荷が高まり表示速度が低下します。場合によってはサーバーダウンを引き起こす可能性もあります。

一方、SSGで生成された静的ファイルはCDNを通じて世界中の多数のエッジサーバーに複製・配置することが可能です。ユーザーからのリクエストは一台のオリジンサーバーに集中することなく、各エッジサーバーへと効率的に負荷分散されます。

何万、何十万という規模の同時アクセスが発生したとしても、サーバーを増強する必要もなく、低コストで大量のトラフィックに対応できます。

メリット3. SEO対策しやすい

SSGではページがビルド時に完全なHTMLとして事前に生成されます。このため、検索エンジンのクローラーはJavaScriptの実行を待つ必要がなく、コンテンツを直接解釈してページ構造やテキスト情報を正確にインデックス化できます。これにより、ウェブサイトの内容が検索結果へ適切に反映されやすくなります。

加えて、SSGのもう一つの強みである高速なページ表示も重要です。快適なユーザー体験を提供するウェブサイトはランキングで優遇される傾向にあるため、表示速度の速さは間接的にSEO評価を高める要因となります。

SSGの3つのデメリット

SSGには多くのメリットがある一方、気を付けるべきポイントや欠点もいくつか存在します。

デメリット1. 頻繁な更新に弱い

コンテンツの更新があった場合、その変更をウェブサイトに反映させるためにサイト全体の再ビルドが必要になります。

CMSなどでコンテンツを更新しても、ウェブサイト上で公開されているHTMLファイルが更新されるわけではありません。そのため、手動もしくはCI/CDパイプラインなどを通じてビルドを再度実行する必要があります。

頻繁な更新が発生するサイトでは運用しづらく、課題となる可能性があります。

デメリット2. 大規模サイトではビルド時間が長くなりやすい

SSGではビルド時にすべてのHTMLファイルを生成するため、ウェブサイトのページ数が多い大規模サイトだと、処理時間が長くなる可能性があります。

ページ数やコンテンツの複雑さに比例してビルド時間は増大する傾向にあり、数千、数万ページ規模のサイトでは、開発のボトルネックとなることも考慮しなければなりません。

デメリット3. リアルタイムの更新に不向き

ビルド完了後に新しく追加されたコンテンツ（新しいブログ記事など）は、次のビルドが行われるまでサイトに反映されません。その間、ユーザーは新しいコンテンツを閲覧できない状態になるため、 リアルタイム性が求められる場合は不向きと言えます。

SSR（サーバーサイドレンダリング）とは？

SSR（Server Side Rendering）とは、ユーザーがウェブページにアクセスするたびに、サーバー側で動的にHTMLを生成してクライアント（ブラウザ）に返す方式です。リクエストに応じて最新の情報を反映したページを提供できるため、リアルタイム性が求められるコンテンツや、パーソナライズされた情報を提供するウェブサイトに適しています。

SSRの仕組み

ユーザーからリクエストが発生すると、ウェブサーバーはデータベースへの問い合わせやAPI連携を行い、取得したデータとテンプレートを用いてHTMLを動的に生成し、クライアントのブラウザに返します。これにより、常に最新の情報に基づいたページがユーザーに提供されます。

SSRの3つのメリット

SSRを採用することは、特に動的なウェブサイトにおいて3つのメリットがあります。

メリット1. 常に最新のデータを表示できる

リクエストのたびにサーバーでレンダリングとデータ取得が実行されるため、データベースやAPIの最新情報が即座にページへ反映されます。ビルド時の情報に固定されたり、一定時間古いキャッシュが表示されたりする静的な手法とは異なるアプローチであり、ユーザーは「今、この瞬間」の情報を得ることができます。

メリット2. SEO対策になる

サーバーサイドでリクエストごとにデータが反映されたHTMLが生成されるため、検索エンジンのクローラーはJavaScriptを実行せずにページ内容を評価できます。そのおかげで素早く正確にインデックスが登録されるため、検索上位に表示される可能性が高まります。

メリット3. パーソナライズができる

リクエスト情報（クッキーや認証トークンなど）からユーザーを特定することで、「マイページ」のようにユーザーそれぞれに最適化されたページをレンダリングできます。これにより、サイトの利用頻度や満足度を向上させる効果が期待できます。

SSRの3つのデメリット

多くの利点を持つSSRですが、その特性上、考慮すべきデメリットも存在します。

デメリット1. サーバへの負荷と費用が高くなりやすい

リクエストのたびにサーバーで処理が実行されるため、アクセス数が増えるとサーバーへの負荷が大きくなります。CPUやメモリを多く消費すると、サーバーの費用も高くなる傾向があるため注意が必要です。

デメリット2. 読み込みに時間がかかる

ページ遷移をするとその都度サーバーにリクエストが送られるため、他のレンダリング手法が用いられているサイトと比較すると、ページ遷移時に読み込みが長く感じる場合があります。

デメリット3. 複雑化しやすい

動的に生成されるHTMLを効率的に配信するには、CDNやサーバーのキャッシュを適切に設定することが必要です。特にユーザーごとに表示内容が異なるページや、頻繁に更新されるページでは、管理が困難になる傾向があります。

ISRという選択肢

SSGの高速表示とSSRの動的コンテンツ更新能力、両者のメリットを享受したいというニーズに応える技術として、ISR（Incremental Static Regeneration）が登場しました。これは、SSGとSSRのいわば「いいとこ取り」を目指したレンダリング手法です。

ISRの5つのメリット

ISRの主なメリットとしては、以下の点が挙げられます。

メリット1. 高速な初期表示ができる

ビルド時または前回の再生成時に生成された静的ページを配信するため、SSG同様に高速な表示が可能です。

メリット2. コンテンツの鮮度維持ができる

設定した間隔でページがバックグラウンドで再生成されるため、完全に静的なSSGよりも新しい情報を提供できます。

メリット3. サーバー負荷の軽減になる

SSRのようにリクエストごとにHTMLを生成するわけではないため、サーバーへの負荷を抑えられます。最初のアクセスや再生成のタイミング以外は静的ファイルを配信します。

メリット4. ビルド時間の短縮できる（大規模サイトの場合）

サイト全体を一度に再ビルドするのではなく、アクセスがあったページや指定されたページから段階的に再生成できるため、大規模サイトでもビルドの負担を軽減できる可能性があります。

メリット5. 耐障害性の向上になる

一度ページが生成されていれば、バックグラウンドでの再生成に失敗したとしても、古いバージョンのページを引き続き提供できるため、サイトが完全にダウンするリスクを低減できます。

ISRの4つのデメリット

一方で、ISRには以下のようなデメリットも考慮する必要があります。

デメリット1. リアルタイム更新に不向き

コンテンツの更新は設定された間隔やトリガーに依存するため、SSRのような完全なリアルタイム性は実現できません。

デメリット2. キャッシュ制御が複雑になる

再生成のタイミングやCDNとの連携など、キャッシュ戦略がSSGやSSR単体よりも複雑になる場合があります。

デメリット3. 更新性が悪い

設定によっては、期間が経過してコンテンツが古くなった後、最初にアクセスしたユーザーにはまず古い（staleな）コンテンツが迅速に提供され、その裏でページの再生成がトリガーされます。
このため、その最初のユーザーは一時的に古い情報を閲覧する可能性があり、再生成が完了するまでは新しいコンテンツを利用できません。

デメリット4. 対応フレームワークの制約がある

ISRは比較的新しい技術であり、主にNext.jsなどの特定のフレームワークでサポートされている機能です。

ISRが適しているユースケース

ニュース記事やブログ、ECサイトの商品ページなど、定期的に更新されるが、必ずしもミリ秒単位のリアルタイム性が求められないコンテンツに特に有効です。

SSGのパフォーマンスとSSRの動的性をバランス良く取り入れたい場合に、ISRは強力な選択肢となります。

App Router｜Next.jsにおけるレンダリング

Next.jsのApp Routerでは、Pages Routerとは異なり、レンダリング戦略の考え方が大きく進化しました。もはやページ全体でSSGかSSRかを選択するのではなく、デフォルトで静的（SSG）であり、必要に応じて動的（SSR）なレンダリングをオプトインする、というより柔軟なアプローチが採用されています。

App Routerでハイブリッド実装

App Routerでは、Server Componentsが導入され、コンポーネントレベルでレンダリング戦略を決定できるようになりました。これにより、同じページ内に静的に生成される部分と、リクエスト時にサーバーでレンダリングされる部分を混在させることが可能です。

例えば、ブログ記事の本文はSSGで高速に配信しつつ、コメント欄だけはSSRで最新の情報を表示するといった柔軟な構成が実現できます。

動的レンダリング（SSR）のトリガー

App Routerで動的なレンダリングをトリガーする方法はいくつかあります。

• 動的関数（`cookies()`, `headers()`, `searchParams`）の使用
  これらの関数をServer Component内で使用すると、そのコンポーネントを含むルートセグメント全体が動的にレンダリングされます。

• fetch`リクエストのキャッシュ設定
  `fetch`オプションで`cache: 'no-store'`や`revalidate: 0`を設定すると、そのデータはキャッシュされず、常に最新のデータがリクエスト時に取得されます。

• ルートセグメント設定（`export const dynamic = 'force-dynamic'`）
  特定のルートセグメントを強制的に動的レンダリングに設定することも可能です。

ISRの実装（`fetch`の`revalidate`オプション）

App RouterにおけるISRは、`fetch`リクエストの`next: { revalidate: }`オプションを使って実現します。これにより、指定した秒数が経過した後にアクセスがあった場合、バックグラウンドでデータを再検証し、新しいHTMLを生成します。

この新しいアプローチにより、Next.jsはパフォーマンスとデータ鮮度の両方を、よりきめ細かく制御できるようになりました。

発展的｜ハイドレーションと認証

SSGやSSRを理解する上で、「ハイドレーション」という概念が重要です。これは、サーバーから送られてきた静的なHTMLに、ブラウザでJavaScriptを適用してインタラクティブなページに「復元」するプロセスのことです。

また、SSGで構築したサイトに認証機能を実装する場合、一般的にはクライアントサイドでJavaScriptを実行し、API経由でユーザー情報を取得・表示するCSR（クライアントサイドレンダリング）のアプローチを組み合わせます。

まとめ

本記事では、ウェブサイトのレンダリング手法であるSSGとSSRについて、それぞれの仕組み、メリット、デメリット、そして適したユースケースを詳細に比較・解説しました。

SSGは表示速度、セキュリティ、サーバー負荷の低減に優れ、静的なコンテンツ中心のサイトに適しています。一方、SSRはリアルタイム性の高いコンテンツやパーソナライズされた体験の提供に長けていますが、サーバー負荷やパフォーマンスの点で考慮が必要です。

さらに、両者の利点を組み合わせたISRという選択肢も紹介しました。
最適なレンダリング手法は、プロジェクトの目的、コンテンツの特性、更新頻度、求められるパフォーマンスなど、多岐にわたる要素を総合的に検討して決定する必要があります。それぞれの技術の特性を深く理解し、ビジネス要件と照らし合わせることで、ユーザーエクスペリエンスの向上と効率的なウェブサイト運用を実現できるでしょう。