SPA・SSRとは

皆さんが普段ご覧のウェブサイトは、SPAでしょうか。

SPA（Single Page Application）とは、単一のWebページでアプリケーションを構成する設計構造の名称のことです。従来のWebアプリケーションでは、ページの遷移のたびにページ全体がレンダリング（画面上に描写）されるようになっていますが、SPAではJavaScriptを用いることで、ページ内のHTMLの変更する部分のみを差し替えて、コンテンツの切り替えを行っています。

GmailやGoogle Map、Netflixなどは恐らくSPAのに分類されるものです。例えばGoogle Mapではメニューの中の項目をクリックすると、メインで表示されている地図はそのまま表示された状態で、必要な部分だけ画面が切り替わります。

実際にはどのような動作が行われているのか、通常のWebアプリケーションと比較し概要や仕組みを解説した上で、課題とその解決方法を考えます。

目次

• 通常のアプリケーションとSPAの処理の違い
• SPAのメリット・デメリット
• SSRとは

通常のアプリケーションとSPAの処理の違い

挙動を比較すると、以下のようになります。

通常のWebアプリケーション

1. ユーザがリクエストに関するアクションを実行する（ボタンやリンクを押下するなど）
2. サーバにリクエストが送信される
3. サーバ側で業務処理を実行する
4. サーバ側でHTML全体を生成して、ブラウザに返却する（レスポンス）
5. 返却されたHTMLが画面に表示される

通常のWebアプリでは、１つのアクションに対して変更がない部分も含めて、全てをサーバー側でリクエストのたびに生成する必要がありました。SPAではどのような挙動なのでしょうか。

SPA

1. ユーザがリクエストに関するアクションを実行する
2. サーバにリクエストが送信される(フロントエンドアプリがバックエンドアプリのAPIを呼び出す)
3. バックエンドアプリが業務処理を実行する
4. バックエンドアプリがレスポンスを返却する
5. フロントエンドアプリがレスポンスを基に、変更のある箇所のHTMLを編集する
6. 編集後のHTMLが画面に表示される

SPAの挙動の具体的な例

今回は、パス「/article」から「/article?id=10」に遷移する場合を想定します。

ここで「/article」は記事のインデックスページとし、「/article?id=1」や「/article?id=5」など記事詳細ページへの導線が貼られているとします。

まず、ユーザーは「/article」のページにアクセスします。この時にSPAのアプリケーションをダウンロードして実行します。SPAのアプリケーションとは、JavaScriptファイルのことで、HTMLのscriptタグで使用するファイルを指定します。

また、この時にダウンロードするJavaScriptファイルは、どのページにアクセスしても基本的には同じファイルがダウンロードされます。「/top」にアクセスしたからといって、トップページ用のSPAをダウンロードするわけではありません。

さて、SPAが実行されると現在のパス「/article」のページがレンダリングされます。必要であればajaxでデータを取得してきます。「/article」はインデックスページのため記事のIDが複数必要です。ajaxで複数の記事の情報を取得しますが、この際に記事の内容も取得することにします。

一度整理すると、現時点でユーザーはパス「/article」にいて、各記事の内容を含む情報を保持しています。

次にユーザーはSPAによってレンダリングされた画面内のリンク「/article?id=10」を押下します。

SPAはユーザーの押下アクションを検知し、「/article?id=10」に相当するページをレンダリングします。「/article」と同じように必要であればデータをajaxで取得しますが、今回の場合はどうでしょうか、「/article?id=10」のページに必要な、IDが10の記事の情報は既に保持しているため、わざわざajaxでデータを取得する必要はありません。見た目のスタイリングをするcssやそもそものhtmlはどうでしょうか、これらは実はSPAに含まれているため、既に保持していることになります。

結果的にこの例でユーザーは、データの取得を待つことなく記事を閲覧できることになります。また、もしサイトに共通なヘッダやメニューなどが有る場合、それらは再度レンダリングしません。「/article」にアクセスした時点で既にレンダリングされているためです。

では、「/article?id=10」のページにいきなり遷移する場合はどうでしょう。いきなりとは例えばブラウザのお気に入りからアクセスした場合などです。この場合ユーザーはSPAをダウンロード、実行するところに始まり、記事の情報もないためajaxで取得しなければなりません。

このように、SPAはHTML全体を都度ダウンロードして置き換えるのではなく、表示中のHTMLの一部を編集することで画面遷移を実現します。

SPAのメリット・デメリット

メリット

動作性の向上

変更が必要な部分のみを書き換えを行っていることで、表示速度が速く、滑らな画面切り替えが可能となります。

一度読み込んだページは、その後必要な部分のコンテンツのみを読み込んで必要な箇所のみを書き換えて表示させることで、動作性が向上します。

ユーザー体験(UX)の実現

例えば、動画や音楽を使用する場合は従来のWebページでは、ページ移動などの更新時にページ全体が再読み込みがされてしまうため、動画や音楽が途切れてしまいます。しかしSPAでは差分のみを更新することを行っているので、動画や音楽を再生させた状態で別のコンテンツに切り替えを行うことができます。

他にも例えばチャットウィンドウを表示したままで、他のコンテンツを変更させるなどといった機能を実現することができます。

またプッシュ型の通知機能を導入可能にするなど、幅広くいろいろな機能でユーザー体験を向上させることができます。

誰が書いても同じようなコードになりやすい

現在SPAの主要ライブラリはReact Vue.js Angularの3つです（日本国内だとVue.jsが一番多く使われていると言われています）。使用されているライブラリさえわかれば、ある程度はどこにどんなコードが書かれているのかを判別できます。プロジェクトを引き継いだ際に、アプリケーション全体をすぐに見渡すことができるのは大きなメリットと言えるでしょう。

デメリット

SEOに弱い

詳しくは後ほど触れますが、SPAの場合はHTMLではなく、HTMLタグを編集するためのJavaScriptで書かれたコード(プログラム)をサーバーが送信しているためです。

初期表示に時間がかかる

SPAでは差分だけ更新させる動作を行うため、フロントエンド側（JavaScript）の記述が必要です。

そのためフロント側でのコード量が通常の設計よりも増えてしまい、ブラウザで読み込む時間がかかってしまうため、最初のページ読み込み時にはその分時間を要します。

どちらのデメリットもWebサービスとしてはかなり致命的ですが、これらのデメリット2つを解消する技術が存在します。それがSSRと呼ばれるものです。

SSRとは

SSRとは、サーバーサイドレンダリング（Server Side Rendering）の略で、コンテンツをサーバー側でレンダリングするという意味です。

「コンテンツ」というのは最終的にHTMLの一部になるような情報(つまりデータ)、もしくはHTMLそのもののことを指しています。単純にコンテンツ=HTMLという認識で問題はありません。

私たちエンジニアが書いたプログラムは、ブラウザ側(クライアント側と呼ばれることもある)とサーバー側(バックエンドと呼ばれることもある)のどちらかで動作します。

ブラウザ側で動作する代表的なプログラミング言語がJavaScriptです。JavaScriptはh1タグやtableタグといったHTMLのタグやその中身を追加、変更・削除などを行うことができます。

一方でサーバー側で動作する代表的なものはPHP、Ruby、Java、C#….などと色々な言語があります。サーバー側のプログラムは基本的にHTMLを作成してから、ブラウザに返却するということをします。HTMLと言うより、HTML文書といった方がわかりやすいかもしれません。サーバーからブラウザにHTMLのルールに乗っ取った文字列を返すと言うことです。

ここで「サーバー側」の説明に記述した、ブラウザで動作するプログラミング言語のJavaScriptは、サーバー側でも動作します。

JavaScriptを動作するためのプログラムで、Node.js(ノードジェーエス)というものがあります(他にdenoと呼ばれるプログラムもある)。

サーバーにNode.jsをインストールすることで、サーバー側でJavaScriptを動作させ、HTMLのタグを編集することができるようになります。となると、前半で説明したSPAのレンダリングや、その際に必要であればデータを取得する処理はサーバー側で実行することができるようになります。

これがSSRです。

SPAはHTMLタグを編集するためのJavaScriptで書かれたコードをブラウザに送り、受け取ったブラウザがそのコードを実行して、コンテンツをレンダリングします。

対して、SSRはサーバー側でJavaScriptのコードを実行してHTMLを編集し、レンダリング済みのコンテンツをブラウザに送るということを行っています。

SPAの課題をSSRで解決

SEO対策

私たちが公開しているWebページは、「クローラー」と呼ばれるWebページの情報を集めて分析するためのプログラムによって分析されています。

集めるといっても私たちがアクセスするのと同じように、URLからページにアクセスしています。そのためアクセスログを確認すると、クローラーがWebサイトを調査しにきたこと(クローリングと言います)を確認することができます。

Webページ情報を集めて分析する際に必要になるのがHTMLです。HTMLの中身を見てWebページのキーワードや特徴を抽出します。しかしSPAではURLからWebページにアクセスしても、中身のほとんどないHTMLがレスポンスとして返ってきます。それもそのはずで、中身はJavaScriptがレンダリングするためです。

ここで気になるのが、「クローラーはJavaScriptを実行できるか」ということです。実はクローラーは、JavaScriptを全て実行してから分析することを保証していません。

ここでSSRの出番です。SSRではサーバー側でJavaScriptのコードを実行してHTMLを編集して、レンダリング済みのコンテンツをブラウザに送るということをしています。そのため、中身がレンダリングされたHTMLをクローラーに読み込ませることができるので、きちんと分析してもらうことができます。

初期表示の速度

SSRを行うことで、初期データを埋め込んだHTMLをブラウザに送信しているので、ページ内容を表示するためにJavaScriptの実行を待つ必要がないようになっています。

このようにして初期の表示速度を改善することができます。

SSRのデメリット

SSRもやはりメリットだけではありません。デメリットが存在します。

中でも特に気になるのが、サーバー側でSSRのプログラムを常に起動しておかなければならない点でしょう。

SPAのみの場合はただ単にJavaScriptのファイル、つまりJavaScriptのルールに乗っ取った文字が並んでいるだけの、テキストファイルを返せば設計が行えました。しかし、SSRではそのJavaScriptファイルを実行して、結果を返す事まで求められます。

従来のWebアプリケーションと比較した場合はどうでしょうか、

例えばPHPの場合はPHPファイルを実行して、その結果を返すということを行っており、この点では処理の大枠は似ていますが、実はSSRの方が多くのリソースを使用します。ライブラリやフレームワークにもよりますが、SSRではHTMLを組み上げる際に仮想的なタグ(仮想DOMと呼ばれます)をツリー状に組み上げ、更新を繰り返すといった処理を行っています。そのため従来のWebアプリケーションと比較してもSSRはリソースを使用するという問題点があります。