SSR vs SPA

それぞれのメリット・デメリットを見ておきましょう

SSR

SSR(Server Side Rendering)では、HTTPリクエストをもとに文字通りサーバ側で描画を行います。この方式には以下のようなメリット・デメリットがあります。

SPAの場合はページの描画完了までの速度は 利用者側の端末(例: スマートフォン・ラップトップ)の性能に大きく依存するが、SSRはサーバ内で完結するので制御できる（= 性能の高いサーバを用意すれば描画速度を改善できる余地がある）
SPAと比べてコンテンツの生成はサーバ側(限られた開発者しかアクセス出来ない環境)で行われるため、セキュリティの面で有利。(= 改ざんされづらい)

サーバ側で描画する = SPAと比べてサーバに負荷が掛かるので、アクセス数が多い場合にはそれなりの性能のサーバを用意する必要がある。実際にはCDNを用いたキャッシュを行うことで、サーバに負荷が掛からないように対処する事がある。(キャッシュをするとキャッシュの破棄の問題も出てくるので、そちらにも対応が必要)

SPA(Single Page Application)では、ブラウザ側でHTMLの初期描画を行ったうえで、AJAXを用いて後追いでデータを取得し、その内容を元にページのコンテンツの描画を行います。この方式には以下のようなメリット・デメリットがあります。

SSRと比べてブラウザ側での処理が多いため、サーバ側の負荷が軽く済む(言い換えるとクライアント側の負荷が重くなるデメリットでもある)。とはいえスマートフォン・ラップトップともに昔の端末と比べて性能が大きく向上しているため、問題になることは少ない。
サーバ側はAPIサーバとしてJSONを返却する事に専念できるので、実装がシンプルになる。またネイティブ(モバイル)アプリを開発する際にもAPIサーバは再利用できる。(SSRの場合は、別途APIサーバを作る必要が出てくる。)

初期のHTTPレスポンスには返却すべきHTMLコンテンツがまだ含まれてないため、一部のクローラ(例: Facebook・TwitterのOGP / Google)がコンテンツの解釈をうまく出来ない場合がある。その場合はSSRと一部併用する(= JAM Stackと呼ばれる構成)か、Pre-renderと呼ばれる事前描画の仕組みを利用して解決したりする。Googleのクローラに関してはある程度JavaScriptによるコンテンツの変更も解釈出来るようになってきているので、全く動かないという事はないものの。仕組みに関しては理解しておきましょう。
フロント(ブラウザ)側で描画する。という仕組みである以上、サーバ側(通常は開発者が関しできるリソース)と比べて信頼が置けない環境で実行されます。例えば悪意のある人がソースコードを差し替えて実行できる(例: バリデーションのコードをスキップできる)ので、クライアント側での妥当性(バリデーション)のチェックはセキュリティの観点では意味がない。ということを覚えておいてください。

プロジェクトの要件に合わせて適切な構成を選びましょう。不向きな構成(例: OGP対応が必要なサイトをSPAとして作る)をあえてやる場合は、適切な対処が必要なことを覚えておいてください。

ECサイトはSSRで作る = セキュリティの面で問題が出ないように対処しやすい
ネイティブアプリに似せた動き(アニメーション)の多いページはSPAで作る = SSRの場合よりも制御できる範囲が広い(例: ページ間のトランジションを実装できる)

最終更新 4 年前