CSR（Client-side Rendering）
React は当初 CSR が主体だった。CSR はユーザーが Webサーバーから1つの HTMLファイル と1つの JSファイル（main.js）を受け取る。複数のJSファイルに分けることもできるけど、一般的には1つのJSファイル。
<script src="/path/to/main.js"></script> の main.js が <div id="root"></div> の id="root" を指定し div の中に React のコンポーネントとかを差し込むというのが CSR である。main.js は React のコードを webpack、Parcel、Vite などでバンドルしたときに作られる。
バンドル は複数のJSファイルやライブラリを依存関係も含めて１つのJSファイルに纏めること。一般的にバンドルする際は、minify や ツリーシェイキング、デッドコード削除という各種最適化も同時に行われる。
minify はコードを最小化すること（変数名1文字にしたりコメントアウトや空白を削除することで、JSファイルのサイズを小さくする）
ツリーシェイキング はモジュールの中の使われないものを削除する。
デッドコード は到達しないコード。
なぜ1つのJSファイルに纏めるのかは、複数のJSファイルがあって複数のリクエストがあるとパフォーマンス的に重くなってしまう。1つのJSファイルをロードする方がネットワーク的に良い。
CSR のみで構築されたアプリは、必要なリソースがすべてバンドルされたJSファイル（main.js）に含まれる。このファイルはルーティングの情報も持ってて（React 自体はルーティングの情報を持ってない。昔は CSR でアプリを構築するときは React Router が使われていた）、ページ遷移はクライアントサイドで解決される。そのため、ユーザーが新しいページに移動する度にサーバーから新しいHTMLファイルを取得する必要がない（Rails とか Laravel ならページ遷移の度に新しいHTMLを受け取るけど、main.js には全ての情報があってサーバーとか関係ない）
このように1つのHTMLファイルだけで動作するアプリは SPA（シングルページアプリケーション）と呼ばれる。React の初期は CSR に基づいて SPA を構築することを目指していた。CSR はレンダリングの性質、SPA はアプリケーションの性質。
SPA はFEとBEの分離を容易にし（Rails とか Laravel はサーバーサイドがテンプレートを持ってるため、FEとBEの分離が難しかった。React ならFEがルーティングの情報を持ってるため、BEはAPIを用意するのみ）、ページ遷移時のUXを向上させた（ページ遷移の度にリクエストは送らず、クライアント側でルーティングするためページ遷移もスムーズだった）
さらに CSR を基にしたライブラリやフレームワーク（React, Vue.js, Angular）は jQuery と比べて保守しやすいと評価され、大流行となった。
しかし、SPA には下記のような問題点も存在した。
初期ロード時間の問題
SPA はJavaScriptファイルのロード時間が長くなる傾向があるため、ユーザーが待たされる。アプリの規模が大きいと、この問題も顕著。
SEOの問題
検索エンジンのクローラーはJavaScriptのレンダリングに完全に対応しておらず、SEO に悪影響が生じる。
OGPの問題
OGP タグ解析用のクローラーもJSのレンダリングに対応しておらず、SNSなどでのリンク共有時にタイトルや画像が正確に表示されない。
こういった問題を解決するために SSR（Server Side Rendering）が導入された。クローリングの問題は直ったと Chrome は発表してるけど、SPA のようにソースを見ても <div id="root"></div> しかないより、最初からソースがある方が SEO は強いというデータもある。