SPAはなぜ流行し、
なぜ見直されているのか

SPAは「やりすぎたJavaScript」だったのか

SPA、つまりSingle Page Applicationという言葉を聞くと、いまでは少し複雑な気持ちになる人も多いかもしれません。初回表示が遅い。SEOが難しい。JavaScriptのバンドルサイズが大きい。ローディング状態やエラー状態の管理がつらい。ReactやVueでサイトを作ったことがある人なら、どれか一つは身に覚えがあるはずです。

けれど、SPAは単に「JavaScriptを使いすぎた流行」ではありませんでした。ページ遷移のたびに画面全体が白くなり、フォームを送信すると最初から入力し直し、地図を少し動かすだけでもサーバーから新しいHTMLを受け取る。そんな時代のWebに対して、「もっとアプリのように振る舞えないのか」と問いを立てたのがSPAの出発点でした。

私がWeb制作を始めたころも、まだ「ページ」はかなり強い単位でした。トップページ、一覧ページ、詳細ページ、完了ページ。デザイナーは画面を作り、エンジニアは画面ごとにテンプレートを用意する。ところが、GmailやGoogle Mapsのようなサービスを一度触ってしまうと、Webはもう「文書を読む場所」だけではなくなっていきます。ページを移動するのではなく、同じ画面の中で状態が変わる。受信箱が更新され、地図が滑らかに動き、検索候補が入力中に現れる。そこには、明らかに新しいWebの感触がありました。

Ajaxが開いた「ページ遷移しないWeb」の扉

SPAの前史を語るなら、避けて通れないのがAjaxです。2005年、Jesse James Garrettが「Ajax: A New Approach to Web Applications」という文章でこの言葉を広めました。Ajaxはひとつの技術名というより、JavaScript、XMLHttpRequest、DOM操作、CSSなどを組み合わせ、ページ全体を再読み込みせずにサーバーと通信する設計パターンでした。

代表例としてよく語られるのが、Google SuggestやGoogle Mapsです。Google Mapsが登場した2005年当時、地図サービスといえば、移動するたびに新しい画像やページを待つものという感覚がありました。ところがGoogle Mapsでは、ドラッグすると地図がそのまま動く。Webページなのに、デスクトップアプリケーションのように感じられる。その体験は、Web制作者にとってかなり衝撃的だったはずです。

この流れの中で、Web制作者の関心は変わっていきました。どのHTMLを返すか、ではなく、どの状態ならどのUIを表示するか。フォームの送信中、通信エラー、ログイン済み、未ログイン、検索結果が0件、データの再取得中。かつては「ページ遷移の途中」に隠れていたものが、画面の中に露出してきたのです。

SPAが解決した問題、そして持ち込んだ問題

SPAの魅力は明快でした。最初に必要なJavaScriptを読み込み、その後はAPIからデータを受け取り、ブラウザ側で画面を組み替える。ページ全体を再読み込みしないため、画面の切り替えは滑らかになり、ユーザーの操作は途切れにくくなります。管理画面、チャット、ダッシュボード、タスク管理ツールのように、ユーザーが長く滞在し、細かく操作し続けるUIでは、この考え方は非常に相性がよかったのです。

しかし、すべてのWebサイトがアプリケーションだったわけではありません。会社案内、採用サイト、メディア、LP、ブログ、ドキュメント。多くのページは、最初に読めること、検索エンジンに理解されること、共有されたURLからすぐ内容に到達できることが重要です。そこに巨大なJavaScriptを配り、ブラウザ上でHTMLを組み立てる設計を持ち込むと、かえってWebの強さを削ってしまう場合がありました。

問題はSPAそのものではなく、「どんな体験にもSPAを当てはめてしまうこと」でした。ユーザーが読むだけのページにも、アプリのような初期化処理が走る。1枚の採用ページを見るために、ルーティング、状態管理、バンドル分割、ハイドレーションが必要になる。もちろん、技術的には動きます。でも、Webとして自然かどうかは別の話です。

// SPAでは「状態からUIを作る」ことが中心になる
<App>
  {isLoading ? "読み込み中" : <Article data={data} />}
</App>

<!-- HTML中心のページでは、まず文書が届く -->
<article>
  <h1>SPAはなぜ流行したのか</h1>
  <p>本文が最初から読める。</p>
</article>

なぜフロントエンドはサーバーへ戻り始めたのか

2010年代後半から、フロントエンドは不思議な方向へ進みます。ReactやVueのようなクライアント側のUI技術が普及した一方で、Next.js、Nuxt、SvelteKit、Astroのように、サーバーでHTMLを生成したり、静的HTMLを事前に作ったりするフレームワークが存在感を強めていきました。これは「昔に戻った」というより、「どこでHTMLを作るべきか」を選べるようになった、と見る方が近いでしょう。

SSR、つまりServer-Side Renderingは、リクエストごとにサーバーでHTMLを生成する方法です。SSG、Static Site Generationは、ビルド時にHTMLを作っておく方法です。さらにAstroが広めたIslands Architectureでは、ページの大部分は静的なHTMLとして届け、必要な部分だけをインタラクティブな「島」としてJavaScriptで動かします。React Server Componentsもまた、すべてをブラウザに送るのではなく、サーバーでできる仕事をサーバーに戻す試みといえます。

ここで大事なのは、HTMLの価値が再発見されたことです。HTMLは古い技術ではありません。リンクできる。検索できる。スクリーンリーダーが読める。JavaScriptが失敗しても、最低限の内容を届けられる。WebがWebであるための性質は、かなりの部分がHTMLに宿っています。

だから、いま起きているSPAの見直しは、ReactやVueを捨てる話ではありません。むしろ、コンポーネント思考、状態管理、宣言的UIといったSPAが育てた知恵を、HTML中心のWebにどう持ち帰るかという話です。Next.jsのApp Router、Nuxtのサーバーレンダリング、Astroの部分的なハイドレーション、RemixのWeb標準への寄り方。方向性は違っても、問いは似ています。どこまでをサーバーが担い、どこからをブラウザに任せるのか。

次に画面を作るとき、まず「これはアプリか、文書か」と考えてみる

SPAは流行しました。たしかに、少し行きすぎた場面もありました。でもそれは、Web制作者が怠けたからではありません。Webが担うものが増えすぎたのです。メール、地図、会計、予約、動画編集、デザインツール、管理画面。ブラウザは、文書を読むための窓から、仕事をするための環境へ変わっていきました。その変化に応えるために、SPAは必要でした。

一方で、すべてのWebがアプリである必要はありません。読まれるべき文章、見つけられるべき情報、共有されるべきURL、軽く届くべきページ。そういうものまでアプリ化してしまうと、Webの本来の強みが薄れてしまいます。だからこそ、いまのフロントエンドには、SPAかMPAか、SSRかSSGか、ReactかAstroか、という選択以前に、「この体験は何を中心に設計されるべきか」という問いが必要なのだと思います。

次に新しいページや機能を作るとき、少しだけ立ち止まってみてください。これは、状態が変わり続けるアプリケーションなのか。それとも、まず確実に届くべき文書なのか。その問いを置くだけで、選ぶ技術の意味はかなり変わって見えてくるはずです。