描画をどこでするか — HTML を作る時と場所を、データごとに選ぶ

What — HTML を、いつ・どこで作るか

ブラウザに表示される HTML は、誰かがどこかで組み立てています。違いはいつ作るかとどこで作るかです。

ビルド時: データ → HTML（全ページ）
アクセス時: CDN → HTML をそのまま返す

サーバーは何もしない

決めるのはデータの性質

どの方式にするかは、アプリ全体ではなく、ページの中のデータごとに決まります。見るのは 2 つです。

• どのくらいの速さで変わるか（年に数回・1 日 1 回・秒単位）
• 誰のものか（全員に同じ・人ごとに違う）

冒頭のサイトは、1 行目と 2 行目と 3 行目が 1 つのページに混ざっていました。それを全部 1 行目の作り方（CSR）で作り、次に全部 2 行目の作り方（SSR）で作り直したのが失敗です。

ハイドレーション：表示されても、まだ押せない

SSR や SSG で作った HTML は、表示はすぐされますが、まだ動きません。ボタンを押せるようになるのは、ブラウザが JavaScript を読み込み、HTML の各部分に処理を結び付けたあとです。この結び付けをハイドレーションと呼びます。

• 表示が速くなっても、JavaScript が大きいと押せるまでが遅い
• その間に押された操作は、反応しないか、遅れて反応する（Core Web Vitals の INP が悪くなる）

React のサーバーコンポーネントは、ここに対する答えの 1 つです。動きの無い部分はサーバーで HTML にしたまま、JavaScript をブラウザに送らない。押せる部品だけが JavaScript を持ちます。

Why — なぜ「全部同じ作り方」になるのか

フレームワークの既定に、アプリごと乗る

フレームワークを選ぶと、既定の作り方が付いてきます。SPA のテンプレートなら全部 CSR、サーバー描画のフレームワークなら全部 SSR。既定のまま全ページを作ると、データの性質の違いが見えなくなります。

冒頭のサイトは、CSR の既定で作り、問題が出たので SSR の既定にアプリごと乗り換えました。問題の単位（データ）と、直した単位（アプリ）がずれていました。

共有と検索は、JavaScript を待ってくれない

CSR で作ると、HTML には中身がありません。

• X や Slack の共有カードを作る仕組みは、多くの場合 JavaScript を実行せず、HTML の <meta> だけを読む。中身の無い HTML からは、カードが作れない
• 検索エンジンは JavaScript を実行できるものもあるが、実行は後回しにされやすく、取りこぼしもある

共有や検索から人が来るページは、少なくとも題名・説明・画像は HTML に入れて返す必要があります。ログインしないと見られない画面は、この制約を受けません。

サーバーで描くことは、費用を払うこと

SSG と CDN の組み合わせは、アクセスが 100 倍になってもサーバーの仕事は増えません。SSR は、アクセスの数だけ描画の仕事が増えます。セールや、SNS で話題になった瞬間のように、アクセスが急に増える場面で差が出ます。

SSR を選ぶなら、描いた結果をどこかでキャッシュできないかを先に考えます。1 日 1 回しか変わらないページを毎回描く理由はありません。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。