SSR、SSG、ClientSideRenderingの違いについて言語化。Next.jsチュートリアルの説明が個人的に一番わかりやすい。Pre-rendering and Data Fetching

Client Side Rendering

「Client Side Rendering = SPA」の文脈で使われることが多い気がする。

ブラウザ上でJavaScriptを実行してDOMを生成、マウントし、コンテンツを表示させる。SPAアプリの場合、以下のような中身が空のHTMLファイルを使うことが多い。

index.html

<html>
<head>
<title>sample</title>
</head>
<body>
<div id="app"></div>
<script src="/js/bundle.js"></script>
</body>
</html>

上記のHTMLファイルはルートディレクトリ直下に置くのが普通なため、/以外にリクエストが送られると404となる。開発時はwebpack-dev-serverがよしなに面倒を見てくれるが、ホスティング先ではそうではないので、初めてSPAでアプリを作ってホスティングしたときに戸惑うやつ。

なので、どのルートにリクエストが送信されても、上記のHTMLファイルがダウンロードされるように設定が必要。

「Vue.jsやReactを使っている = SPA」ではない。LaravelやRailsなどのテンプレートファイルにVueやReactコンポーネントを埋め込んで使う例もある。

JSファイルが実行、評価されてDOMがマウントされるまでコンテンツが何も表示されない
JSファイルのサイズが大きくなると、ファイルダウンロードの時間が無視できないレベルになる
SEOで不利（クローラーがJavaScriptを実行できるようになったとのことなので、この問題は解決されつつある。ただ、即時的に評価されるのではなく、評価までにラグがあるらしい）
TwitterやFacebookのクローラーはJavaScriptを実行しないため、プレーンなSPAアプリだと動的なOGP対応ができない

SSR

「Server Side Rendering」の略。Vue.jsやReactコンポーネントをサーバー側で評価、実行し、その結果を配信する。

オリジンサーバーにリクエストがあるたびに上記の処理を行い、HTMLファイルを生成する。そのため、サーバーの負荷は他の2つより高くなる傾向があり、TTFB（Time To First Byte）の時間も長くなる。

JSファイルを配信しないというわけではない。インタラクティブな表現のためのJSファイルは必要。

Nuxt.jsやNext.jsを使って実装するのが楽。

「Static Site Generator」の略。「SSRする」は意味が通じるが、「SSGする」は元の言葉の意味を考えるとおかしい気がする。

アプリのビルド時にあらかじめページ表示に必要なデータを取得し、各ページごとに静的なHTMLファイルを出力しておく。そしてサーバーへのリクエスト時にはこのHTMLファイルを返却する。

たとえばヘルプページなんかはユーザーごとに表示するコンテンツが変わるわけではない。それなら最初から静的なファイルとして用意しておけばよくね？的な発想。

ブラウザが静的なHTMLファイルを取得するのはサイトへの初回リクエスト時のみで、ページ遷移時には代わりにJSONファイルを取得し、動的に変化する部分はこのJSONファイル内のデータを使ってレンダリングする。

上記はイメージがつきにくいが、実際に自分で試してみるとわかりやすい。

Nuxt.js、Next.js、Gatsby.jsなどが対応。Next.jsではSSRとSSGを混在させることもできる。

要件的にSSGを選択できるなら、そちらのほうが良さそう。SSRとSSGのメリットはよく似ているが、メンテナンス性などを考えると基本的にSSGのほうが楽になるはず。というより、SSRは消極的に選択される手法な気がする。。。