初級ではフロントを「顔」と捉えました。中級では、静的配信とアプリサーバ（SSR）を分けて正確に見ます。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
「フロント」と一口に言っても、実体は2種類が組み合わさっています。
- 静的配信（Nginx・CDNなど）— 変わらないファイルをそのまま返す。速く、負荷が軽い
- アプリサーバ（SSR）（Next.js など）— リクエストごとにHTMLを生成する
登場人物メモ:
- ※1 SSR／CSR／SSG — サーバ側生成／クライアント側生成／ビルド時生成
- ※2 ハイドレーション — サーバ生成のHTMLに、ブラウザでJSを結びつけて操作可能にする工程
この部分をもっと深く（上級）
どこで・いつHTMLを作るかが、速さ・鮮度・コストを決めます。
- CSR／SSR／SSG／ISR — クライアント／サーバ／ビルド時／再生成つき静的
- ストリーミングSSR — 出来た部分から送る
- エッジSSR — CDNのエッジで生成し、利用者に近い場所から
- サーバコンポーネント（RSC） — サーバで描き切り、クライアントのJSを削る
やさしく言うと（初級）
レストランのホール係を思い浮かべてください。注文を受け、料理（データ）は厨房（バックエンド）に頼み、盛り付けてテーブルに運ぶ——お客さんが接するのはこの人です。
フロントサーバは、見た目（HTML・CSS・JS ※1） を組み立てて返します。中身のデータは自分では作らず、バックエンドに頼みます。
登場人物メモ:
- ※1 HTML・CSS・JS — HTML（骨組み）・CSS（見た目の装飾）・JS（動き）。この3つで画面ができる
- ※2 静的ファイル — 画像・CSS・JSなど、誰に対しても同じもの
仕事の流れ
- 入口（ロードバランサ／リバースプロキシ）経由でリクエストが届く
- 静的アセット（画像・CSS・JS）は CDN／静的配信から返す（キャッシュが効く）
- 動的ページは SSR でHTMLを生成し、必要なデータは API から取得する
- ブラウザで ハイドレーション（HTMLにJSを載せて操作可能にする）
この部分をもっと深く（上級）
- リクエストがエッジ／オリジンに届く
- 必要ならストリーミングで段階的に送出
- クライアントで部分／遅延ハイドレーション（見えている所から動かす）
- 静的アセットはコード分割・プリロード・不変キャッシュ
やさしく言うと（初級）
- ブラウザから「このページください」を受け取る
- 画面の器（HTML）を用意する
- 中身のデータが要るなら、バックエンドに頼む（API）
- 受け取ったデータを画面にはめ込み、組み立てて返す
- ブラウザがそれを描画 → あなたが見る
描画方式の使い分け
- CSR（クライアント側描画）— 最初は空のHTML＋JSで描く。初期表示は遅めだが操作は軽快
- SSR（サーバ側描画）— 初期表示が速く、SEOに強い。サーバ負荷は上がる
- SSG（ビルド時生成）— あらかじめHTMLを作っておく。最速だが更新に弱い
アニメーション『HTMLをどこで組み立てるか』を開く
静的アセットはハッシュ付きファイル名＋長期キャッシュにして、変更時だけ新しいファイル名で配るのが定石です。
この部分をもっと深く（上級）
- アイランド／部分ハイドレーション — 動的な島だけをJSで動かし、残りは静的
- キャッシュ戦略 — ISR／stale-while-revalidateで鮮度と速さを両立
- アセットパイプライン — 圧縮（brotli）、ハッシュ名＋長期キャッシュ、重要リソースの優先読み込み
- 画像最適化 — 適応配信、遅延読み込み、寸法先行確保
やさしく言うと（初級）
- 静的配信 — 誰に見せても同じもの（画像・CSS・JS）は、そのまま配る。速い
- 動的（SSR） — 人によって違う画面（ログイン後など）は、その場で組み立てて返す
「トップページの見た目」は静的、「マイページ」は動的、と混ざっているのが普通です。
なぜフロントだけじゃダメ？
フロントとバックを分ける核心は 信頼境界（trust boundary） です。手元（クライアント）は信用できない、という前提から設計します。
- クライアントは信頼しない — ブラウザから来る値も、そこで走るコードも、すべて改ざん可能。フロントのバリデーションは「親切機能（UX）」であって防御ではない。最終的な検証・認可はバックで必ずやり直す
- 単一の真実（source of truth） — 在庫・残高などの正はDBが唯一。クライアントの計算結果は信用しない
- 秘密情報の隔離 — 資格情報・APIキー・署名鍵はサーバ側だけ。ブラウザに配られるコードは全部読まれる前提
- 関心の分離とスケール — 配信（CDNで剥がせる）と処理（水平スケール）は最適化の方向が違うので、分けたほうが伸ばしやすい
合言葉は「フロントでやったチェックは、サーバでもう一度やる」。二度手間に見えて、これが基本です。
見た目（フロント）と中身（バック）を分け、境界を API（JSON）で薄くつなぐ——この構図が分離の基本形です。
アニメーション『フロントとバックの分離』を開く
やさしく言うと（初級）
「フロントだけで全部やればいいのでは？」と思うかもしれません。でも、それだと困ることが3つあります。
- 手元は改ざんできる — ブラウザはあなたのPCの中。中身は見えるし、書き換えられます。もし「支払い済みか」をフロントで判断したら、誰でも書き換えて「済み」にできてしまう。だから大事な判断はサーバ（バック）でやる
- みんなで同じデータを見たい — 在庫や残高は、全員が同じ正しい値を見る必要がある。各自の手元で持つとバラバラになる。だからDBという「1つの正しい置き場」に集める
- 秘密が置けない — DBの鍵やAPIキーは、中身が見えるフロントには置けない。だから秘密に触れるのはサーバ側だけ
つまりフロントは「顔」に徹し、判断とデータは信じられない場所（手元）ではなく、守られた場所（バック）で扱う。これがフロントとバックを分ける理由です。
⚠️ うまくいかないとき
- TTFB（最初の1バイトまで）が遅い — SSRが重い → キャッシュ／SSGに寄せる
- ハイドレーションのズレ — サーバ生成とクライアントの状態が食い違い、画面が乱れる
- CLS（表示中のガタつき） — 画像や広告の高さを先に確保していない
この部分をもっと深く（上級）
- ハイドレーションミスマッチ — サーバとクライアントの出力差で乱れる
- Core Web Vitals悪化 — LCP／INP／CLS。重いJSやレイアウト未確保
- バンドル肥大 — 依存の入れすぎで初期JSが重い
- キャッシュとパーソナライズの衝突 — 個人向けを共有キャッシュに載せる事故
やさしく言うと（初級）
- 見た目は出るが中身が空 — バックエンドやDBが応答していない（顔はあるが料理が来ない）
- レイアウトが崩れる — CSSやJSが読み込めていない
- 真っ白 — JSのエラーで描画が止まった
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. SSRで生成したHTMLに、ブラウザ側でJSを載せて操作可能にする工程はどれ？
問2. 初期表示が速くSEOに強い代わりにサーバ負荷が上がる、サーバ側でHTMLを生成する描画方式を英字3文字で答えてください。
問3. 内容が全員共通で更新も稀な「会社概要」ページに最も向く生成方式はどれ？
問4. CSR（クライアント側描画）の特徴として正しいのは？
問5. フロント側で行う入力チェック（バリデーション）の位置づけとして正しいのは？
問6. 在庫や残高の「唯一の正しい値（単一の真実）」を持つべき場所はどこか？
問7. 「最初の1バイトが届くまで（TTFB）が遅い」とき、まず検討する対処は？
問8. 静的アセットを「変更したときだけ新しい名前で配る」ために、ファイル名へ付けるのは何付きの名前か（カタカナで）。