SPAとMPA

SPAとMPAとは

Webアプリの画面の作り方には、大きく2つの方式があります。

MPA(Multi Page Application)— ページを移動するたびに、サーバーから新しいHTMLを丸ごと受け取って表示し直す従来型の方式
SPA(Single Page Application)— 最初に1枚のHTMLと JavaScript を読み込み、以降はJSが [[DOM]] を書き換えて画面を切り替える方式。サーバーとは [[REST API]] などを通じてデータ(JSON)だけをやり取りします

比較

	SPA	MPA
ページ遷移	JSで画面を書き換え(高速・なめらか)	HTMLを再読み込み(画面が一瞬白くなる)
初回表示	遅くなりがち(JSを大量に読む)	速い(HTMLがすぐ表示される)
サーバーとの通信	データ(JSON)のみ	HTML全体
SEO	工夫が必要	有利
実装の複雑さ	高い(ルーティング・状態管理が必要)	低い
代表例	管理画面、Webメール、地図アプリ	ブログ、ニュースサイト、ECの商品ページ

どちらを選ぶか

「操作が多いアプリはSPA、閲覧が中心のサイトはMPA」が基本的な目安です。

SPA は [[React]] や [[Vue.js]] で作られることが多く、画面の状態を [[状態管理]] の仕組みで保持します
SPA は最初のHTMLがほぼ空のため、検索エンジンに内容が伝わりにくいという弱点があります([[SEOの技術基礎]] 参照)
この弱点を補うのが [[Next.js]] などのサーバーサイドレンダリング(SSR)で、初回はサーバーでHTMLを生成し、以降はSPAとして動く「いいとこ取り」ができます

初学者向けポイント

SPA でもURLは変わります。History API という仕組みで、再読み込みせずにURLだけを書き換えています
「SPAが常に優れている」わけではありません。要件に対して過剰なSPA化は、初回表示の遅さと実装コストだけが残ることもあります
迷ったら「このページはどれくらい操作するか?」を考えると選びやすくなります

公開するときにつまずくところ

ブラウザ側だけで動く SPA の実体は 1枚の HTML と JavaScript・CSS だけです。サーバー側でページを組み立てる処理が要らないため、公開に必要なのは静的ファイルを置いて配る場所だけになります。静的サイト向けの [[ホスティングとレンタルサーバー]] や、配信そのものを [[CDN]] 上で行うサービスがそのまま選択肢になります。

ただし、ここでほぼ全員が同じ罠を踏みます。SPA が History API で URL を /users/123 のように書き換えるとき、その書き換えはブラウザの中だけで完結していて、サーバーへは何も問い合わせていません。アドレス欄の見た目が変わっているだけ、という状態です。ところが同じ URL を直接開いたり、その画面で再読み込みしたりすると、今度は /users/123 がそのままサーバーへの実際のリクエストになります。サーバー側にその名前のファイルは存在しないので、返ってくるのは 404 です。「手元では動くのに、公開してリンクを共有した相手だけエラーになる」という定番のつまずきです。

直すのはアプリ側ではなく配信側の設定で、「該当するファイルが無ければ index.html を返す」というフォールバックを入れます。[[Nginx]] なら try_files、[[リバースプロキシ]] を挟む構成なら同じ考え方の転送設定、静的ホスティングサービスでは「SPAモード」「リライト設定」といった名前で用意されています。index.html さえ返れば、あとは JS が URL を読んで正しい画面を描きます。

MPA でこの問題が起きないのは、URL がサーバー側のファイルやルートと1対1で対応していて、どの URL を直接開いてもサーバー側に答えがあるからです。

なお、ここまでは SSR を使わない構成の話です。[[Next.js]] のようにサーバーでHTMLを組み立てる構成では、置き場所は「ファイルを配るだけの場所」では足りず、リクエストのたびにコードを実行できる環境が要ります。逆にビルド時にURLごとのHTMLを書き出しておく静的生成(SSG)なら、配信は静的ファイルのままで、どのURLを直接開いてもそのHTMLが返るため上の404も起きません。

関連技術とのつながり

[[React]] — SPA を作る代表的なライブラリ
[[Next.js]] — SSR で SPA の弱点を補うフレームワーク
[[DOM]] — SPA は DOM の書き換えで画面遷移を実現する
[[状態管理]] — SPA では画面をまたぐデータの持ち方が課題になる
[[SEOの技術基礎]] — SPA と検索エンジンの相性問題を理解する鍵
[[REST API]] — SPA が画面を書き換えるためのデータの入手先
[[CORS]] — SPA と API を別オリジンで動かすときに必ず出会う制約
[[fetchと非同期通信]] — そのデータを実際に取りに行くブラウザ標準API

Q: SPAのページ遷移の仕組みとして正しいのはどれ?
- [ ] 遷移のたびにサーバーから新しいHTMLを丸ごと受け取る
- [x] JavaScriptがDOMを書き換えて画面を切り替える
- [ ] ブラウザが自動的にページのスクリーンショットを切り替える
解説: SPAは1枚のHTMLを読み込んだ後、JSによるDOM書き換えで画面を切り替え、サーバーとはデータだけをやり取りします。

Q: MPAが有利とされる点はどれ?
- [x] 初回表示の速さとSEO
- [ ] ページ遷移のなめらかさ
- [ ] 画面をまたぐ状態管理のしやすさ
解説: MPAはHTMLがすぐ表示されるため初回表示が速く、検索エンジンにも内容が伝わりやすい方式です。

Q: SPAのSEO面の弱点を補う手法として本文で挙げられているのはどれ?
- [ ] 画像をすべてSVGに置き換える
- [ ] localStorageにHTMLを保存する
- [x] Next.jsなどによるサーバーサイドレンダリング(SSR)
解説: SSRは初回はサーバーでHTMLを生成して返すため、SPAの「最初のHTMLがほぼ空」という弱点を補えます。