【Next.js】レンダリング手法を手書きで図解してみた(CSR / SSR / SSG / ISR)

おはこんばんちは、ちーずです。
本日のテーマは、Next.jsにおけるレンダリング手法に関してです！！

Next.jsでは、柔軟にレンダリング方法が切り替えることができますが、
一方でそれぞれの特性を理解して適切に使わないといけません。

その特性を理解するために記事にしました！

CSR(Client Side Rendering)

CSRは、名前の通りクライアントサイドでレンダリングする手法です。

ブラウザからリクエストがあった時に、

• ほぼ中身のないHTML
• 全ページの情報を持ったJavaScript、CSS

これらがサーバー側から返されます。
そして、クライアント側でデータの取得を行い、レンダリングします。

メリット

• 遷移がサクサクでよいユーザー体験が提供できる
• ホスティングが容易

デメリット

• 初期ロード時に他ページの処理も含めてレンダリング送、初期ローディングは時間がかかる
  • SEOサイトには向いていない

SSR （Server Side Rendering）

SSRも、名前の通りサーバーサイドでレンダリングする手法です。

SSRでは、ブラウザからリクエストがあった時に、サーバー側でAPIを叩き、レンダリングまでを行います。
レンダリングされたデータをブラウザ側に返します。
(通常のwebのレンダリングの仕組みに一番近いです。)

メリット

• コンテンツ表示までの時間が早く、SEOに有利

デメリット

• SSRを実行できる実行環境が必要
  • 開発環境のセッティングが容易ではない
• サーバーサイドの処理肥大化によって、重くなるケースもある
• サーバー側で実行されているか、クライアントで実行されているかちゃんと理解しないと、重複発火などが起きる

SSG (Static Site Generator)

SSGは「静的サイトジェネレーター」といい、静的なサイトを事前にビルドしておく仕込みのことを指します。
最近では、SG (Static Gneration)と言われています。

ビルド時にあらかじめデータを取得し、データを埋め込んだ状態でHTMLを生成します。
その静的なHTMLを、リクエストがあった時に返してあげるような仕組みになっています。

メリット

• 静的サイトを配信するため、パフォーマンスが良い
  • SEOにも一番有利！
• ホスティングが容易(静的なHTMLとJSファイルのみであるため)

デメリット

• ページが増えれば増えるほど、ビルドに時間がかかってしまう
• 更新に向いていない

ISR (Incremental Static Regeneration)

ISRは「インクリメンタル静的再生成」といい、SSGを決まった間隔で再度レンダリングしつづけるものです。
クチコミのような、頻繁に更新されるサイトに対して使われます。

メリット

• SSGのメリットはそのまま継承し、その上で更新が可能になった

デメリット

• vercel依存

参考