【比較】SPAとMPAの違い¶
概要¶
SPA（Single-Page Application）と MPA（Multi-Page Application）は、「ページ遷移のときにブラウザが何をするか」という Web アプリの構成方式の違いです。SPA は最初に1つの HTML 文書だけを読み込み、以降の画面切り替えは JavaScript が文書の中身を書き換えて行います。MPA はリンクをたどるたびにサーバーから新しい HTML 文書を取得し、ブラウザがそれを読み込み直します。
混同しやすいのは、これを SSR/CSR と同じ軸だと思ってしまう点です。SSR/CSR は「HTML をどこで生成するか」の軸、SPA/MPA は「遷移ごとに文書を読み込み直すか」の軸で、おおむね直交します。実際、SPA でも初期 HTML をサーバーで生成（SSR）できますし、MPA でも各ページ内で CSR を使えます。Astro や Next.js の App Router のように、両者の良いとこ取りをするハイブリッド構成も一般化しています。
例えるなら：本の読み方¶
- MPA … 章を変えるたびに「別の冊子」を司書（サーバー）に取りに行く。冊子そのものは完成しているのですぐ読めるが、取りに行く往復が毎回発生する。
- SPA … 最初に1冊の差し替え式バインダーを受け取り、ページめくりは自分（ブラウザの JS）が中身を差し替えて行う。最初にバインダー一式を受け取るのに時間がかかるが、その後のページめくりは手元で速い。
詳細比較¶
| 比較軸 | SPA（シングルページアプリ） | MPA（マルチページアプリ） |
|---|---|---|
| 読み込む文書 | 起動時に1つの HTML 文書のみ | 遷移ごとに新しい HTML 文書 |
| 画面遷移の仕組み | JS が文書の中身を書き換え（クライアントサイドルーティング、History API の pushState 等を使用） |
サーバーへ新規リクエストし、ブラウザがページを再読み込み |
| 初回ロード | 重くなりやすい（アプリ全体の JS を読む） | ページ単位で軽くなりやすい（そのページ分だけ） |
| 遷移後の体感 | 速くアプリ的（差分のみ更新） | 都度フルロード（往復が発生） |
| 状態（state）の保持 | 文書が維持されるので保持しやすい（実装は要工夫） | 遷移で文書が破棄され基本リセット（保持には別途仕組みが必要） |
| SEO・クローラ | 不利になりやすい（初期 HTML が空になりがち。MDN も SEO を弱点に挙げる） | 有利になりやすい（各 URL が完成 HTML を返しやすい） |
| ルーティング実装 | 自前で実装が必要（MDN が弱点として明記） | サーバー/ブラウザ標準の遷移に乗れる |
| 代表例 | React/Vue/Angular の単一アプリ構成 | 従来型 Web サイト、Astro（MPA フレームワーク） |
よくある誤解¶
- 誤解1：「SPA は CSR、MPA は SSR と同じ意味」 — 誤りです。SPA/MPA は「遷移で文書を読み込み直すか」、SSR/CSR は「HTML をどこで生成するか」の別軸で、ほぼ直交します。SPA でも初期 HTML をサーバーで生成（SSR）できますし、MPA の各ページ内で JS による CSR を併用することもできます。組み合わせで考えるべきものです。
- 誤解2：「SPA の方が常に速い」 — 一面的です。遷移後の体感は SPA が軽快ですが、SPA は起動時にアプリ全体の JavaScript を読み込むため初回ロードが重くなりやすいのがトレードオフです。MPA は各ページがそのページ分の HTML だけで完結し、初回が軽いことも多い。Astro 公式も、SPA は多量のクライアント JavaScript により初回表示性能（TTI など）を損ないやすいと整理しています。
- 誤解3：「SPA は SEO に対応できない」 — 「できない」ではなく「不利になりやすい・追加対応が要る」が正確です。MDN も SPA の弱点として SEO・状態管理・ナビゲーション実装・性能計測の難しさを挙げています。SSR やプリレンダリングを併用すればクローラ向けに完成 HTML を返すことは可能で、絶対に不可能なわけではありません。
- 誤解4：「ページ数が複数あれば MPA」 — 誤りです。MPA/SPA の本質は「ページ数」ではなく「遷移時にブラウザが新しい HTML 文書を読み込み直すか（MPA）／1つの文書のまま JS で書き換えるか（SPA）」です。SPA も URL 上は複数の画面（
/profile等）を持てますが、それはクライアントサイドルーティングで文書を読み込み直さずに実現しています。
実務での選び分け¶
- コンテンツ中心・公開サイト（メディア、ブログ、コーポレート、LP、ドキュメント） → MPA 寄り。SEO に強く初回が軽い。Astro のような MPA フレームワーク＋必要箇所だけ JS（アイランド）構成が好相性。
- 操作中心・アプリ的 UX（管理画面、SaaS ダッシュボード、エディタ、認証後の業務アプリ） → SPA 寄り。遷移が頻繁で状態を持ち回る画面は SPA の体感が活きる。SEO 不要なら弱点も問題になりにくい。
- 公開もアプリ性も両方必要（EC、ニュースサイトの会員機能など） → ハイブリッド。Next.js App Router のように初期はサーバーで HTML を返し（SEO・初回速度）、遷移以降はクライアント側で滑らかに、という構成が定石。
- 判断軸：①SEO と初回表示が重要か（→ MPA/ハイブリッド） ②遷移頻度とリッチな状態管理が必要か（→ SPA） ③チームが許容できる実装複雑度（SPA はルーティング・状態・計測の自前実装コストが上がる）。
ひとことまとめ¶
SPA＝1つの文書を JS で書き換えて遷移、MPA＝遷移ごとにサーバーから新しい文書を取得。SSR/CSR とは別軸（直交）で、現代は両者を組み合わせたハイブリッドが主流です。
出典・参考¶
- MDN「SPA (Single-page application)」用語集（SPA は1つの Web 文書だけを読み込み、表示内容が変わるとき Fetch 等の JS API でその文書の body を更新する。サーバーからページ全体を読み込み直さないため性能と動的体験で利点があるが、SEO・状態維持・ナビゲーション実装・性能計測の難しさというトレードオフがある）: https://developer.mozilla.org/en-US/docs/Glossary/SPA
- MDN「Working with the History API」（SPA のように fetch() で内容を更新するサイトを支えるのが History API の主目的。
pushState()でページ全体を再読み込みせず履歴と URL を更新できる）: https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API - Astro 公式ドキュメント「MPAs vs. SPAs」（MPA はサーバーで描画される複数 HTML ページから成り、遷移でブラウザが新しい HTML をサーバーに要求する。SPA はブラウザで動く単一 JS アプリで、SPA もサーバーで HTML を生成しうるが、遷移時にブラウザ内で新しい HTML を描画する点が固有）: https://docs.astro.build/en/concepts/mpa-vs-spa/
- Astro 公式ドキュメント「Islands architecture」（既定で UI を HTML/CSS に描画し、
client:*で指定した対話要素のみ JS を読み込む、MPA を基盤とした構成）: https://docs.astro.build/en/concepts/islands/