【Web開発入門】SSR・SSG・CSR？レンダリングの違いとSPA・MPAを寿司屋に例えて解説！

こんにちは、Wakka Inc. Webディレクターの安藤です。

ここのところ、Next.jsやNuxt.jsを使ったモダンなweb開発に取り組む事例が増えてきました。
そこで毎回、レンダリング方式の違いをお客さんにもどう説明したものか、と頭を悩ませていました。

レンダリングとは、《プログラムがデータを処理・演算することで、画像やテキストを画面に映し出すこと》です。
webシステムにおいては、方式が色々とあり、昔に比べると複雑化していると感じます。

というのも、従来のwebシステムでは基本的にレンダリングをするのはサーバーであることが多かったのですが、最近のモダンなwebサイトでは、ブラウザが行うケースもあります。
また、同じサイト内でもページによって柔軟に方式を変えることができるようになりました。

そのため、選択の幅が広がった分、違いを理解して、エンジニアとよくすり合わせなければいけません。
僕自身もエンジニアではないので、何かに置き換えて理解を深めようと試行錯誤していたのですが、《寿司屋》に例えるとわかりやすいんじゃないか、と思いつきました。

どういう事か、早速見ていきましょう。

従来のWordPressサイトは『寿司職人のワンオペ』？ MPAとSSRの仕組み

まず、従来のwebサイトの一例として、一般的なWordPressサイトの特徴をおさらいします。

• 複数のwebページによって成り立ち、ページ遷移が発生するwebサイト。
• webページがリクエストされる度に、webサーバーがデータベースからコンテンツを取ってきて、webページを生成して、クライアントに提供する。

これを、お寿司に例えてみましょう。

• 複数のネタが食べられる、握り寿司のコースメニュー。
• お客さんの注文を受けて、寿司職人が厨房でネタとシャリを取ってきて、調理して、お寿司としてお客さんに提供する。

「お寿司を食べたい」と思ったら、複数のネタの握り寿司（軍艦や手巻き寿司を含む）を食べる事を想定するのが普通でしょうし、お寿司屋さんに行ってお寿司が提供されるのは当たり前ですね。

このように《複数のwebページによって成り立ち、ページ遷移が発生するwebサイトやアプリケーション》を《Multi Page Application》（MPA）と呼びます。

常に新鮮な状態を提供できるのがSSR

《webサーバーが完全なwebページを作って提供すること》を、《Server Side Rendering》（SSR）と呼びます。
お店で作られた出来立てのお寿司を提供してもらえるように、サーバーから常に最新のページを提供してもらえるのがSSRのメリットです。

このようにWordPressをはじめとした従来のwebサイトは、《MPA》で《SSR》であることが一般的でした。

従来のWordPressサイトの課題：サーバー負荷とセキュリティリスク

しかし、いくつか大きな課題がありました。

1. 一般的なWordPressの場合、管理画面も表示部分も同じwebサーバー上で動作しているので、攻撃されたら全部に影響が出る。
2. リクエストの度にwebページを生成するので、webサーバーの負荷が高い。

お寿司に例えると、《寿司職人がワンオペで回している》状態なのです。

お店に全てのリソースがあるので、強盗に襲われたら大変です。
何かの拍子でバズったらお店がパンクして、お寿司が提供されるまでに時間はかかるし、寿司職人もお店を回せなくなります。
これはいけません。
モダンなweb開発で使われる手法は、その解決策として生み出されたわけです。

「管理画面と表示が一体化している」という欠点に対する解決策としては、「管理画面だけを持ち、表示は別途構築する」というヘッドレスCMSがあります。
では、もう一つの課題、webサーバーの負担を軽減し速くwebページを提供してもらうには、どのような手法があるでしょうか。

一つの器にネタを盛り込む！SPAはいわば〝海鮮丼〟

まずは、従来のwebサイトにおける《複数のwebページによって成り立ち、ページ遷移が発生するwebサイト＝MPA》に対応する概念が挙げられます。
つまり、《単一のwebページによって成り立ち、ページ遷移しているように見せかけるwebサイト》です。 これが《Single Page Application》（SPA）です。
クライアントからすれば得られる結果は同じではあるものの、webページ一つで完結するので、負担を軽減できます。
そういう意味では、従来のペライチのランディングページも、一種のSPAと言えるかもしれませんね。

お寿司に例えるなら、一品で一つのネタを味わう《握り寿司》に対して、一品で複数の味を楽しめる《海鮮丼》などが近いのかなと思います。

さて、次はいよいよ本題、様々なレンダリング方式です。

〝作り置きテイクアウト〟で負担を軽減できるSSG

「リクエストの度にwebサーバーがwebページを作って提供するのが負担なら、事前にwebページを生成しておけばいい」というアプローチが、《Static Site Generation》（SSG）す。
お寿司に例えるなら、《作り置きのテイクアウト》といったところでしょうか。

これなら、”注文の度に作る”という一連の作業が省略され、”事前に作り置きしてあるものを言われたまま提供するだけ”なので負担が軽減でき、素早く提供できます。
ただし、デメリットとしては、以下のような事が挙げられます。

• 動的な動きが苦手。
  →作り置きなので、個別の細かな振る舞いが難しい。
• webページの状態が常にリアルタイムではない。
  →作り置きなので、鮮度が落ちる。
• webページが多いと、再構築に時間がかかる。
  →作り置きの量が多いと、作業が終わるまでに時間がかかる。

上記の特徴から、リアルタイム性が優先される更新頻度の高いサイト、特にメディアサイトには向きません。
一度公開したら頻繁に更新することがない、コーポレートサイトの読み物ページなどに向いています。

お客さんが自分で器に盛り付ける〝寿司バイキング〟なCSR

PCやブラウザの性能が向上したことで、「クライアント（自分）でwebページの生成をすればサーバー負荷が軽くなるのでは？」というアプローチが《Client Side Rendering》（CSR）です。
この場合、クライアントがwebページをリクエストすると、webサーバーはコンテンツがほぼ空の状態で、webページを構成する素材（html、css、javascript）を提供します。
クライアントは直接CMSなどにコンテンツを取りに行き、素材と組み合わせてwebページとして完成させ、画面に表示します。

《CSR》をお寿司に例えるなら、《セルフサービスの寿司バイキング》といったところでしょうか。

受付をすると、お盆と酢飯が渡されて、食べたいネタは自分で取りに行って盛り付けるという方式です。
先述の《Single Page Application＝SPA》は、この《CSR》を採用している場合がほとんどです。
そのため、ほぼ同一の概念として扱われがちですが、先に述べた通り”MPAに対するSPA”であり、正確に言えば少し違う視点の話です。

どうして《CSR》と《SPA》がほぼ同一に扱われ、逆に《CSR》の《MPA》はないのか疑問に思いませんか？
僕自身、《CSR》と《SPA》を混同していて、ややこしいなと思っていたのですが、お寿司に例えると割とスッキリしました。

要は「寿司職人でもないのに、何個も食べたい《握り寿司》を全て自分で手作りするのは大変」という事です。

それだけ自分の手間が増え、全てのお寿司を完成させ、食べるまでの時間がかかりすぎます。
早くお寿司を食べたい、得られる結果が同じでよければ、何も《握り寿司》ではなく、最初から一品で複数の味が楽しめる《海鮮丼》を作ったほうがラクですよね。

では、お寿司の例えからwebに戻ってみましょう。
もし、複数のwebページで成り立つwebサイトをそのまま手元のPCにダウンロードして表示しようものなら、重たすぎるし、表示までに時間がかかりすぎます。
また、手元のPCには様々なアプリケーションがインストールされており、web用途に特化したものではない訳ですから、なるべく負担は軽いほうがいいですね。
だから現実的に考えて《SPA》になる、と解釈しています。

《CSR》と《SPA》の組み合わせの特徴は、

• 一度ダウンロードすれば、ページ遷移は速い（というより、ページ遷移しているように見せかけている）
• 単一のwebページで成り立つwebアプリケーションなので、画面遷移がシームレスで、且つ動きをつけやすい。

ということが挙げられます。
しかし、デメリットもあります。

• ダウンロードが終わるまでは何も表示されない。
• クライアントで動作するので、クライアントのリソース（CPUやメモリ等）に負荷がかかる。
• クライアントのスペックに依存するので、スペックの低いクライアントでは正常に動作しない可能性がある。
• 複数のwebページが実体として存在しないため、SEOに弱い。
• 複数のwebページが実体として存在しないため、下層ページの直リンクができない。
• 実体は単一のwebページなので、設定できるOGP（Open Graph）は一つ。
  Javascriptで書き換えたとしても、SNSのクローラーでは解釈ができないので、シェアしてもサムネイル画像やタイトルは1パターンしか表示できない。

また、デフォルトではクライアントが直接コンテンツを呼び出しにいくので、《セキュリティの観点からCMSを閉じた環境に設置する場合、別途処置などが必要になる》という点も、注意が必要です。

よって、SEOを重視する通常のwebサイトにおいてはそのままCSRを選択することはあまりなく、他のレンダリング方式と組み合わせることが多くなると思います。

CSRの場合、SNSでシェアすることはなく、SEOを重視しないコンテンツであったり、ログインを求めるようなプライベートなコンテンツを提供するwebサイト、webアプリケーションに向いています。

Next.js/Nuxt.jsの意外な挙動｜ページ遷移後はCSRになる理由

ということで、ここまではよく目にするレンダリングの違いの説明ですが、これらはあくまで〝初回アクセス、またはリロードした時の話〟です。
Next.jsやNuxt.jsを用いてSSR又はSSGで構築しても、実はページ遷移などの次のアクションを実行するとCSRの振る舞いをします。
え、って思いませんか。（実は僕は思いました）

通常のSSRでは、全てリクエストに対して毎回ページを生成するためwebサーバーに負荷が高くなるという課題がありましたね。
Next.jsやNuxt.jsを用いてSSR又はSSGで構築すると、最初はwebサーバーがページを生成して提供してくれますが、ページ遷移などをした場合、その差分をクライアントが直接コンテンツを呼び出して生成するという振る舞いをするのです。
「SSRなのにCSRなんかい！」って最初気付いた時は思いました。

ですが、よくよく考えてみると、Next.jsのベースであるReact.jsにしろ、Nuxt.jsのベースであるVue.jsにしろ、元々がCSRを出発点とするフレームワークですし、ページ遷移後もSSR又はSSGの振る舞いをし続けるのであれば、それは結局、従来のwebサイトと同じであり、webサーバーの負担を軽減することになりづらいのだと思います。

誰でも厨房に入っていいわけではない！CSRのセキュリティリスク

ということで、結局ページ遷移後などにCSR的な振る舞いをするため、先に述べた通り、セキュリティの観点から別途対策が必要になります。
セルフサービスの寿司バイキングだからといって、無秩序に人が厨房に入っていいわけはないし、提供しているネタを勝手に並べ替えられたり、一人のお客さんに使い切られたらお店は混乱しますよね。

例えばこういった対策が必要です。

• リクエストを制限する
  →入場を制限して、厨房の混雑を緩和する
• サーバーサイドプロキシを利用し、サーバ側にAPIを仲介させる
  →厨房の前に窓口を設け、お客さんが直接厨房に入らないようにする

リクエスト制限は、ホスティングサービスやCMSサービスで備わっていることもあるので、開発で対応する場合には後者のほうが多いでしょう。

まとめ

というわけで、お寿司に例えて、モダンなweb開発の手法の違いを解説してみました。
まとめるとこんな感じです。

MPA

複数のwebページによって成り立つwebサイト、アプリケーション。
お寿司に例えると、「複数の握り寿司のコースメニュー」。

SPA

単一のwebページによって成り立つwebサイト、アプリケーション。
お寿司に例えると、「一品で複数の味が楽しめる海鮮丼」。

SSR

特徴
クライアントのリクエストを受けて、webサーバーがwebページを生成して提供する。
お寿司に例えると、「お客さんの注文を受けて、寿司職人がお寿司を提供する」

メリット
個々のリクエストに応じて、常に最新の状態を提供できる。

デメリット
webサーバーの負荷が高くなりがち。

SSG

特徴
事前にwebサーバーがwebページを生成しておき、クライアントのリクエストに応じて生成済のwebページを提供する。
お寿司に例えると「作り置きのテイクアウト」。

メリット
webサーバーの負荷が低く、提供が速い。

デメリット
リアルタイム性に欠け、個々の細かな調整が難しい。

CSR

特徴
クライアントのリクエストを受けたら、webサーバーは最低限の素材を提供し、クライアントが自分でコンテンツを取得してwebページを生成する。
お寿司に例えると「セルフサービスの寿司バイキング」。

メリット
一度ダウンロードが完了すれば速い。
カスタマイズ性に優れ、リッチなUI操作を実装しやすい。
ログインが必要なパーソナルなwebサイト、アプリケーションに向いている。

デメリット
自分で生成するので、時間がかかる。
SEO、OpenGraphに弱く、一般的なwebサイトには向かない。
クライアントから直接コンテンツを取得する振る舞いをするので、仲介をさせるなどの処置が必要になることも。

いかがでしたでしょうか。

従来のwebサイトでは、あまり意識することがなかった部分ですが、モダンなweb開発においては、サイトごとやページごとに適切なレンダリング方式を選定することが重要です。
最近のwebトレンドでは、SSR回帰の風潮も散見され、何が最適解かはケース・バイ・ケースだと改めて考えさせられます。

メリットとデメリットをお客さまにも理解いただいたうえで、最適なwebサイトを構築していきたいものですね。