CSR（Client Side Rendering）
クライアントサイド レンダリング（CSR）は JavaScriptを使用し、直接ブラウザでページをレンダリングすることを意味します。すべてのロジック、データフェッチ、テンプレーティングやルーティングは、サーバーではなくクライアント上で扱われます。
要するにブラウザでレンダリングする情報を取得したり、計算したりしてレンダリングする手法です。
ただし、実行する処理が複雑で多いほど処理による負荷が増えてしまいます。負荷が増えれば増えるほど、ユーザーに対してページを表示するまでの時間が長くなります。
また、利用者の持つ端末の性能によってページを表示するまでの時間の差が生まれやすくなります。
このようにCSRはアプリケーションの大きさに比例して、JavaScriptの量も増えて処理が重なることでページ表示が遅くなるのが主要な欠点でした。
そこで上記の問題を解決する手法としてサーバーサイドレンダリング（SSR）が台頭します。
SSR（Server Side Rendering）
CSRとは異なり、サーバーで処理を実行して生成したHTMLをクライアントに返却する手法です。
この手法ではブラウザで実行していた処理をサーバーで実行することにより、利用者の端末による差異を軽減することができます。また、JavaScriptをサーバーで事前に実行するので、大量のJavaScriptファイルをクライアントに送信する必要がなくなります。
ただし、サーバー上でページを生成するには時間を要するので、しばしばページがレンダリングされ始めるまでの時間が遅くなることがあります。
ちなみにSSRは全ページに採用しなければならない訳ではありません。一部の処理が多いページ等に対して、SSRを使用するのかを選択できます。このようにSSRとCSRの両方を使用する手法をハイブリッドレンダリングと呼称します。
SSG（Static Site Generation）
日本語では静的サイト生成と訳されるページのレンダリングに関連する手法の一つで、CSRやSSRとは異なり、ページを要求されるよりも前にHTMLを生成しておきます。
事前にHTMLが生成されているので、ページが要求される度にHTMLを生成する手間がなく、高速なレンダリングを提供します。また、アプリケーションサーバーから直接HTMLを返却するのではなく、CDNにキャッシュしておくことでさらに高速にページを表示させることができます。
ただし、SSGにも代表的な問題点が2つほどあります。
1つ目は__全てのページのHTMLファイルを事前に生成しなければならない__ということです。例えば、Qiitaでは記事が投稿されると記事ページが必要になりますが、記事が投稿されるよりも前にHTMLファイルを生成することは不可能な訳です。
2つ目は事前にHTMLを生成した時に情報を取得しているので、それ以降に__更新された情報を表示することができません。__正確にはブラウザでJavaScriptを用いて更新された情報を取得できます。しかし、ページアクセスの度に情報を取得する必要があるので、SSGのメリットである高速なレンダリングの一部を犠牲にしてしまうのです。
これらの問題について一部のフレームワークでは上記の問題を解決する手段を用意しています。例えば、ReactのフレームワークであるNext.jsではgetStaticPathsの__fallback__や__ISR(Incremental Static Regeneration)__、SWRという技術を提供しています。
※これらの手法については後日記事として投稿した後にリンクします。
参考サイト
Rendering on the Web - Web上のレンダリング | Google Developers
【Next.js】CSR,SSG,SSR,ISRがあやふやな人へざっくり解説する - Zenn
Next.jsにおけるSSG/SSR/ISR/CSRの違いと使い分け - Zenn