中級では静的配信とSSRを見ました。上級では、レンダリング戦略と配信最適化を性能の観点で。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
描画戦略の地図
どこで・いつHTMLを作るかが、速さ・鮮度・コストを決めます。
- CSR／SSR／SSG／ISR — クライアント／サーバ／ビルド時／再生成つき静的
- ストリーミングSSR — 出来た部分から送る
- エッジSSR — CDNのエッジで生成し、利用者に近い場所から
- サーバコンポーネント（RSC） — サーバで描き切り、クライアントのJSを削る
やさしく言うと（中級）
「フロント」と一口に言っても、実体は2種類が組み合わさっています。
- 静的配信（Nginx・CDNなど）— 変わらないファイルをそのまま返す。速く、負荷が軽い
- アプリサーバ（SSR）（Next.js など）— リクエストごとにHTMLを生成する
登場人物メモ:
- ※1 SSR／CSR／SSG — サーバ側生成／クライアント側生成／ビルド時生成
- ※2 ハイドレーション — サーバ生成のHTMLに、ブラウザでJSを結びつけて操作可能にする工程
配信の流れと最適化
- リクエストがエッジ／オリジンに届く
- 必要ならストリーミングで段階的に送出
- クライアントで部分／遅延ハイドレーション（見えている所から動かす）
- 静的アセットはコード分割・プリロード・不変キャッシュ
やさしく言うと（中級）
- 入口（ロードバランサ／リバースプロキシ）経由でリクエストが届く
- 静的アセット（画像・CSS・JS）は CDN／静的配信から返す（キャッシュが効く）
- 動的ページは SSR でHTMLを生成し、必要なデータは API から取得する
- ブラウザで ハイドレーション（HTMLにJSを載せて操作可能にする）
パフォーマンス設計
- アイランド／部分ハイドレーション — 動的な島だけをJSで動かし、残りは静的
- キャッシュ戦略 — ISR／stale-while-revalidateで鮮度と速さを両立
- アセットパイプライン — 圧縮（brotli）、ハッシュ名＋長期キャッシュ、重要リソースの優先読み込み
- 画像最適化 — 適応配信、遅延読み込み、寸法先行確保
やさしく言うと（中級）
- CSR（クライアント側描画）— 最初は空のHTML＋JSで描く。初期表示は遅めだが操作は軽快
- SSR（サーバ側描画）— 初期表示が速く、SEOに強い。サーバ負荷は上がる
- SSG（ビルド時生成）— あらかじめHTMLを作っておく。最速だが更新に弱い
アニメーション『HTMLをどこで組み立てるか』を開く
静的アセットはハッシュ付きファイル名＋長期キャッシュにして、変更時だけ新しいファイル名で配るのが定石です。
⚠️ 落とし穴
- ハイドレーションミスマッチ — サーバとクライアントの出力差で乱れる
- Core Web Vitals悪化 — LCP／INP／CLS。重いJSやレイアウト未確保
- バンドル肥大 — 依存の入れすぎで初期JSが重い
- キャッシュとパーソナライズの衝突 — 個人向けを共有キャッシュに載せる事故
やさしく言うと（中級）
- TTFB（最初の1バイトまで）が遅い — SSRが重い → キャッシュ／SSGに寄せる
- ハイドレーションのズレ — サーバ生成とクライアントの状態が食い違い、画面が乱れる
- CLS（表示中のガタつき） — 画像や広告の高さを先に確保していない
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 利用者操作の反応の速さを測る Core Web Vitals の指標は？
問2. HTMLを「完成を待たず、出来た部分から順に送る」レンダリング手法は？
問3. サーバコンポーネント（RSC）のねらいとして正しいのは？
問4. ISR や stale-while-revalidate が両立させようとしているのは？
問5. Core Web Vitals の LCP が測るのは？
問6. 個人向けページを共有キャッシュ（CDN）に載せてしまうと起きる事故は？
問7. 表示中に要素がずれる「レイアウトのガタつき」を測る Core Web Vitals の指標を英字3文字で答えてください。
問8. CDNの利用者に近い拠点でHTMLを生成し、近い場所から返すレンダリング方式を何と呼ぶか（カタカナで、末尾はSSR）。