少し前からWeb業界で多く聞かれるようになってきた「SPA(Single Page Application)」という技術ですが、皆さんはその正体をご存知ですか?
「興味はあるけど学習に手が回らない」というエンジニアの方や「導入してみたいけどそもそもメリットあるの?」という企業の方も多いのではないでしょうか。
今回はそのような方々に向けて、SPAの特徴やその導入に必要となる技術、そして実際に導入した際のメリット・デメリットについて、簡単に分かりやすく説明させていただきます。
これを機にSPAに対するハードルをガクッと下げていただければ幸いです。
SPAとは何か?
SPAとは「Single Page Application」の略であり、日本語に訳すと「単一(シングル)ページのアプリケーション」になるかと思います。
単に直訳しただけだといまいち分かりづらいと思いますが、要は「1枚のページのみで構成されているアプリケーション」をイメージしていただければよいかと思います。
ここで第一のハードルが待ち構えているかと思います。
これまでWeb業界に携わってこられた方からすると、「1枚のページのみ」という部分に大きく引っかかると思います。
それもそのはず、「会員登録ページ」や「レストランの検索結果ページ」、「お問い合わせページ」などの数多くのページが合わさって初めて一つのWebアプリが完成する、というのがこれまでの常識だったと思います。
しかし実際に、このこれまでの常識を根底からひっくり返し、「1枚のページのみ」でWebアプリを完成させることができるようになったのです。
SPAを支える技術
では、なぜ「1枚のページのみ」でWebアプリが開発できるようになったのでしょうか?
このSPAを支えているのはズバリ「Javascript」になります。
その技術を読み解く前にまずは従来のWebアプリのページ表示の仕組みを見直してみましょう。
- 1. ユーザーがページへアクセスする(=リクエスト)
- 2. サーバーがユーザーからのリクエストを受け取る
- 3. サーバーがアクセスされたページのHTMLを生成し、ユーザー側(ブラウザ)に返す(=レスポンス)
- 4. ブラウザ上にページが表示される
概ね上記のような流れでリクエスト/レスポンスが繰り返されることになり、ページへのアクセスが来るたびにサーバーはページを隅から隅まで生成してユーザー側へ返していました。
この「隅から隅まで」という部分が重要なのですが、通常のWebアプリではユーザーの属性に関わらず共通化されている箇所は多いですよね?
(例えば、ユーザーAとユーザーBがいて、それぞれがFacebookにログインした際にプロフィールや投稿の内容などユーザー固有の情報以外のデザインは変わらないですよね。)
SPAでは、そのような共通化されている箇所は初回ロード時にまとめて生成(ここで「1枚のページ」が出来上がります)し、それ以降は必要な情報(プロフィール情報や投稿の内容)のみをサーバーへ要求するという方法を採用することで、ページ表示速度の向上を実現しているのです。
これらを踏まえると、SPAでのWebアプリのページ表示の仕組みは以下のようになります。
- 1. ユーザーがページへアクセスする
- 2. (初回ロード時のみ)ブラウザ側でページ全体が丸ごと生成される
- 3. 必要なデータのみサーバーへ要求する(=リクエスト)
- 4. サーバーがユーザー側(ブラウザ)にデータを返す(=レスポンス)
- 5. サーバーから帰ってきたデータをJavascriptで処理し、ページを表示する
- 以降、ページを遷移する毎に3〜5が繰り返される
つまり、必要なデータのみリクエストすることでサーバーとの通信量を最小限に抑えることができるようになり、これによってページ表示速度の大幅な向上が実現できているのです。
SPAのもう一つのメリット
SPAを導入した際の最も大きなメリットは、先ほどもご紹介した通り、「ページ表示速度の大幅な向上」が挙げられます。
1秒でも表示速度が遅くなるとユーザーの直帰率が大きく上昇すると言われている昨今、SPAを導入にすることによって他のサービスと大きく差別化できるということはとてつもなく大きなメリットだと思います。
このメリットだけでもとてつもなく大きな効果があるのですが、SPAにはもう一つ大きなメリットが存在しています。
それは、ネイティブアプリの代替手段になりうるということです。
ネイティブアプリとは
ネイティブアプリとは、PCやスマホなどの端末内にダウンロードして使用するタイプのアプリケーションを指します。
皆さんが普段スマホで使用している「LINE」や「Gmail」などのアプリを想像していただくと分かりやすいかと思います。
SPAの導入によりWebアプリでありながらもネイティブアプリのような機能(オフラインでのページ閲覧、プッシュ通知、ホーム画面からの起動 など)を実装することができるようになるのです。
この考え方はPWA(Progressive Web Apps)と言われ、Googleからも提唱されている技術となります。
通常、まずWebアプリを開発し、そのWebアプリのiOSアプリ/Androidアプリ版をリリースしていくのは非常に手間がかかってしまいます。
その点、SPAの導入によりその手間を省くことができ、なおかつUXを格段に向上させることができるため、非常に大きなメリットの一つと言えるでしょう。
SPA導入のデメリット
これまで非常に大きなメリットを二つご紹介してきましたが、もちろんその影にはデメリットも存在します。
私の考えるデメリットは以下の3点になります。
- 1. SPAを扱える開発者が少ない
- 2. 実装コストが大きくなってしまう
- 3. 初回のページロードに時間がかかってしまう
SPAを扱える開発者が少ない
まずは、SPAを開発できるエンジニアがまだ少ないということが挙げられるでしょう。
SPAを開発するには、通常のWebアプリを開発するのに比べて必要な知識が格段に多くなってしまいます。
具体的には、Webページの制作スキル(HTML/CSS)はもちろんのこと、SPAの主要技術であるJavascript、及びその周辺技術に対する理解を深めておかなければなりません。
また、SPAを構築する際には必ずと言って良いほど何かしらのライブラリやフレームワークを導入する必要もあるため、それらに対する理解も必要となります。
今後徐々に増加していくことが見込まれますが、現時点ではSPAを扱える開発者はまだそれほど多くなく、SPAを導入したいと思ってもすぐに導入できるような環境は整っていないのが現状です。
実装コストが大きくなってしまう
SPAではそれまでブラウザの機能に頼っていた機能(「戻る・進む」の履歴管理や画面遷移時のローディング表示 など)を実装する必要があるため、それだけでも開発コストが格段に上がってしまいます。
それほど特殊でない機能であれば、フレームワークに標準で実装されていたり、ライブラリを導入することで解決することも多いのですが、開発するアプリケーションの要件によってはゼロから実装する必要もあるため注意が必要です。
また、SEOの観点からもサーバーサイドレンダリング(以下「SSR」とします)という技術を用いる必要もあります。
SSRとは、簡単に言うと、初回のページロード時にブラウザ側ではなく、サーバー側でページ全体を生成してしまおうという考え方です。
(詳しくは別の機会にご説明させていただきますね。)
通常のSPAの場合、Javascriptでの処理によってページを生成するのですが、この点がSEOの観点で少し不安が残るのです。
通常、SEOのためにはGoogleなどによるクロールによってWebページでの表示順位が決まってくるのですが、このクロールプログラムがきちんとJavascriptを理解してページを読み取ってくれるかが不確実なのです。
(Google側は「クロール技術は向上しておりJavascriptも読み取れる」と言っているのですが、本当に100%正しく読み取ってくれるかは正直なところ不明です。)
SSRを実装する場合、サーバーサイドの知識も必要となってしまうことがあるため、より一層開発コストが大きくなってしまいます。
初回のページロードに時間がかかってしまう
SPAの導入によってページ遷移の速度ははるかに向上するのですが、逆にJavaScriptのコード量ははるかに増えてしまい、かつこれまでサーバー側で行っていたページの生成をブラウザ側で負担することとなるため、どうしても初回ローディングにかかる時間は増えてしまいます。
こちらについては、上記でご説明したSSRを実装することで改善は可能なのですが、その分の実装コストがかかってしまうこととなります。
どんなサービスでSPAを採用すればいいの?
では、メリットとデメリットを考慮した上で、実際にはどのようなサービスで採用すべきなのでしょうか?
SPAの大きなメリットとしては、ページの遷移/表示速度にあります。そのため、ユーザーが頻繁にページ遷移をするサービスに適していると言えます。
(例えば、口コミや評判などを分析するサイトやチケット購入のサイト等はユーザーが繰り返し検索を行うことが見込まれるため、SPAに向いていると言えるでしょう。)
一方で、ブログのようにユーザーの直帰率が高いサービスはSPAにはあまり適していません。
SPAの特徴としては、サービスに最初にアクセスした際のページ読み込みに多くの時間を必要とすることが挙げられます。そのため、直帰率が高いサービスにSPAを採用したとしても、初回のアクセス時にかかる時間が増加するだけであまり導入効果は無いと言えます。
これらの特徴を踏まえ、開発予定のサービス要件とも照らし合わせた上で導入する必要がありますね。
お仕事の途中ですが、少し一休みして、転職や独立について考えてみませんか🙌?
現役エンジニアが選ぶおすすめの転職エージェント11選【成功談・失敗談もあります】
レバテックフリーランスの評判ってどう?【現役エンジニアが徹底解説します】
MidWorks(ミッドワークス)の評判ってどう?【現役エンジニアが徹底解説します】
日々の業務に追われて自分を見失わないよう、
定期的にキャリアを振り返るようにしておきましょう🤲
最後に
さて、ここまでSPAの特徴とそのメリット・デメリットについてご紹介してきましたがいかがでしたか?
SPAはその導入効果が非常に大きい反面、実装する際のコストも非常に大きくなってしまいます。
また、サービスの要件によってはそのメリットも十分に享受することができないこともありますので、導入する際には事前にしっかりと検討するようにしましょう。
このブログを通じて少しでも「傍(はた)を楽(らく)にする」ことができていれば嬉しく思います。
最後まで読んで頂きありがとうございました。