CSR・SSR・SSG・ISRとHydration — 見えているのに、押せない時間
Webページの中身(HTML)を誰が、いつ作るかには、いくつかのやり方があります。ブラウザがJavaScriptで組み立てるCSR、リクエストのたびにサーバーで作るSSR、ビルドのときに作り置きしておくSSG、その作り置きを時々作り直すISR。どれを選ぶかで、画面が見えるまでの速さと中身の新しさが変わります。
もう1つ見落とされがちなのが、「見えている」と「押せる」は別だということです。サーバーで作ったHTMLは、見た目は完成していても、JavaScriptが結びつく(Hydration)までボタンはただの絵。下の図1で方式を選んで「ページを開く」を押し、表示された瞬間に「いいね」を連打してみてください。
誰がHTMLを作るか — 速さと新しさの交換
CSRでは、サーバーが返すのは中身が空のHTMLとJavaScriptだけ。ブラウザがJSを読み込み、APIからデータを取ってきて、ようやく画面を組み立てます。図1でCSRを開くと、しばらく真っ白なのが分かります。その代わり、一度表示されれば見えた瞬間から押せます。
SSRは、リクエストが来るたびにサーバーがDBを読んでHTMLを作ります。中身はいつも最新ですが、毎回の作業があるぶん最初の1バイトが届くまで少し待たされます。SSGは、ビルドのときに1回だけHTMLを作ってCDNに置いておく作り置きです。届くのは最速ですが、図1で在庫を減らしても再ビルドするまで古いままです。
ISRはその中間です。作り置きを配りつつ、決めた時間(図1では1分)が過ぎてから最初に来たリクエストで、古いものを返しながら裏で作り直す。だから作り直しのきっかけになった1人は古いページを見て、次の人から新しいページになります。図1で「1分すすめる」→「ページを開く」を2回やると、この1回遅れが確かめられます。
Hydration — 絵だったボタンに、命が入る瞬間
SSR・SSG・ISRで届くHTMLは、見た目だけ完成した模型です。いいねボタンも描かれてはいますが、押されたら何をするかというJSの処理はまだ結びついていません。あとからJSが届いて、すでにあるHTMLの各部品に処理を結びつけていく作業がHydration(水を与えて生き返らせる、の意)です。
図1で「見えるまで」と「押せるまで」の差が、押しても反応しない時間です。利用者には見た目で区別がつかないので、「壊れている」と感じさせてしまう。JSを小さくする、ページの一部だけをHydrationする(アイランド)、Hydration自体をなくす工夫など、最近のフレームワークがこの差を縮めることに力を入れているのはこのためです。
- CSR(Client-Side Rendering)
- ブラウザがJSでHTMLを組み立てる方式。最初は空っぽで、JSの実行後に表示される。
- SSR(Server-Side Rendering)
- リクエストごとにサーバーでHTMLを作って返す方式。中身は常に最新。
- SSG(Static Site Generation)
- ビルド時にHTMLを作っておき、そのまま配る方式。最速だが、再ビルドまで中身が変わらない。
- ISR(Incremental Static Regeneration)
- 作り置きを配りつつ、一定時間ごとに裏で作り直す方式。
- Hydration
- サーバーで作られたHTMLに、ブラウザ側でJSの処理を結びつけて操作できるようにすること。
まとめ
4つの方式の違いは、HTMLを作る人(ブラウザかサーバーか)とタイミング(毎回か、作り置きか)の組み合わせです。サーバー側で作るほど早く見え、作り置きするほど速いが古くなる。そしてサーバーで作った画面は、Hydrationが終わるまで「見えるけど押せない」。ページごとに「どれくらい新しくないと困るか」「どれくらい早く見せたいか」で、方式を選び分けるのが基本です。