中級では静的配信とSSRを見ました。上級では、レンダリング戦略と配信最適化を性能の観点で。
上級の解説は準備中のため、上級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
描画戦略の地図
どこで・いつHTMLを作るかが、速さ・鮮度・コストを決めます。
- CSR／SSR／SSG／ISR — クライアント／サーバ／ビルド時／再生成つき静的
- ストリーミングSSR — 出来た部分から送る
- エッジSSR — CDNのエッジで生成し、利用者に近い場所から
- サーバコンポーネント（RSC） — サーバで描き切り、クライアントのJSを削る
配信の流れと最適化
- リクエストがエッジ／オリジンに届く
- 必要ならストリーミングで段階的に送出
- クライアントで部分／遅延ハイドレーション（見えている所から動かす）
- 静的アセットはコード分割・プリロード・不変キャッシュ
パフォーマンス設計
- アイランド／部分ハイドレーション — 動的な島だけをJSで動かし、残りは静的
- キャッシュ戦略 — ISR／stale-while-revalidateで鮮度と速さを両立
- アセットパイプライン — 圧縮（brotli）、ハッシュ名＋長期キャッシュ、重要リソースの優先読み込み
- 画像最適化 — 適応配信、遅延読み込み、寸法先行確保
⚠️ 落とし穴
- ハイドレーションミスマッチ — サーバとクライアントの出力差で乱れる
- Core Web Vitals悪化 — LCP／INP／CLS。重いJSやレイアウト未確保
- バンドル肥大 — 依存の入れすぎで初期JSが重い
- キャッシュとパーソナライズの衝突 — 個人向けを共有キャッシュに載せる事故
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問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）。