この記事でわかること

フロントエンドのアーキテクチャを「SPA vs MPA」という視点で選定するポイントをご紹介します。

はじめに

開発や改修、保守などの業務で、SPA開発の代表的なフレームワークの一つであるVue.jsを１年ほど使っています。その中で「このシステムはそもそもなんでSPAで作ってあるんだろう？」「SPAとかMPAってそれぞれどんなポイントで選ぶものなのか？」という根本的な部分の整理ができていませんでした。

エンジニア2年目、まだ私自身が先頭に立って技術選定をする機会は少ないものの、「SPA vs MPA」みたいなテーマを語れるようになりたい！と考え調べる中で、そういったテーマをひととおり網羅している記事を見つけました。

**********************************************

ASPER BROTHERS BLOG
“Single Page Application (SPA) vs Multi Page Application (MPA) — Which and when to use?”

https://asperbrothers.com/blog/spa-vs-mpa/

**********************************************

上記の記事は、これからアプリを作るにあたって、SPAとMPAのどちらを選んだらいいか分からないという開発者向けに、SPAとMPAのプロコン比較を様々な観点から行ったものです。

開発上の利点比較もあれば運用上の利点比較もあり、両アーキテクチャの開発経験者が読んでも、腑に落ちる部分や新たな発見があると思います。

本記事は、上記の記事を要所要所で引用・翻訳しつつ、自分の実体験を肉付けとして、MPAと対置したときのSPAの特徴について記述します。技術選定というより、実際の開発や保守でSPAに関わったデベロッパーという立場から見えたポイントを挙げていくため、内容に多少偏りがあると思いますが、ご承知おきください。


SPA vs MPA – 違いは何？

細かい比較に入る前に、まずSPAとMPAそれぞれの定義を引用してみます。

A single-page application is a more modern approach to app development, it was used by Google, Facebook, Twitter, etc. A SPA is an app that works inside a browser and does not require page reloading during use.

A multiple page application, on the other hand, is considered a more classical approach to app development. The multi-page design pattern requires a page reload every time the content changes. It’s a preferred option for large companies that have extensive product portfolios, for example, e-commerce businesses.

SPA(シングルページアプリケーション)とは、比較的モダンなアプリ開発アプローチであり、GoogleやFacebook、Twitterなどで使われています。SPAはブラウザ上で動作し、使用中にページのリロードをする必要がありません。

いっぽう、MPA(マルチページアプリケーション)は、比較的クラシカルなアプリ開発アプローチと考えられています。MPAのデザインパターンでは、コンテンツが変わる度にページのリロードが必要です。ECビジネスなど、広範な商品ポートフォリオを持った大企業に好まれます。

SPAとMPAの技術面での細かい違いを挙げようとすればきりがないと思いますが、引用元の記事では「リロードをする必要性があるかどうか」というキーワードによって両者を区別しています。

SPAはページが一つしかないので、基本的にはページそのものの情報は一度読み込むだけでよいというわけですね。この最小限のリロードを実現できるようにした仕組みがSPAであるという言い方もできそうです。

次に、具体的にそれがどんなメリット、もしくはデメリットに繋がるのかという点を詳しく見ていきます。

SPA vs MPA – どっちを選ぶ？

はじめに、引用元記事の内容を要約した比較マトリクスを置いておきます。

SPAMPA
読み込み速度○×
結合度の低さ○×
検索エンジン対策×○
モバイル端末対応○△
情報アーキテクチャ△○
セキュリティ対策
(労力の少なさ)		○×
セキュリティ対策
(安全の度合い)		×△
開発スピード○×
JavaScript
への依存度の低さ		×○

元記事の内容から訳者独自作成。
○が選定にあたってポジティブ、×が選定にあたってネガティブな意味になるよう文言を調整。



一目見て分かるのは、SPAもMPAも一長一短だということです。モダンなSPA、古典的なMPAという捉え方は前段の引用でも語られていましたが、これから新規に開発するシステムならイマドキなSPAがよい、などという単純な話ではなく、目的に応じて両者を選び分ける必要があります。

図に起こした各観点のくわしい比較については元記事を読んでいただくとして、以下では私の実体験から、４つの比較観点を紹介しつつ、所見を加えていきます。

読み込み速度

“Speed”と題して両者の比較を行っている部分を引用します。

SPA’s load faster. Why? As it loads the majority of app resources just once. The page doesn’t reload entirely, whenever a new piece of data is requested by the user. 

MPA is slower as the browser must reload the entire page from scratch whenever the user wants to access new data or moves to a different part of the website. The optimal loading time for a website is 0.4 seconds. If your website or app is image-heavy then choosing a SPA is a safer option. 

ロードの速さでは、SPAに軍配が上がります。これは、大部分のアプリケーションリソースが一度しか読み込まれないためです。ユーザが新たにデータを要求したときに、ページ全体が再読み込みされることはありません。

MPAでは比較的速度が遅くなります。これは、ユーザが新たにデータを要求したり、サイトの別の場所へ遷移したりするたびに、ページ全体を一から再読み込みしなくてはならないためです。WEBサイトの最適な読み込み時間は0.4秒です。サイトやアプリの画面に画像が多い場合は、SPAを選んだ方が無難でしょう。

これは初めてSPAの案件に携わったときに実感しました。SPAの場合、初回アクセス時に一度ページを読み込んでしまえば、ページのコンテンツに関してはもう追加的な読み込みが必要ないのです。

アプリ内で画面移動をする際、MPAであればサーバから追加的にコンテンツを読み込むところですが、SPAの場合ユーザのブラウザ上でJavaScriptがゴリゴリ動いてコンテンツを書き換えてくれるので、仮にネットワークが重かろうがページ遷移に伴うストレスは最小限で済みます。

コロナ禍でテレワークに入ったばかりの頃、当時の我が家の貧弱ネットワーク環境では開発用のアプリケーションサーバにVPNでアクセスするだけで結構な苦労を伴ったのですが、アプリのページに辿り着いてしまえば、それまでの遅さが嘘のようにさくさく動くので、デバッグやテストの際は、「SPAで助かった…」と思ったのを覚えています。

他方、SPAであっても、ひとたびAPIリクエストを投げると、（当然のことですが）HTTP通信は貧弱ネットワークを通じて地獄の遅さを見せていましたので、SPAにおける「速さ」の正体は、「ページコンテンツの読み込みを不要にする仕組み」に尽きるのだということも同時に実感しました。(そして何より、このときはテレワーク時のネットワーク環境がいかに大事かを実感しました…。)

結合度

次に、“Coupling”と題して比較を行っている部分の引用です。

SPA is strongly decoupled meaning that front-end and back-end are separate. Single-page applications use APIs developed by server-side developers to read and display data. In MPA’s, front-end and back-end are more interdependent. All coding is usually housed under one project. 

SPAはフロントエンドとバックエンドが分離されており、その意味で結合度が非常に低いアプローチです。SPAはデータの読み込みや表示の際に、サーバーサイドで開発されたAPIを利用します。MPAでは、フロントエンドとバックエンドはより相互依存的で、両者のコードは大抵一つのプロジェクトの中に一緒に格納されています。

SPAはサーバとの通信に頼らずにページコンテンツを生成するアーキテクチャですので、ページコンテンツの生成処理ロジックを担うフロントエンドの資源は、サーバーサイドの処理を担うバックエンドの資源からはっきりと独立することになります。両者の関係性も、かたやAPIリクエストを投げ、かたやそれに対するレスポンスを返すのみという明快なものです。

私が業務で初めて触ったSPAのアプリケーションも、フロントエンドとバックエンドは別プロジェクトとして資源管理されていました。フロントエンドを中心とした改修に携わった際には、両プロジェクトの責任の分担が明確であることから、不具合の原因追及などが非常にスムーズだった印象があります。

また、フロントエンドとバックエンドとが疎結合であることは、疎結合な実装の「互換性や拡張性に優れる」という特徴から、後述するように開発プロセス上の利点として現れてきます。

開発プロセス

“Development process”の項目を引用します。

One of the greatest advantages of SPA’s is the reusable backend code. If you’re thinking reusable code equals less work, then you’re right. You can apply the same code you used in your web app to your native mobile app. It’s an important piece of information, as applications and websites are frequently used on mobile devices – which is no surprise since most of us are constantly on the run. 

Also, thanks to the clear division between front-end and back-end, both parts can be developed simultaneously which speeds up the entire development process. MPA’s take longer to develop as in most cases, the server-side has to be coded from the beginning. 

SPAの最も優れた利点の一つに、バックエンドを再利用できるという点があります。コードが再利用できるということは、開発の労力が減るということです。開発者は、WEBアプリで使われていたバックエンドをネイティブモバイルアプリに使いまわすことができます。アプリケーションやウェブサイトが頻繁にモバイル端末から利用される現在、この利点は無視できません。

加えて、フロントエンドとバックエンドが明確に分離されているおかげで、両者の開発を同時並行で進め、開発プロセス全体を加速させることができます。サーバーサイドを一から書かなければならないMPAの開発は、殆どの場合SPAよりも時間がかかります。

ここに関しては、読みながらうんうんとうなずいていました。

私が関わっていた案件の一つに、既存システムのモバイル端末対応というものがあり、これはまさに引用元にある活用例の通り、既存システムのバックエンドモジュールを使いまわしてモバイルアプリを構築するという内容の案件でした。

フロントエンドとバックエンドが疎結合であるSPAでは、互換性のある別のフロントエンドモジュールを作って既存バックエンドのAPIを再利用すれば、それだけで新たな装いのアプリケーションを構築することができます。

あるシステムのマルチデバイス対応を考えたとき、煩雑なデバイス判定ロジックや、調整に限界のあるレスポンシブデザインをきらって専用モジュールの別途開発に踏み切ることはままあることだと思いますが、このように舵を切る場合、MPAよりSPAの方が圧倒的に少ない工数で済むはずです。また、とりあえずSPAで作っておけば、こうした拡張性をシステムに持たせておくことが可能になります。

JavaScriptへの依存

ここまで紹介してきたような観点は、SPAのメリットを挙げるようなものばかりでしたが、もちろんデメリットもあります。それは、JavaScriptに大きく依存していることです。

SPA lives and breathes JavaScript, which can be problematic. […] If the app is run on a browser with disabled JavaScript, it can cause problems with app functionality which might result in higher bounce rates and lower conversion. JavaScript reliance also contributes to its problems with SEO optimization and security issues. MPA’s can be built without any JavaScript dependency. 

SPAはJavaScriptに大きく依存しているため、それにより問題が起こる可能性があります。（中略）JavaScriptを無効化するブラウザでアプリが実行された場合、アプリに機能的な問題が発生する可能性があります。その場合ユーザはサイトをすぐに離れてしまい、サイトのコンバージョンも達成されないでしょう。JavaScriptへの依存は、SEOやセキュリティの問題にも繋がります。MPAであれば、JavaScriptに依存せずに構築することが可能です。

MPAであれば、ページの動的制御に少し使う程度の役割を担うことが多いJavaScriptという要素技術が、SPAの場合、非常に多くの役割を担うことになり、結果多くの問題に行き当たります。

引用元の記事で言われていることを列挙すると、次のようになります。

  • 動的に生み出されるコンテンツが検索エンジンに引っ掛かりにくいせいで検索順位が落ちる(＝SEO対策に難あり)
  • コンパイルを伴わないJavaScriptへの依存度が高いため、ハッカーの攻撃を受けやすい
  • ブラウザ毎にJavaScriptの対応状況が異なるため、JavaScriptに依存するぶんマルチブラウザ対応は大変になる

私関わっていた案件は、使用ブラウザを固定した、社内ネットワークで動くエンタープライズアプリだったため上記のようなデメリットはあまり実感を伴って理解できているわけではないのですが、コンシューマー向けアプリの場合に置き換えて考えてみると、上記のデメリットがいずれも深刻であることは理解しやすいです。

引用元記事に書かれたこれらのデメリットは、要件定義時に頭を悩ませる問題、もしくは要件定義時に頭を悩ませなかったことで運用時に問題となるようなものだと思うのですが、実際に私が携わったSPAの実装フェーズでも、JavaScriptへの依存から来る問題に苦労させられました。

具体的には、MPAであればJavaなど同期処理を基本として動くプログラムに任せていたような処理もSPAではJavaScriptに任せることになりますので、MPAの感覚でコードを書いていると思わぬところでプログラムの非同期実行が起き、しばしばドツボにハマっていました。これは、SPAが大きく依存する技術であるJavaScriptへの理解が浅かったことが原因です。

少し拡張して言えば、単純に、実装上のTipsがSPAとMPAとでは異なるということなのでしょう。そしてSPAは比較的新しいアプローチであり、MPAと比べれば構築経験のある人が少ないです。従ってSPAの開発にあたって、きちんとSPA特有のTips―特に、中心技術としてのJavaScriptの特性をおさえることができなければ、実装フェーズにおいて苦労することになります。

まとめ

本記事では、開発や保守のフェーズでSPAに携わった筆者が、SPAとMPAの比較記事を軸にしてSPAの特徴を述べてきました。

SPAというアーキテクチャは動作も早く、開発プロセス上の利点も多くあります。ただし、利点に対する副作用としてJavaScriptへの依存の度合いが大きくなっています。実装時に多少のTipsが必要なのはもちろんですが、SEO対策やセキュリティ対策、マルチブラウザ対応等に難ありというSPAの弱点は、いずれもJavaScriptへの依存から来るものであり、技術選定の段階でも注意が必要です。

なお、引用元の記事では、本記事では言及できなかったMPA特有の強みなども載っていますので、本格的に技術選定を見据えてSPAとMPAの比較検討をされたい方は、ご一読をおすすめします。

引用文献

Single Page Application (SPA) vs Multi Page Application (MPA) — Which and when to use?