非エンジニアのための基礎知識③シングルページアプリケーションを知ろう
みなさんこんにちは、のっちです。
前回まで、非エンジニアのための基礎知識ということで、web開発、言語の仕組みについてまとめてきました。
①『web開発の仕組み』はこちら
②『言語の仕組み』はこちら
第3回は、webでの体験を大きく飛躍させるシングルページアプリケーション（以下、SPAと呼びます）についてまとめていきます。
多くの有名サービスで取り入れられているSPA。エンジニアのみならず、プロダクトに関わる方なら誰もがこのSPAについて知っておく必要があります。
今回は、SPAの仕組みや利用するメリット・デメリット、どのようなサービスに採用すべきか、プロダクトづくりを行うときに考えるべきことをまとめていきたいと思います。
SPAとは
SPAとは、複数ページではなく、単一のページで構成されたwebアプリケーションまたはwebサイトのことを指します。
単一のページで作成することで、新しい情報を読み込むときにページの遷移を伴う必要がありません。
ちょっとピンとこない方もいるかも知れないので、例を出していきます。
SPAが使われている例
例えばFacebookのメッセンジャーを考えてみましょう。
FacebookのメッセンジャーはSPAが採用されています。
たとえばある友人とのメッセージ画面にいて、他の友人のメッセージを見ようとした場合、ページ遷移をすることなく別の画面の情報を見ることができますよね。
これは、SPAで単一のページでできているからこそ、webなのにまるでアプリのようにページ遷移無しで他の情報を見ることができます。
trelloは、タスクの追加や移動にページの更新を挟む必要がありません。
「使い心地がいいなあ」と思うWebサービスのいろいろな箇所でSPAは取り入れられています。みなさんが携わっているサービスの一部でも取り上げられているかもしれません。
SPAはどのようにしてできているのか
SPAを従来のwebアプリケーションと比較してみましょう。
SPAは、ブラウザとサーバー間のやり取りが異なります。ブラウザはクライアントのことですね。（クライアント・サーバーの話は第1回でまとめたので詳しく知りたい方はこちらを参考にしてください。）
従来のwebアプリケーションは、サーバーに全ての種類のページを保持していて、ブラウザがリクエストしたページに対して新しいHTMLファイルを送り、それをブラウザで表示する、といったものでした。
SPAでは、ブラウザがリクエストする内容が異なります。
ブラウザには最初に基本となるHTMLファイルが送られており、新しいページをサーバーから取得する際、その差分のみをリクエストします。
そして、サーバーから差分のみを返してもらい、それを同じHTMLファイルを使って表示します。
これによって、ページを更新することなく、サーバーと通信することができます。
このようなやり取りがどうしてできるかと言うと、Ajaxという通信処理を使っているからです。Ajaxという言葉もよく使われるので、ここでAjaxについて触れておきたいと思います。
（少しだけ詳しく）Ajaxとは
Ajaxは「Asynchronous JavaScript + XML」の略で、「JavaScriptとXMLを使って非同期でサーバと通信すること」という意味です。
通常、プログラム処理は1つずつ行われ、同時に複数の処理が走ることはありません。これを同期処理といいます。
しかしAjaxでは、プログラムでメインの処理が走っている裏で、HTMLの指定した部分を書き換えるためにサーバーと通信を行うことができます。プログラムが並行して走っている形となるので、非同期処理と呼ばれます。
サーバーと通信して返ってくるのはJSONというデータ形式で、この形式をJavaScriptが読み取り、非同期で部品を更新することができます。
例えば郵便番号を入れると、ページ全体が更新されずに住所が候補表示されることがあると思いますが、Ajaxが使われた処理です。
まとめるとこのような仕組みになります。
GoogleMapはどこを検索してもページ遷移無しで新しい情報を取得できますが、これはAjaxによって実現しています。
Ajaxによって、SPAのように新しい情報を取得しても更新を必要としないweb開発が可能となります。
サービス開発におけるSPAのメリット
さて、それではSPAを採用するとどのようなメリットがあるのでしょうか。
現在SPAの開発に携わっているので、その経験も含めてまとめていきます。
①ユーザーにストレスのないページ遷移
SPAでは従来のwebサイトのように、ページを遷移するごとに新しいHTMLを表示するということがありません。そのため、高速に新しい画面を表示することができ、ユーザーに待ち時間を与えることがありません。
何度も更新したりページ遷移したりするアプリケーションにうってつけの機能と言えます。
②アプリのような体験を提供できる
SPAでは共通の部品は更新せずに差分だけ更新するので、例えばメッセンジャーのようにユーザー一覧は表示したままチャットコンテンツを切り替えたり、Spotifyでページを変えても音楽を流しっぱなしにしておいたりと、アプリのような体験を提供することができます。（WebのSpotifyを使ってみてください。）
③アプリに必要なことを考えなくてよい
これはMacアプリなどと比較したときのメリットです。
通常iOSアプリやMacアプリ、Androidアプリをリリースするとき、考えなくてはいけない重要なポイントがいくつかあります。
・審査に出す必要：アプリでは審査を通過する必要があり、場合によってはその対応に数週間かかる場合がありますが、webなのでその審査を受けることなくアプリケーションをリリースすることができます。
・デバイスごとの挙動：これもwebなので当然といえば当然ですが、ブラウザで表示するので、デバイスによらずサービスを提供することができます。
④運用が楽
③に続いてですが、アプリを開発し、複数のデバイスで別の開発ラインを走らせていると、当然改修の工数が膨らみます。バージョン管理も大変になります。
この点、webであれば（ブラウザによる違いを考える必要はありますが）シンプルな開発ラインで改修を行うことができます。
⑤SEOに弱いわけではない（と言われている）
これはメリットではないのですがプラスポイントなのでここに入れておきます。
コンテンツの豊富さが求められるSEO（Googleなどの検索エンジンに上位表示させるための手法）ですが、Googleの使用するクローラーの仕様的にSPAで動的に表示した部分が読み込まれないのでは？という課題が指摘されていました。
しかしGoogleとしてはそこまで関係ないと言及しており、また仮に読み込まれなければ別の手法（サーバーサイドレンダリングなど）で回避することができます。
関連がないわけではないのでチェックしておく必要はありますが即NG、というわけではありません。
SPAとSEOの関連について詳しく知りたい方は以下を参考にしてください。
サービス開発におけるSPAのデメリット
逆にSPAのデメリットについても触れておきます。
①初期ローディングに時間がかかる
SPAは「どの処理でどの差分を必要とするのか」をフロントエンド（JavaScript）で記述するので、その分ブラウザで読み込むコード量が増加します。そのため、最初のページを読み込んで表示するまでに時間がかかります。
先程「SEOに弱いわけではない」と書きましたが、ローディングに時間がかかるwebサイトはGoogleの評価を落としてしまうので、処理速度を保つことをより意識する必要があります。
②実装コストがかかる
これまでとは異なる差分を意識した処理が求められるので、フロントエンドの実装に多くの時間がかかります。
また、エンジニアも最新知識を探りながらの開発となるので、多少の開発遅延の原因になる可能性があります。これは開発チームと相談する必要があります。
③モバイルアプリとのユーザー体験の差がある
PC画面はアプリと遜色がないとしても、モバイル画面での体験の差は大きくあります。
・プッシュ通知：SPAだとできる通知に限界があります。またiOSではSPAでのプッシュ通知は採用されていません（iOSアプリを作って欲しいので今当然といえば当然です）。これはでかいですよね。
・画面の大きさ：ブラウザだと上下にブラウザ用のボタンが表示されるので、狭いモバイル画面をサービスのために使うことができません。
・タッチジェスチャー：モバイルアプリだとピンチインなどのジェスチャーが使えますが、同じようなことがSPAだとできないことがあります。
その他、アプリだと比較的簡単に使えるカメラや決済などの機能、位置情報なども追加の手順が必要となる場合があります。
④モバイルのホーム画面に登録してもらえない
PCであればブックマークが簡単に呼び出せるのでアプリと大差ありませんが、モバイルではwebをホーム画面に登録する機会はあまりないのではないでしょうか。
普段使いしてもらうサービスになるのが必然的に難しくなります。
⑤採用が難しそう
SPAで作られたサービスはまだまだメジャーではなく、特に国内だとそこまで数は多くありません。そのため、SPAの実装に対応できるフロントエンジニアはそれほど多くなさそうです。デザイナーも多いとは言えないと思います。
メリット・デメリットをまとめると以下のようになります。
どんなサービスに使用するべきか
ここまでメリット・デメリットについてお話しました。
それでは、どのようなサービスにSPAを採用するべきでしょうか。
SPAは最初の更新が終わってしまえば、その後ユーザーがいろいろな操作をしても更新のタイムラグを挟むことがありません。そのため、アプリのようにユーザーの操作が多く、滞在時間が長いサービスはSPAに向いていると言えます。
ダッシュボードでデータを可視化する必要のあるサービスなどは、ユーザーの操作が多いと考えられるのでSPAの採用を考えるのが良いでしょう。
また、タスク管理やメッセージなど常に開いておいて様々な情報にアプローチするサービスなどにも有用です。
逆に、滞在時間が長くないWebメディアや直感的な操作を第一としないサービスでは、SPAは費用対効果が低くなる可能性があります。
「サービスの挙動を早くしたいのでSPAを取り入れたほうがいい！」というのは少し考える必要があります。
というのも、SPAは同時に情報処理することはできますが、データの更新が早くなるわけではありません。データ処理を早くするためにはバックエンドの仕組みを再考するのがベターであると言えます。
プロダクトづくりの際に考えること
これらの情報を踏まえて、最後に、プロダクトマネージャーやデザイナーがSPAに関わる際に特に考えるべきことについて、まとめていきたいと思います。
webサービスだからと諦めていた体験を再考する
従来のwebでは情報を取得するたびに更新が必要だったので、「入力によってリアルタイムにAとBを使い分けて表示」「CをしながらDをする」などの体験はwebでは実装が困難でした。
しかしSPAであれば部品ごとの取替で更新が必要ないため、これまで諦めていた体験ができる可能性があります。画面を分割した新しい体験を届けることもできるかもしれません。
「〜のような体験を届けたい」をエンジニアに伝え、工数との兼ね合いで議論しましょう。
初回ロード時間に対する意識を持つ
SPAは最初の更新に時間がかかります。多くのエンジニアを抱えるSlackやメッセンジャーですら、他のwebページと比較すると初回の読み込みに時間がかかることがわかると思います。
そのため、1人あたりの滞在時間が短いwebサイトにおいてSPAは適していません。
また、SEOを重視することを考えているのであれば、SPAを採用する場合はロード時間に特に気を配る必要があります。
画面のつながりを意識したデザイン
SPAは部分的な通信を行って画面の一部を変更していく実装なので、画面設計に関する一貫性が求められます。
また、画面ロードが行われないので、ユーザーが情報の更新に気づかない可能性があり、不必要な画面部品の変更は混乱を生む危険性が高いです。
そのため、独自性を意識したデザインよりは、どこにどんな機能があるか予測しやすい「わかりやすい」デザインが求められると言えます。
このあたりは、web、モバイルに対応できるマテリアルデザインを頭に入れておく必要があるでしょう。
コンポーネントを意識したデザイン
SPAは部品ごとに呼び出すため、同じコンポーネントを使ったデザインを心がけると、より効率的に実装することができます。
コンポーネントを使い回す際、同じ操作では同じような挙動をするようにデザインすると、ユーザーも開発者も戸惑うことが少なくなります。また、コンポーネントは見た目だけでなく、操作時のインタラクションなども統一しておくことが望ましいでしょう。
現在関わっているプロジェクトではAtomic Designを採用しています。コンポーネントの使い回しを念頭に置いたシステムなので、SPAと相性が良いと言えます。
それぞれのURLでの挙動を考える
SPAはアプリと違い、操作時にURLが発行されます。同じ画面であるように見えても、サーバーに対してリクエストする際はURLが異なります。
URLが発行されるということは、そのURLを他者にシェアしたり、ブックマークしたりする可能性があるということです。
全てのURLを厳密に考慮する必要はありませんが、特定のURLを開いたときにユーザーにどの画面を見せるべきなのか、考えてエンジニアとコミュニケーションを取る必要があります。
モバイルに対する対応を考える
SPAのデメリットに書きましたが、モバイルはネイティブアプリと比較するとユーザー体験が低下する点が多いです。
実際、上で紹介したFacebookメッセンジャーやGoogleMapはモバイルではネイティブアプリを出しています。
サービスとして大きくなった後もモバイルに対する方針は様々で、モバイルにも対応しているサービスとそもそもモバイルでは見ることのできないサービスがあります。
モバイルの操作性を重要視するサービスではSPAの採用は（現状）難しそうです。
まずPCでの操作性を担保したデザインを作り、モバイルも簡単に対応しておく、もしくはPCへ誘導することが初期のリリースでは考えられます。
そしてモバイルでの用途が増えてきたタイミングで対応するのがベストでしょう。
まとめ
今回は、SPAの仕組みやメリット・デメリット、サービスに採用する際に考えるべきことについてまとめました。
webの可能性を高めてくれるSPAですが、注意すべきポイントもあります。是非今回の記事を参考に、エンジニアと対話していただければと思います。
それでは、またよろしくお願いします。
この記事が気に入ったらサポートをしてみませんか？