SPAは万能ではなく「用途が限定された最適解」
SPA（Single Page Application）はモダンなWeb開発の代表格ですが、すべてのサイトに適しているわけではありません。
むしろ、社内システムでは強力に機能し、公開サイトでは問題を生みやすいという性質があります。
結論として、SPAは「操作するアプリケーション」に向いており、「閲覧されるページ」には向いていません。
この違いを理解しないまま採用すると、パフォーマンス・SEO・運用のどこかで破綻します。
SPAが得意なこと
SPAの本質は「画面遷移のないUI」です。
ページを再読み込みせず、JavaScriptが状態を管理して画面を書き換えます。
典型的な処理の流れです。
| 処理 | 内容 |
| 初回 | JavaScriptを読み込む |
| 以降 | API通信のみ |
| 描画 | DOMを差し替え |
つまりSPAは、Webページというより「ブラウザ上のアプリケーション」です。
社内システムと相性が良い理由
社内システムには次の特徴があります。
- ログイン前提
- URL共有が少ない
- 長時間操作する
- 入力フォームが多い
これらはSPAの利点と一致します。
特に効果が大きいのはフォーム操作です。
画面遷移がないため入力状態を維持でき、操作の中断や戻る操作でもデータが消えません。
例：勤怠管理・在庫管理・CRM・管理画面
setFormState(prev => ({ ...prev, name: value }))
この「状態保持」がSPA最大の価値です。
ページ単位ではなく、アプリ単位で動作します。
公開サイトで起きる問題
公開サイトは性質がまったく異なります。
- 初回訪問ユーザーが多い
- 検索流入が多い
- URL共有される
- 滞在時間が短い
ここでSPAの弱点が出ます。
初回表示の遅さ
SPAは最初にJavaScriptを大量に読み込みます。
| 段階 | 処理 |
| 1 | HTML取得 |
| 2 | JSダウンロード |
| 3 | JS実行 |
| 4 | API取得 |
| 5 | 描画 |
ユーザーはこの間、ほぼ何も見えません。
いわゆる「白画面問題」です。
社内システムでは許容されますが、公開サイトでは離脱率に直結します。
SEOとクローラ
検索エンジンやSNSクローラは、JavaScript実行に依存するページを苦手とします。
結果として、
- OGPが表示されない
- インデックスが遅れる
- 検索順位が安定しない
といった現象が発生します。
URLの意味が弱くなる
SPAではルーティングはアプリ内部の状態です。
history.pushState({}, "", "/article/123")
URLは変わりますが、サーバにはページが存在しません。
これが404設定やリロード時エラーの原因になります。
実務で起きる設計失敗
よくあるパターンです。
- 採用サイトをSPAで構築
- SEOが伸びない
- OGPが出ない
- 離脱率が高い
- 結局SSRへ作り直し
これは技術力の問題ではありません。
用途とレンダリング方式の不一致です。
SSRとの違い
SSRは最初から完成したHTMLを返します。
| 項目 | SPA | SSR |
| 初回表示 | 遅い | 速い |
| 操作性 | 高い | 普通 |
| SEO | 弱い | 強い |
| フォーム | 得意 | 普通 |
| URL共有 | 弱い | 強い |
つまり、SSRは「ページ」、SPAは「アプリ」です。
向き不向きの目安
SPAが適しているケース
- 管理画面
- ダッシュボード
- 編集ツール
- チャット
- Webアプリ
SPAが不向きなケース
- ブログ
- メディア
- EC商品ページ
- LP
- コーポレートサイト
これは絶対ではありませんが、設計判断の目安になります。
注意点
SPAを選ぶ最大のリスクは「後から変えにくい」ことです。
公開後にSEO問題が発覚すると、SSRへの移行はほぼリプレースになります。
ルーティング・データ取得・ビルド構成が根本から変わるためです。
まとめ
SPAは優れた技術ですが、「モダンだから選ぶ」と失敗します。
重要なのは、サイトが操作されるものか、閲覧されるものかです。
Webは1つの形ではありません。
アプリを作るのか、ページを公開するのか。この区別を最初に行うだけで、多くのリプレースを防ぐことができます。
