next.js のレンダリングの仕組みを公式Docを元に理解してみた

こんにちは。
今回は、
next.jsのサーバーサイドレンダリング(SSR)と
ページ遷移時のレンダリング速度
について理解した範囲で
書いていければと思います。

何故SSRの方がレンダリング速度がはやいのか？

サーバーサイドレンダリング(SSR)とは、
初回ページロード時や、ページのリフレッシュ時に、

つまり、０から情報を構築する必要がある際に、
サーバー側でレンダリングしようというものでした。

では何故、
サーバー側でレンダリングする必要があるかというと、
以下が考えられます。

初期HTMLの即時提供:
- SSRを使用すると、サーバーは完全にレンダリングされたHTMLをクライアントに直接送信します。これにより、ブラウザはページの内容をすぐに表示できるようになります。一方、クライアントサイドレンダリング（CSR）では、ブラウザがJavaScriptをダウンロード、解析、実行する必要があり、その後で初めてコンテンツがレンダリングされます。
サーバーのリソースの利用:
- サーバーは通常、高性能なCPUやメモリを持っており、クライアント（特にモバイルデバイス）よりも高速にレンダリングを行うことができます。これにより、サーバーでのレンダリングはクライアントでのレンダリングよりも迅速に行われることが多いです。

しかし、
homeページ(“/”)から、aboutページ(“/about”)などにlinkタグで遷移するとき、
ここからは、非同期処理によって、
必要なcomponentのみをとってくる作業に変わります。

例えば、
homeからaboutにページ遷移する際、共通のコンポーネントやlayout.tsxがかぶっている場合、
それらの部分は再度取得されることはありません。

例を挙げると、
homeページではcomponent1と2と3で構成されていましたが、
新しいページ先では、component1と4と5で構成される場合、
component１はhomeページの読み込み時にブラウザにキャッシュされるので、
component4と5のみを読み込む必要だけがあります。

つまり、
全てのページのcomponentが読み込まれたとき、
全ての情報がcashされているので、
各ページの遷移が最速になると思われます。

以下、簡単にまとめます。

初回ページロード時: ユーザーがアプリケーションに初めてアクセスする際、必要なページのコンポーネントと共通のコンポーネント（例: layout.tsxや共有ライブラリ）がロードされます。
クライアントサイドナビゲーション: 一度ロードされたコンポーネントはブラウザにキャッシュされるため、他のページに遷移する際には、新しく取得する必要があるのはそのページ固有のコンポーネントやデータのみとなります。
高速なページ遷移: すでにロードされている共通のコンポーネントやライブラリを再度取得することなく、ページ間の遷移が行われるため、遷移が非常に高速になります。

他にも、
Next.jsでは、ページのデータ取得方法を指定するための関数が提供されていたりするので、
以上に限った話では無いとは思いますが、
参考にしていただけたら幸いです。