Next.jsでは、以下の3つのレンダリングを使用する
- CSR（クライアントサイドレンダリング）
- SSR（サーバーサイドレンダリング）
- SG（静的サイト生成）
CSR - クライアントサイドレンダリング
Client Side Renderingの略。
データフェッチやルーティングのすべてがクライアント上で行われる。
サーバーではなく、クライアント側にコードが全て配信されてからブラウザでコードが実行されて画面が生成される。
※Next.jsの開発ではクライアント側でのみ行いたい処理はuseEffectで囲む。
仕組みの流れ
①クライアントからHTTPリクエストがサーバーに飛ぶ
②リクエストの応じてレンダリング前のTHMLをクライアントに返却
③返ってきたHTMLとjavascriptのコードをもとに画面を構築
④画面構築中に追加の情報が必要であれば、クライアントからAPIサーバーにデータをリクエストを飛ばす
⑤戻り値としてJSONデータが返ってくる
⑥受け取ったデータから画面を構築
メリット
- 静的なファイルの配置の身で動く
- サーバー側の負荷が軽い
デメリット
- 初期描画に時間がかかる（ブラウザ側ですべてのコードから画面を構築するため）
- クローラーによってはSEO的な問題あり
クローラーについて
クローラーは、タイトルやメタタグからそのサイトの説明文を作ったりするもの。
検索結果の説明とかに載せるやつを勝手に作ってくれるやつのこと。
Googleは問題ないが、SNS系のクローラーはjavascriptの実行ができないものがあり、うまくタイトルなどを読み込んでくれない場合がある
SSR - サーバーサイドレンダリング
Sever Side Renderingの略。
サーバーにリクエストが着たタイミングで動的にHTMLを生成。
外部APIへのデータの取得やコンポーネントのpropsの値を決定する処理を行い、HTMLを作成してクライアント側に返却する。
仕組みの流れ
①クライアントからHTTPリクエストをサーバーに飛ばす
②サーバーからAPIサーバーにデータを問い合わせ
③必要なデータがJSONファイルなどでサーバー側に返却される
④サーバー側でHTMLを生成
⑤生成されたHTMLがクライアントに返却
メリット
- 生成済みのHTMLを取得するのでSEOに強い
デメリット
- 生成処理をすべてサーバー側でするので負担が大きい
- HTMLをクライアントに渡すまで時間がかかる
SG - 静的サイト生成
Static Generationの略。
ビルド時にデータフェッチやpropsの値の決定を行い、HTMLを構築する。
クライアントからリクエストされたら、サーバー側で構築することなく、生成済みHTMLを渡す。
仕組みの流れ
①ビルド時にビルド用のコマンドをたたいてHTMLを生成
②生成時にデータが必要な場合はAPIサーバーにリクエストを送信
③返ってきた情報をもとにHTMLを生成
④出来上がったHTMLをサーバーに配置
⑤クライアントからリクエストされたパスに応じて生成済みHTMLを返す
メリット
- 構築済みのため表示速度が高い
- SEO問題なし
デメリット
- 更新頻度が高い動的な処理には向かない
基本構成
基本的にはSG。
動的に作成する必要があるページはSSR。
近年ではSSRを使うことが多い。キャッシュをうまく使えば効率よくできるから。