初級ではフロントを「顔」と捉えました。中級では、静的配信とアプリサーバ（SSR）を分けて正確に見ます。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
「フロント」と一口に言っても、実体は2種類が組み合わさっています。
- 静的配信（Nginx・CDNなど）— 変わらないファイルをそのまま返す。速く、負荷が軽い
- アプリサーバ（SSR）（Next.js など）— リクエストごとにHTMLを生成する
登場人物メモ:
- ※1 SSR／CSR／SSG — サーバ側生成／クライアント側生成／ビルド時生成
- ※2 ハイドレーション — サーバ生成のHTMLに、ブラウザでJSを結びつけて操作可能にする工程
仕事の流れ
- 入口（ロードバランサ／リバースプロキシ）経由でリクエストが届く
- 静的アセット（画像・CSS・JS）は CDN／静的配信から返す（キャッシュが効く）
- 動的ページは SSR でHTMLを生成し、必要なデータは API から取得する
- ブラウザで ハイドレーション（HTMLにJSを載せて操作可能にする）
描画方式の使い分け
- CSR（クライアント側描画）— 最初は空のHTML＋JSで描く。初期表示は遅めだが操作は軽快
- SSR（サーバ側描画）— 初期表示が速く、SEOに強い。サーバ負荷は上がる
- SSG（ビルド時生成）— あらかじめHTMLを作っておく。最速だが更新に弱い
アニメーション『HTMLをどこで組み立てるか』を開く
静的アセットはハッシュ付きファイル名＋長期キャッシュにして、変更時だけ新しいファイル名で配るのが定石です。
なぜフロントだけじゃダメ？
フロントとバックを分ける核心は 信頼境界（trust boundary） です。手元（クライアント）は信用できない、という前提から設計します。
- クライアントは信頼しない — ブラウザから来る値も、そこで走るコードも、すべて改ざん可能。フロントのバリデーションは「親切機能（UX）」であって防御ではない。最終的な検証・認可はバックで必ずやり直す
- 単一の真実（source of truth） — 在庫・残高などの正はDBが唯一。クライアントの計算結果は信用しない
- 秘密情報の隔離 — 資格情報・APIキー・署名鍵はサーバ側だけ。ブラウザに配られるコードは全部読まれる前提
- 関心の分離とスケール — 配信（CDNで剥がせる）と処理（水平スケール）は最適化の方向が違うので、分けたほうが伸ばしやすい
合言葉は「フロントでやったチェックは、サーバでもう一度やる」。二度手間に見えて、これが基本です。
見た目（フロント）と中身（バック）を分け、境界を API（JSON）で薄くつなぐ——この構図が分離の基本形です。
アニメーション『フロントとバックの分離』を開く
⚠️ うまくいかないとき
- TTFB（最初の1バイトまで）が遅い — SSRが重い → キャッシュ／SSGに寄せる
- ハイドレーションのズレ — サーバ生成とクライアントの状態が食い違い、画面が乱れる
- CLS（表示中のガタつき） — 画像や広告の高さを先に確保していない
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. SSRで生成したHTMLに、ブラウザ側でJSを載せて操作可能にする工程はどれ？
問2. 初期表示が速くSEOに強い代わりにサーバ負荷が上がる、サーバ側でHTMLを生成する描画方式を英字3文字で答えてください。
問3. 内容が全員共通で更新も稀な「会社概要」ページに最も向く生成方式はどれ？
問4. CSR（クライアント側描画）の特徴として正しいのは？
問5. フロント側で行う入力チェック（バリデーション）の位置づけとして正しいのは？
問6. 在庫や残高の「唯一の正しい値（単一の真実）」を持つべき場所はどこか？
問7. 「最初の1バイトが届くまで（TTFB）が遅い」とき、まず検討する対処は？
問8. 静的アセットを「変更したときだけ新しい名前で配る」ために、ファイル名へ付けるのは何付きの名前か（カタカナで）。