MPA vs. SPA

マルチページアプリケーション（MPA）とシングルページアプリケーション（SPA）のアーキテクチャのトレードオフを理解することは、AstroとNext.jsやRemixといった他のWebフレームワークの違いを理解する上で重要なポイントになります。

マルチページアプリケーション（MPA） とは、複数のHTMLページで構成されるWebサイトのことで、そのほとんどがサーバー上でレンダリングされます。新しいページに移動すると、ブラウザはサーバーに新しいページのHTMLを要求します。Astroは、MPAフレームワークの1つです。従来のMPAフレームワークには、Ruby on Rails、Python Django、PHP Laravel、WordPress、Joomla、Drupal、そしてEleventyやHugoなどの静的サイトジェネレーターも含まれます。

シングルページアプリケーション（SPA） とは、ユーザーのブラウザに読み込まれ、ローカルでHTMLをレンダリングする単一のJavaScriptアプリケーションで構成されるウェブサイトです。SPAもサーバー上でHTMLを生成することがありますが、SPAはブラウザ上でJavaScriptアプリケーションとしてウェブサイトを実行し、ページ遷移したときに同じHTMLで新しいHTMLのページを再描画する機能が特徴的です。Next.js、Nuxt、SvelteKit、Remix、Gatsby、Create React Appなどが、SPAフレームワークの一例として挙げられます。

Astroは、MPAフレームワークの1つです。しかし、Astroは他のMPAフレームワークとは一線を画しています。その大きな違いは、サーバー言語とランタイムにJavaScriptを使用している点です。従来のMPAフレームワークでは、サーバーに別の言語（RubyやPHPなど）を書き、ブラウザにはJavaScriptを書くことになります。Astroでは、常にJavaScriptとHTML、CSSを書くだけです。そうすれば、（ReactやSvelteのような）UIコンポーネントをサーバーとクライアントの両方でレンダリングできます。

その結果、Next.jsやその他のモダンなWebフレームワークとよく似た感覚で、より伝統的なMPAサイトアーキテクチャのパフォーマンス特性を備えた開発者体験が得られます。

MPAとSPAの比較では、3つの主な違いを意識する必要があります。

MPAでは、ページのHTMLのほとんどがサーバーでレンダリングされます。SPAでは、ブラウザ上でJavaScriptを実行することにより、ほとんどのHTMLがローカルにレンダリングされます。これは、サイトの動作、パフォーマンス、SEOに劇的な影響を与えます。

ブラウザでHTMLをレンダリングするのは、リモートサーバーにリクエストするよりも高速なオプションのように聞こえるかもしれません。しかし、これは正反対です。サーバーレンダリングを使用しない限り、SPAの最初のページ読み込み時のパフォーマンスは、MPAよりも常に遅くなります。これはSPAがページ上のHTMLをレンダリングするためだけに、ブラウザでJavaScriptアプリケーション全体をダウンロード、解析、実行する必要があるためです。さらに、SPAはリモートデータを取得する必要があるため、ページの読み込みが完了するまでに、もっと待ち時間がかかります。

ほとんどのSPAフレームワークでは、最初のページロード時に基本的なサーバーレンダリングを追加することで、このパフォーマンス問題を軽減しようとしています。これは改善策ですが、ウェブサイトが複数の方法と複数の環境（サーバー、ブラウザー）でレンダリングできるようになったため、新たな複雑さが生じます。また、アプリケーションのJavaScriptロジックがバックグラウンドでまだ読み込まれているため、サイトが読み込まれたように見える（HTML）にもかかわらず応答しないという、新しい「不気味の谷」問題が発生します。

MPAはすべてのHTMLをリモートサーバーでレンダリングするため、多くの場合、（たとえあったとしても）JavaScriptの実行をあまり必要としません。このため、MPAはSPAよりも初回ロードがはるかに速く、コンテンツ重視のWebサイトには欠かせない存在です。しかし、これにはトレードオフがあります。将来のページ遷移ではローカルレンダリングの恩恵を受けられないため、最初のページロード以降、長期にわたるユーザー体験はそれほど得られないのです。

Webサイトのルーターはどこに存在するのでしょうか。MPAでは、サーバーへのリクエストごとに、どのHTMLで応答するかを決定するため、ルーティング・ロジックはサーバーに格納されます。SPAでは、ルーターがブラウザでローカルに動作し、サーバーにアクセスすることなく新しいページをレンダリングするためにあらゆるナビゲーションをハイジャックします。

これは、前述のトレードオフと同様です。MPAは最初の読み込みが速く、SPAはJavaScriptアプリケーションがブラウザにすべて読み込まれると、2ページ目、3ページ目の読み込みが速くなる傾向にあります。

また、SPAはページレンダリングに関する多くの制御を行うため、ページナビゲーションでより強力なトランジション（遷移アニメーション）を提供できます。このサポートに対応するため、MPAはHotwireのTurboのようなツールを活用し、ブラウザのナビゲーションも制御してクライアントルーティングを模倣しています。HTMLは依然としてサーバーでレンダリングされますが、TurboはSPAのクライアントルーティングと同様に、ページ間のシームレスな遷移を表示できるようになりました。

SPAは、複雑な複数ページの状態管理を扱うWebサイトのアーキテクチャとして優れています（例：Gmail）。これは、SPAがウェブサイト全体を単一のJavaScriptアプリケーションとして実行し、アプリケーションが複数のページにわたって状態とメモリを維持できるためです。受信トレイや管理者用ダッシュボードのようなインタラクティブでデータ駆動型のエクスペリエンスは、Webサイト自体が本質的に「アプリ的」であるため、SPAとしてうまく機能するのです。

MPAとSPAを比較する場合、「より良い」「より悪い」という選択肢はありません。すべてはトレードオフの関係にあるのです。

Astroでは、MPAのパフォーマンスとシンプルさを優先していますが、これは、コンテンツに特化したWebサイトという私たちの使用目的にもっとも合致しているからです。 ステートフルでインタラクションを多用するWebサイトでは、ファーストロードのパフォーマンスを犠牲にしてでも、SPAがもたらすアプリのようなアーキテクチャの方が、有益な場合があります。

以下は、私たちが知っているすべてのAstroの比較事例です。

• Astro vs. SPA (Next.js) - 94% JavaScriptを削減
• Astro vs. SPA (Next.js) - 34% ロードが速い
• Astro vs. SPA (Next.js) – ネットワーク使用量を65％削減
• Astro vs. SPA (Remix, SvelteKit) - 『あの「Lighthouseのスコア」はすごいですね。』
• Astro vs. Qwik - 43% 高速なTTI

もし、公開されているマイグレーションやベンチマークをご存知で、ここに掲載されていない場合は、PRを作成し追加してください。

もっと詳しく知りたい方は、Surma（Google）とJake Archibald（Google）が、このトピックについて素晴らしいやりとりを記録しています。