📘

Next を触る当たってSSR SSG ISRなどを知る

2024/02/21に公開

はじめに

4月で社会人２年目になりもうちょっとフロントエンドとバックエンドの両方の知識を増やしたいと思い、趣味で書いていたReactのフレームワークであるNextを使ってみることにしました。
Nextはサーバー側でのレンダリングが可能でそのレンダリング方法には

の３つがあることを知りました。

クライアントサイドのレンダリング方法

では、Nextの前ではどうやってレンダリングしてたの？ってなりますよね。
その方法としては、クライアント側でレンダリングするCSRという方法や単一のページを使うSPAが主に使われていました。<- 自分はこういう認識です。

SPA

SPAはSingle Page Application の略称で
最初に説明した通り単一ページでWebアプリを構成しており、ページ遷移を行わずに画面が切りわかります。
従来では、操作のたびに全体のHTMLを読み込んでいたのですが、SPAでは、一部分だけを更新し、書き換えることで、サーバーとの通信量を減らすことができます。
しかし、最初の初期ロードの時間がJS（TS)のコードが増えたことで長くなってしまうデメリットがあるそうです。
現在では、上記の点は初期ロードはSSRを用いることで高速化はできるそうです。

CSR

CSRはクライアントサイドレンダリングの略になります。
クライアントのリクエストに対してからのHTMLとJSを返し、クライアント側でJSを実行しレンダリング、及びデータ取得を行いっています。
Reactのみを使ってSPAを作る場合にuseEffectの中でデータのフェッチして結果をuseStateに渡して表示するなどいうやり方がCSRに当たります。　<- 今まで知らずに使っていました。
クライアントだけで完結して実装や運用もシンプルだしすごいいいい！！！って思っていましたが、CSRにも欠点があります。
それは、クライアントのリクエストに対してからのHTML返すために、SEOとOGPに対応できない点があります。
この欠点を解決するのがSSRになります

サーバサイドのレンダリング方法

SSR (サーバーサイドレンダリング)

クライアントのリクエストに対してサーバ側でデータを取得してHTMLを生成しそれを返します。
サーバ側でHTMLを生成しているのでSEOとOGPに対応可能で、初期表示も早いです。

デメリットとしては、サーバー側での負荷を増加してしまいます。

SSG (静的サイト生成)

SSRの問題点としては、ユーザーのリクエストを受けてからHTMLを生成しているので、時間がかかってしまう点が挙げられます。

ビルド時にサーバー側でデータを取得してHTMLを生成しリクエストに対してそれを返します。
事前にHTMLを生成しているため、CDNにキャッシュもできるのでSSRをパフォーマンスに優れています。

デメリットとしては、ページ量が多いウェブサイトには適さないことや更新頻度の高いサイトには適していない点などがあります。

ISR(定期的な静的再生成)

SSGのデメリットでもある、更新頻度の高いサイトの解決策としてISRという定期的にページ更新をする。

ISRではビルド時にサーバー側でデータを取得してHTMLを生成した上で、revalidateで指定した時間経過後にデータを再取得してHTMLを再生成しています。

最後に

いろいろな人は文献を上げてくださっているので、調べたらいろいろな記事が出てきたので、実際に自分もNextを書く際にこのレンダリングの方法の特色に合わせて使い方を意識していきたいと思いました。