Nuxt.jsでWebサービスのフロントエンドを書く上でSSRに関することを調べたのでまとめた.

SPA

シングルページアプリケーション(SPA)は, 単一ページによるWebアプリケーションのことで, 画面遷移によるページ全体のリロードが発生しない.
レンダリングはクライアントサイドが担うため,

初回ロード時間が長い
全ページをレンダリングしてから表示するため, 初回ロード時間が長くなる.
SEO的な観点から見ると良くない
空白のページがサーバから返された後にJavaScriptが実行され, コンテンツがレンダリングされる.
そのため, JavaScriptを解釈できないクローラの場合(今時あるのだろうか？), コンテンツの無いWebページだと認識されることがある.

といった問題点がある.

SSR

SPAの問題を解決すべく, サーバサイドレンダリング(SSR)が登場した.
SSRはクライアントサイドでレンダリングしていたものをサーバサイドでレンダリングすることによってSPAの問題に対処した.

また, SSRと似たような概念として,

アイソモーフィックJavaScript
アイソモーフィックは英語でIsomophicと記述し, 「同型」といった意味を持つ.
クライアントサイドとサーバサイドを同じ言語(JS)で記述することで, コードの共有を可能する試み.
ユニバーサルJavaScript
ユニバーサルは英語でUniversalと記述し, 「一般的な」「普遍的な」といった意味を持つ.
クライアントサイドやサーバサイドだけでなく, モバイル端末や組み込みデバイス上まで考え方を広げたもの.

といったものも存在する.

Nuxt.jsでは, 上に挙げたSPAとSSRの他, 静的化(Static Site)といったビルド方式を選択できる.
以下にそれぞれのビルド方式のメリット・デメリットをまとめた.

SPA
３つの中では一番実装しやすくサーバの準備が楽(GitHub PagesやNetlifyで動作するため).
ただし前述したSPAの問題点は残る.
SSR
SPAの問題点は解消できるが, 実装が面倒でサーバの準備が面倒(Heroku, Now等, Node.jsが動作するサーバを用意する必要があるため).
静的化
静的化は各ルートのHTMLを事前にレンダリングして生成する方式で, 生成時にはSSRの仕組みを利用するため, SSRを考慮した実装が必要.
SPAの欠点の解消ができ, サーバの準備も楽(GitHub PagesやNetlifyで動作するため)でSSRよりも速い.
ただし, 利用用途が限られる(更新が少ないサイト・ドキュメント・ブログ向き).