HTML はどこで作られるか

CSR（クライアントサイドレンダリング）は、画面をブラウザで組み立てるやり方だよ。

サーバから届く HTML は、ほとんど空っぽ。置き場所を1つ用意して、あとは JavaScript を読み込む指示が書いてあるだけ。そこから先の段取りはこうなる。

• JavaScript のファイルを落としてくる
• それを動かす
• データの往復を出して、中身をもらう
• もらったデータで、画面を組み立てる

つまり中身が出るまでに4段階待つことになるので、最初の表示までが遅くなりやすい。そのあいだ画面は真っ白だったり、読み込み中の印だけが出ていたりするね。

そのかわり、サーバの仕事は置いてあるファイルを配るだけなので軽いよ。困りごとがもう1つあって、検索エンジンやSNSのプレビューが中身を読めないことがある。届いた HTML が空だからね。

SSR（サーバサイドレンダリング）は、要求が来るたびにサーバが完成した HTML を作って返すやり方だよ。

サーバの側でデータベースを見て、その人のぶんの中身をはめこんで、出来上がった HTML を返す。ブラウザは届いたものをそのまま描けばいいので、待つ段階が1つで済むね。

利点は2つ。最初の表示が速いことと、いつも新しいこと。返す直前にデータを読んでいるので、1秒前の更新も入っているよ。届いた HTML に中身が入っているから、検索エンジンやプレビューにも読める。

代わりに払うのはサーバの負担だよ。要求が10万回来れば、組み立ても10万回。置いてあるファイルを返すのとは、要る力がまるで違うんだ。

SSG（静的サイト生成）は、公開する前に HTML を作り置きしておくやり方だよ。

作るのは1回だけ。あとは出来上がった HTML を、置いてあるファイルとして配るだけになる。要求が来てから考えることは何も無いね。

だからいちばん速くて、いちばん安い。プログラムを動かさないので、ファイルを配る仕組みにそのまま乗せられるよ。届く HTML に中身も入っているので、検索エンジンやプレビューにも困らない。

弱点はひとつだけ、でも大きいよ。内容を変えるには作り直しが要るんだ。作った時刻の中身で固まっているので、そのあとデータが変わっても、配られている HTML は古いまま。

つまり SSG が向くのは、誰が見ても同じで、めったに変わらないものだね。

同じ4つの軸で見ると、性格の違いがはっきりするよ。

最初の表示の速さ
- SSG … いちばん速い（置いてあるものを返すだけ）
- SSR … 速い（組み立てる時間はかかる）
- CSR … 遅くなりやすい（JS を動かしてデータを取るまで待つ）

データの新しさ
- SSR … いつも新しい（返す直前に読む）
- CSR … 新しい（開いたあとに取りに行く）
- SSG … 作った時点で止まる

サーバの負担
- SSG … いちばん軽い
- CSR … 軽い（ファイルを配るだけ）
- SSR … 重い（要求のたびに働く）

作り直しの要否
- SSG … 内容を変えるには作り直しが要る
- SSR / CSR … 要らない（そのとき読む）

見てのとおり、全部がいちばんになる方式は無い。だから「どれが正しいか」ではなく「このページは何を優先するか」で決めるんだ。

SSG の弱点は「古くなること」だけだったよね。それなら、作り置きを定期的に作り直せばいい。この考え方が ISR（増分的な静的再生成）や再生成と呼ばれるやり方だよ。

合図の出し方は2通りあるよ。

• 時間で切る … 「作ってから10分たっていたら作り直す」
• 更新で知らせる … 記事を書き換えたときに「あのページを作り直して」と伝える

大事なのは、作り直しているあいだも古いほうを配り続けること。だから学習者を待たせないよ。表示の速さは SSG のままで、古さだけを減らせるんだ。

完全に最新ではないよ。「10分までは古いかもしれない」を受け入れる代わりに、SSR の負担を払わずに済ませる中間のやり方だと考えてほしい。

手がかりは、前のレッスンで使ったものと同じだよ。誰にとっても同じか、人によって違うか。

• 誰にとっても同じで、めったに変わらない … 作り置き（SSG）。会社の紹介、利用規約、書き終えた記事
• 誰にとっても同じだけど、たまに変わる … 作り置き＋再生成（ISR）。ニュースの一覧、商品の一覧
• 人によって違う、または常に変わる … 要求のたびに作る（SSR）か、ブラウザで取る（CSR）。自分の注文履歴、通知、管理画面

そしていちばん大事なこと。方式はサイト全体で1つに決めるものではなくて、ページごとに違ってよいんだ。

同じサイトの中で、トップページは作り置き、商品の一覧は再生成、自分のページは要求のたびに作る — これでいい。1ページずつ「これは誰にとっても同じか」を聞いていけば決まるよ。

ここは取りちがえやすいところ。「SSR にすれば API は要らない」と思ってしまう人がいるけれど、それは誤りだよ。

たしかに最初の1枚は、サーバがデータを読んで HTML に入れてくれる。だからその1枚を出すぶんには、ブラウザからのデータの往復は要らない。

でも、そのあとの操作はどうだろう。

• 「もっと見る」を押して次の20件を出す
• 並べ替えを新しい順から人気順に変える
• 投稿ボタンを押して書きこむ

どれも、その時点で新しく必要になったデータだね。HTML に入っていたのは、最初の1枚を作った時点のぶんだけ。だからここからは結局、データの往復を出すことになるよ。

SSR が置きかえるのは最初の1枚だけ。それ以降の往復は、どの方式でも残るんだ。

サーバでも HTML を組み立てるようになると、同じ言葉で書いたコードが、2つの場所で動くことになる。ここで気をつけることが2つあるよ。

① サーバにはブラウザの機能が無い。window や document、画面の幅を測る命令などは、ブラウザが用意しているものだよ。サーバで組み立てているときにそれを触ると、その場で失敗する。「ブラウザで動かしたら平気だったのに」というつまずきの正体はこれだね。

② ブラウザで動く側に、秘密を書いてはいけない。1本目でやったとおり、ブラウザに送ったものは全部見える。外部サービスの鍵や、データベースにつなぐための情報は、サーバでだけ動く場所に置くこと。

どちらも、まずこのコードはどちらで動くのかを意識できていれば防げるよ。

サーバが作った HTML が届いた時点で、画面は見えている。でも、まだ押せないんだ。

届いた HTML は文字列であって、「このボタンを押したらこうする」という動きは入っていないからだね。その動きを付けるのは、あとから届く JavaScript のほう。

サーバが作った HTML に、ブラウザ側の JavaScript があとから結びついて操作できるようになることを、ハイドレーションと呼ぶよ。

だから、SSR や SSG のページには見えているのに押せない一瞬があるんだ。開いた直後にボタンを連打しても何も起きなくて、少し待つと動きだす — あれがこの時間だよ。

「表示が速い」と「使えるようになるのが速い」は、別のこと。SSR や SSG が短くしているのは前者で、後者を短くするには結びつける JavaScript を軽くする必要があるよ。

このレッスンの5つだよ。

• HTML の作り場所は3通り。CSR（ブラウザ）・SSR（要求のたびにサーバ）・SSG（あらかじめ作り置き）
• 選ぶ軸は最初の表示の速さ・データの新しさ・サーバの負担・作り直しの要否。全部がいちばんになる方式は無い
• ISR / 再生成は、作り置きの速さを保ったまま古さを減らす中間のやり方
• 方式はページごとに変えてよい。「誰にとっても同じか」で1ページずつ決める
• SSR にしてもデータの往復は消えない。置きかわるのは最初の1枚だけ

そして忘れないでほしいのが、そのコードはどちらで動くのか。ブラウザの機能はサーバに無いし、秘密はブラウザに置けない。

次のレッスンでは、②のデータをもらう往復そのものを開けて見ていくよ。