SPA（クライアント描画 / CSR）— ブラウザで全部描く

📖 このページのゴール：ここから第2部「どこで描画するか」。最初の主役 SPA（エスピーエー＝シングルページアプリケーション）／CSR（シーエスアール＝クライアントサイドレンダリング） を、たとえ話でつかむ。「サーバーはほぼ空のHTMLとJSの束を返すだけ。画面はブラウザのJSが組み立てる」というしくみと、その得意・不得意を知る。 ← 目次・はじめにへもどる

🧭 ここから第2部：「何で作るか」から「どこで描くか」へ

第1部では、①UIを“何で”作るか（素のJS／React／Vue）を見てきました。第2部のテーマは②その画面を“どこで”描くかです。

同じReactで作ったアプリでも、「描く場所」を変えられます。 「ブラウザで描く」のがこの章の SPA（CSR）、「サーバーで描く」のが次章の SSR。作る道具（React/Vue）と、描く場所（CSR/SSR）は別の話——ここが最初のヤマです。

軸	選択肢	このページ
① 何で作る？	素のJS ／ React ／ Vue …	（第1部・済み）
② どこで描く？	ブラウザ（CSR＝SPA）／サーバー（SSR/SSG）	← いまここ

🍳 ひとことのたとえ

SPA は 「材料を送って、お客さんに自分で調理してもらう」お店です。

サーバーは、料理そのもの（完成した画面）を出さない。代わりに材料キット（JSの束）をドサッと送ります。
受け取ったお客さん＝ブラウザが、キッチン（あなたのPC・スマホ）で自分で組み立てて、画面を完成させます。
一度キットがそろえば、次の一皿はその場でサッと作れる（＝画面の切り替えがサクサク）。でも最初のひと皿は、材料が届いて調理し終わるまで待つ（＝初回が重い）。

🟢 キモは「完成品ではなく材料を送る」こと。だからお店（サーバー）は軽くてラク。代わりに、調理（画面づくり）の負担はお客さん側（ブラウザ）に乗る——この“役割の引っ越し”が、SPA の長所と短所をぜんぶ生みます。

📖 ことばをほどく：SPA と CSR

名前が2つ出てきますが、ほぼ同じものを別の角度から呼んでいるだけです。

ことば	読み／正式名	なにを指す？
SPA	エスピーエー／Single Page Application	ページは1枚だけ。中身をJSで書き換えて画面を切り替える“作りのスタイル”
CSR	シーエスアール／Client Side Rendering	描画（レンダリング＝画面を組み立てて表示すること）をブラウザ側でやる“描く場所”

SPA＝「ページを何枚も読み込み直さない（1枚で完結）」というアプリの形の話。
CSR＝「その画面をどこで描くか＝ブラウザで描く」という描画の場所の話。
実際にはセットで使われるので、本ガイドでは SPA（CSR） とまとめて呼びます。

🔧 厳密には「SPAだけどサーバーでも描く（SSR）」混ぜ技もありますが、入門ではまず SPA＝CSR＝ブラウザで全部描く、と覚えてOKです。

🧩 しくみ：どこで何が起きる？

ふつうの昔ながらのサイト（MPA＝マルチページアプリ）と並べると、違いが一目で分かります。

	🏛 昔ながら（MPA）	⚡ SPA（CSR）
サーバーが返すもの	完成したHTML（ページごと）	ほぼ空のHTML＋JSの束
画面を組み立てるのは	サーバー	ブラウザのJS
別ページへ移ると	毎回ページ全体をリロード	リロードせず、必要な所だけ部分更新
体感	ページごとに“パッと白くなって”切り替わる	アプリのようにヌルッと切り替わる

SPA がページを表示するまでの流れは、こんな順番です。

① ブラウザがアクセス
        ↓
② サーバーは「ほぼ空のHTML」＋「JSの束」を返す
        ↓
③ ブラウザがJSを “落として（ダウンロード）→ 実行”      ← ここが初回の待ち時間
        ↓
④ JSが画面の部品（DOM）を組み立てて、初めて中身が見える
        ↓
⑤ 以後の操作・ページ移動は、リロードせず “部分更新” でサクサク  ← ここが速い

🟢 ②の「ほぼ空のHTML」がポイント。最初に届くHTMLは、よく <div id="app"></div> のようなガランとした器だけ。そこへJSが中身を流し込んで初めて画面になります。だからJSが動かないと、ほぼ何も映りません（＝JS必須）。

👍 向いている / 👎 向かない

👍 得意（向いている）	👎 苦手（向かない）
操作がサクサク：一度読み込めば、以後の切り替えが速い	初回が重い：JSを落として実行し終わるまで“待ち”が出る
アプリ的なUI：入力・並べ替え・リアルタイム更新が多い画面	SEO（検索エンジン対策）に弱い：最初が空HTMLなので拾われにくい（※昔ほどではない）
サーバーが軽い：HTMLづくりをブラウザに任せられる	JS必須：JSが切れている・落ちると、ほぼ表示されない
管理画面・ダッシュボード・社内ツールにぴったり	端末性能に依存：古いスマホ等では“調理”が重くなりがち

🔧 「SEOに弱い、は昔ほどではない」 のは本当です。検索エンジンも今はJSをある程度実行して中身を読むようになりました。とはいえ確実に・速く読ませたい公開ページ（ブログ・EC等）では、次章の SSR/SSG が依然有利です。判断軸は「🔎 検索や初回の速さが命なら SSR/SSG、アプリ的な操作が中心なら SPA」。

🎯 こんな用途にハマる

“ログインした先の、操作中心の画面”は SPA の独壇場です。

🛠 管理画面（ダッシュボード）：数字やグラフを切り替え・絞り込みしながら見る
🏢 社内ツール：検索しても困らない（むしろ検索に出したくない）／操作のキビキビ感が大事
💬 アプリ的なWebサービス：チャット、エディタ、地図、かんばんボードなど

逆に、初めて来た人にパッと見せたい公開ページ（LP・ブログ・商品ページ）は、SPA だと“最初の真っ白”が不利。そこは第2部の後半（SSR・SSG）で回収します。

🛠 代表的なツール（実名）

ツール	ひとことで
React（リアクト）＋ Vite（ヴィート）	いま最も定番の組み合わせ。Vite＝高速なビルド／開発ツール
Vue（ビュー）＋ Vite	学びやすいVueでSPA。Viteとの相性も◎
Angular（アンギュラー）	フルセット型。大規模なSPAを“全部入り”で作る
Create React App（CRA）	かつてのReact定番スターター。今は非推奨で、新規は Vite が主流

🟢 これから始めるなら「React か Vue ＋ Vite」でOK。CRA（シー・アール・エー）という名前を昔の記事で見かけますが、今はViteに置き換わったと覚えておけば十分です。

🔒 SPA でも「鍵」はフロントに出さない（超重要）

ここは姉妹教材ぜんぶに共通する鉄則です。

SPA のJSはブラウザに丸ごと届きます。つまりソースは誰でも覗ける。
だから APIキー・パスワード・秘密のトークンを、フロントのコードに書いてはいけません。書いた瞬間、世界中に配っているのと同じです。

✋ やってはいけない：
   フロントのJSに  const API_KEY = "sk-xxxx..."  と直書き
   → ブラウザに届く＝誰でも盗める

✅ 正しい置き場所：
   鍵は “サーバー側” に置く。
   フロントは「サーバーの自前API」を呼ぶだけにして、
   サーバーが鍵を使って外部サービスへアクセスする

🟢 合言葉は「鍵はサーバーに、フロントは入口だけ」。なお次章の SSR / Server Components は、そもそもサーバー側で処理を実行できるので、秘密をサーバーに置いたまま扱えるのが大きな利点になります（SPA単体ではできない芸当）。

📝 ことばメモ

SPA（エスピーエー）：シングルページアプリケーション。1枚のページの中身をJSで書き換えて画面を切り替える作り。
CSR（シーエスアール）：クライアントサイドレンダリング。描画（画面づくり）をブラウザ側でやること。
レンダリング：画面を組み立てて表示すること。
MPA（エムピーエー）：マルチページアプリ。昔ながらの、ページごとにサーバーがHTMLを返す作り。
部分更新：ページ全体をリロードせず、必要な所だけ書き換えること。SPA がサクサクな理由。
Vite（ヴィート）：高速なビルド／開発ツール。いまのフロント開発の定番。
CRA（シー・アール・エー）：Create React App。かつてのReact定番スターターだが今は非推奨。

🟢 ひとことで言うと

SPA（CSR）は 「材料（JS）を送って、ブラウザに自分で調理させる」作り。サーバーはほぼ空のHTML＋JSの束だけ返し、画面はブラウザのJSが組み立てる。初回は重い・SEOに弱め・JS必須だけど、いったん動けば操作はサクサクで、管理画面・社内ツール・アプリ的なサービスにぴったり。React/Vue ＋ Vite が定番（昔の CRA は卒業）。そしてSPAでも鍵はフロントに出さない——これだけは絶対。

➡️ 次へ

次のページ：SSR（サーバー描画）とハイドレーション → ← 目次・はじめにへもどる