SPAとSSRの違いは描画場所ではない

Webアーキテクチャ SPA SSR フロントエンド設計 Webパフォーマンス

SPAとSSRの違いは「描画場所」では説明できない

SPAとSSRの違いは「ブラウザで描画するか、サーバで描画するか」だと説明されることが多いですが、この理解だけでは実際の設計判断をほとんど説明できません。実務で問題になるのは描画の場所ではなく責務分割です。

つまり、どちらがHTMLを作るかではなく「どこがアプリケーションの主導権を持つのか」が本質です。

同じUIを表示していても、SPAとSSRではシステムの振る舞い・キャッシュ・エラー・SEO・パフォーマンスが根本的に変わります。ここを理解しないまま「流行っているからSPA」「SEOが必要だからSSR」と選ぶと、後でほぼ確実に設計破綻が起きます。

SPAの責務：クライアントがアプリケーションになる

SPA（Single Page Application）は、ブラウザが単なる表示装置ではなく「アプリケーション実行環境」になります。サーバはデータ提供APIに近い存在になります。

最初に取得するHTMLはほぼ空です。

<!DOCTYPE html>
<html>
<head>
  <script src="/app.js"></script>
</head>
<body>
  <div id="app"></div>
</body>
</html>

この時点では画面は何も表示されません。JavaScriptが読み込まれて初めて、UIが構築されます。

ここで重要なのは、SPAでは「画面遷移」という概念がサーバに存在しないことです。ユーザがページを移動しても、HTTP的には同一ページに留まり続けます。画面の変化はすべてJavaScriptが担当します。

つまりSPAは、

  • UI状態管理
  • ルーティング
  • 画面描画
  • キャッシュ制御

をブラウザ側が責任を持つ設計です。

これは「描画場所の違い」ではありません。アプリケーションの主体がサーバからクライアントへ移動しているのです。

SSRの責務：サーバがアプリケーションの主体

SSR（Server Side Rendering）は逆です。サーバがアプリケーション本体です。ブラウザは基本的に「完成した結果」を受け取るクライアントです。

ユーザがURLへアクセスすると、サーバはリクエストごとにHTMLを生成します。

GET /products/1
→ DBアクセス
→ テンプレート生成
→ HTMLレスポンス

ブラウザはそのHTMLをそのまま描画します。JavaScriptは補助的な役割になります。

ここで重要なのは、SSRでは画面遷移がHTTPリクエストと一致する点です。URLの変化がそのままサーバの処理単位になります。

つまりSSRでは

  • ルーティング
  • データ取得
  • 描画
  • 状態管理

の主導権がサーバにあります。

なぜ「描画場所」で説明すると誤解が起きるのか

SPAでもSSRでも、最終的に画面を描画するのはブラウザです。サーバはGPUを持たないため、物理的に描画はできません。サーバがしているのは「HTML生成」です。

そのため、「どこで描画するか」という説明は技術的に正しくありません。

誤解の典型例があります。SPAにプリレンダリングを入れると、サーバがHTMLを生成します。しかしアーキテクチャはSPAのままです。なぜなら状態管理の主体は依然としてクライアントだからです。

つまり区別は以下になります。

観点 SPA SSR
状態管理 ブラウザ サーバ
ルーティング ブラウザ サーバ
データ取得主体 クライアント サーバ
HTTPとの関係 API通信 ページ取得

ここを理解すると、なぜ設計や性能特性が変わるかが見えてきます。

責務分割が変わると何が変わるのか

キャッシュ戦略**

SSRではHTMLが成果物です。CDNキャッシュが非常に有効です。逆にSPAではHTMLは意味を持たず、APIレスポンスとJSバンドルがキャッシュ対象になります。

エラーの出方**

SSRではサーバエラーはHTTP500になります。SPAでは多くの場合、ユーザは「何も表示されない画面」を見ることになります。これはアプリケーションがブラウザ内でクラッシュしているためです。

ログの意味**

SSRはアクセスログがユーザ行動に直結します。SPAではアクセスログだけではユーザ遷移は分かりません。イベントログが必要になります。

セキュリティモデル**

SSRはサーバ側で認可を制御できます。SPAではトークン管理が中心になり、認証設計が難しくなります。localStorage保存などを安易に行うとXSS時に即漏洩します。

向いているケースの違い

SPAが向くのは、状態変化が激しいUIです。
例：

  • 管理画面
  • エディタ
  • チャット
  • ダッシュボード

これらは頻繁に部分更新が起きます。HTTPリクエスト単位のSSRでは逆にオーバーヘッドが増えます。

SSRが向くのは、コンテンツ配信です。
例：

  • 記事サイト
  • EC商品ページ
  • コーポレートサイト

これらは「到達した瞬間に内容が見える」ことが重要です。初期表示速度とキャッシュが効きます。

設計を間違えると起きる問題

最も危険なのはSSRの思想でSPAを作ることです。

よくある例として、

  • 毎回フルデータをAPIで取得
  • ページ遷移ごとに大規模再描画
  • URLと状態が一致しない

この結果、SEOは弱く、初期表示も遅く、開発も複雑という「両方の欠点」を持つシステムが生まれます。

逆にSPAの思想をSSRに持ち込むと、サーバで過剰な状態管理を行い、スケールしなくなります。

結局どう理解すればいいのか

SPAとSSRはUI技術の選択ではありません。アプリケーションの配置場所の選択です。

SPAは「ブラウザにアプリを配布する」設計です。
SSRは「サーバでアプリを実行して結果を返す」設計です。

この違いを理解すると、SEO・初期表示速度・キャッシュ・認証・ログ設計まで一貫して説明できます。どちらが優れているかではなく、どこにアプリケーションを置きたいのかを先に決めることが、SPAとSSRを選ぶ唯一の正しい順番になります。