Next.jsのSSG・SSR・CSRについてRailsと比較しながら調べた

# 0. はじめに

使ったことはないが気になったので調べてまとめた。

# 1. RailsとNext.jsの比較

|| Rails | Next.js |
|:-:|:-:|:-:|
|雛形作成 | `rails new`  |  `create-next-app` |
|ルーティング| routes.rb  |  File-system Routing |
| クライアントサイドルーティング| turbolinks | next/link |
| Static Site Generation| ○<br>（ActiveRecordが不要なのでRailsを使う必要はない。） | ◎ |
| Server Side Rendering| ◎<br>(Server Side Templatingとも呼ばれる。) | ○ |
| Client Side Rendering |△<br>(フレームワークのような規約がないJavaScriptでAjaxを実行する必要がある。)| ○<br>(File-system RoutingやSEO/OGPの最適化が不要になるため、Reactを使った方が良さそう。) |
| Incremental Static Regeneration | × | ○ |

あまり自信なし。

# 2. Next.jsの機能

## Zero Config

WebpackやTypeScriptの設定が基本的に不要。

## File-system Routing

ページのルーティングはファイル名によって決まる。

## Image Optimization / Font Optimization / Script Optimization

[Core Web Vitals](https://web.dev/learn-web-vitals/)に沿うパフォーマンスの最適化をフレームワークとして提供している。

## Pre-Render(Hybrid: SSG and SSR)

- SSGやSSRによるプリレンダリングなど、様々な方法でデータの取得とコンテンツのレンダリングが可能。

### SSG(Static Site Generation)

- HTMLをビルド時に生成し、それをCDNでキャッシュすることでリクエストごとにHTMLを再利用する方法。
- Next.jsの公式ドキュメントでは、パフォーマンスの観点から、可能な限りSSGを利用することが推奨されている。

> We recommend using Static Generation (with and without data) whenever possible because your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request.
https://nextjs.org/docs/basic-features/pages#when-should-i-use-static-generation

- ブログやメディア系のサイトなど、**静的**にビルドできる(DBやAPIからデータを取ってこなくて良い)ケースで適する。
- デプロイ時に全ファイルを更新しないといけないため、コンテンツ量に比例してビルド時間が増える。

### SSR(Server Side Rendering)

- HTMLをリクエストごとに生成する方法。
- 動的にデータが変わる商品ページなどのケースで適する。
- サーバーサイドフレームワークからテンプレートエンジンを返す方法を、SSRの一種としてSST(Server Side Templating)とも呼ぶ。
    - SSTのフレームワークの一例:
        - ExpressとPug
        - RailsとERB
        - LaravelとBlade
- SSRを行うためにはSSR用のサーバを建てる必要がある。
    - Vercelを使うとSSRを行う場合でもサーバーサイド用のホスティングを別途用意する必要はない。
- 静的にコンテンツが決められる場合はSSGの方がパフォーマンスが良く、頻繁にコンテンツが更新される等の理由でプリレンダリングが必要ないケースではCSRを利用するべき。

### CSR(Client Side Rendering)

- 最初にほぼ空のHTMLを読みこみ、JavaScriptからDOMを生成する方法。
- すべてのロジック、データフェッチ、テンプレーティングやルーティングがクライアントで行われる。
- SEOが関係なく、データが頻繁に更新され、また、事前に静的にページをレンダリング（プリレンダリング）しておく必要もないSPA(Sing Page Application)のようなケースで適する。
    - CSRが適しているページの一例:
        - ユーザーのダッシュボードページ
        - Gmailのようなアプリケーション
        - 管理画面
- デメリットは、コンテンツを取得するために何度もリクエストを繰り返す必要があるため初期描画のパフォーマンスが悪いことと、JavaScriptを実行できないSEOやOGPなどのクライアントに適さないこと。

### ISR(Incremental Static Regeneration)

基本的にはSSGで静的コンテンツを作りつつ、コンテンツがない場合はオンデマンドでファイルを生成したり、生成したファイルの生存期間を超えるとサーバー側で再生成してくれる、SSR+ファイルキャッシュのようなもの。
※ あとで調べる。

## 3. インフラ要件（ホスティング/CDN/Faas）の一例

- Vercel
    - 推奨。
- GitHub Pages
- Netlify（Netfliy Functions）
    - 無料プランでは日本のCDN拠点が含まれない。
- Firebase Hosting（+ CloudFunctions）
- Amazon S3（+ Amazon CloudFront（+ AWS lambda））
- AWS Amplify（+ lambda@edge）

[Next.jsのインフラ要件と選択肢](https://hackmd.io/@euxn23/r1zO5zzpw)


## 4. 参照

https://nextjs.org/

https://vercel.com/

https://hokaccha.hatenablog.com/entry/2021/10/23/135532

https://qiita.com/kimizuy/items/d33420330479f8c85449

https://qiita.com/thesugar/items/47ec3d243d00ddd0b4ed

https://shimablogs.com/spa-ssr-ssg-difference

https://qiita.com/ryokkkke/items/1bd858a5d6f261a9342a

https://qiita.com/jagaapple/items/faf125e28f8c2860269c

https://speakerdeck.com/takefumiyoshii/nextjs-make-the-web-faster

https://diary.ssig33.com/posts/462


https://www.suzu6.net/posts/268-blog-server/

https://techblog.yahoo.co.jp/entry/2020121530052952/

https://qiita.com/mikan3rd/items/3f46b1edcb79ad63deef

https://zenn.dev/hirof1990/scraps/7db8fe2cdff510