CSR・SSR・SSGは「HTMLをいつ組み立てるか」の違い
この記事の内容は次のとおりです。
Webページの「作り方」は3種類ある
WebページのHTMLをいつ、どこで組み立てるかには3つのやり方があります。まず略称から。
| 略称 | 正式名称 | 日本語 | ひとことで言うと |
|---|---|---|---|
| CSR | Client-Side Rendering | クライアントサイドレンダリング | ブラウザが組み立てる |
| SSR | Server-Side Rendering | サーバーサイドレンダリング | アクセスのたびにサーバーが組み立てる |
| SSG | Static Site Generation | 静的サイト生成 | 公開前にあらかじめ組み立てておく |
レストランで例えると
SSGは「作り置きのお弁当」です。開店前に作って並べてあるので、注文したらすぐ出てきます。ただし中身は全員同じで、開店後にメニューを変えることはできません。
SSRは「注文を受けてから作る料理」です。その人に合わせて中身を変えられますし、いつでも最新の食材が使えます。そのぶん、出てくるまでにキッチンが動く時間がかかります。
CSRは「空の皿と、食材＋レシピの入った袋を渡して、持ち帰って作ってもらう」やり方です。お店（サーバー）が渡すのは空の皿（空のHTML）と袋（JS）だけなので身軽ですが、持ち帰ってから自分で調理して皿に盛り付ける（ブラウザがJSを実行してHTMLを組み立てる）ぶん、食べられるまで一番時間がかかります。
ここで、店（サーバー）の料理（HTML）の写真を撮りに来る人——クローラーさん——が登場します。クローラーとは、検索エンジンやSNSがWebページを自動で巡回させているプログラムのことです。ページの中身を読み取って、検索結果やリンクのプレビューに使います。
クローラーさんは食べに来たわけではなく、写真を撮りに来ただけです。そしてクローラーは、その場で調理が終わるのを待ってはくれません。だからCSRでは、渡された時点の皿——まだ何も盛り付けられていない皿——しか写真に撮れません。
皿の中身が読み取れなければ、Google検索やYahoo検索の検索結果には出てきません。一般に、クローラーがページの中身をすぐ認識できるほど、検索結果の上位にも組み込まれやすいとされています。
クローラーさんが同じサーバーを巡回しても、見つけるものは方式によって変わります。
選び方は、たった1つの質問で決まる
そのページの中身は、全員に同じで、公開前に決まっているか？
- はい → SSG（作り置きできる）
- いいえ → SSR（その場で作るしかない）
「ログイン中のユーザー名が出る」「在庫数がリアルタイムで変わる」といったページは、そもそも作り置きできないのでSSRになります。逆に会社紹介やブログ記事のように、誰が見ても同じで、更新のたびに作り直せば済むものはSSGが向いています。
SSRとCSR、どちらも「作り置きできない」なら何で決めるか
この質問1つで決まるのはSSGとそれ以外の境目までです。「いいえ」に転んだ先のSSRとCSRは、実は似た者どうしで、ここの使い分けのほうが迷います。両方とも「その場で組み立てる」点は同じで、組み立てる場所がサーバーかブラウザかだけが違います。
判断材料は主に2つです。
- 検索エンジンに見せたいか。 SSRは完成品のHTMLをそのまま返すので、クローラーにもすぐ読めます。CSRは空の皿を返すだけなので、前述のとおりクローラーには中身が見えません。検索結果に出したいページはSSRです。
- 開いたあとも中身が動き続けるか。 チャットやダッシュボードのように、開いたあともサーバーとやり取りしながら中身が変わり続ける画面では、最初のHTMLをサーバーが律儀に組み立てても、表示した瞬間から古くなっていきます。だったら最初からブラウザ側で完結させ、以降の更新もブラウザ主導にしてしまうほうが理にかなっています。これがCSRです。
つまり、検索に出したくて、開いたあとは中身が変わらない画面はSSR、検索に出す必要がなく、開いたあともずっと動き続ける画面はCSR、という組み合わせが典型です。両方の条件が一致しない画面（検索には出したいが動き続ける、など）は、素直には決まらず悩みどころとして残ります。
実際のプロジェクトでの使い分け
個人開発で作っている匿名チャットサービスの、画面ごとの選択です。
| 画面 | パス | 選択 | 理由 |
|---|---|---|---|
| トップページ | / | SSG | 中身がコードの中にあり、誰が見ても同じ。検索と広告の入口なので、最速で返したい |
| サービス紹介 | /about | SSG | 同上 |
| トピック選択 | /topics | SSR | 話題の一覧は管理画面から変えられる。作り置きすると、古い一覧を配り続けてしまう |
| マッチング待機 | /waiting | SSR | 待機状況は人によって違う。そもそも作り置きができない |
| チャットルーム | /rooms/{id} | CSR | リアルタイムに会話が流れる画面。検索結果に出す必要もない |
この表から読み取れること
1つのサイトの中で、3つすべてを使い分けています。 「このサイトはSSRで作りました」という言い方をすることがありますが、実際には画面ごとに向き不向きがあり、混ぜて使うのが普通です。
検索に出したい画面ほど、作り置き（SSG）に寄せています。 速く返せるうえ、クローラーが来た時点で中身が完成しているからです。
逆に、検索に出す必要のない画面では、SSRを選ぶ積極的な理由が1つ消えます。 チャットルームは会員だけが見る画面なので、検索エンジンに読ませる意味がありません。とはいえ「検索に出さなくていい」だけならSSRのままでも困らない話で、これだけではCSRを選ぶ理由になりません。チャットルームがCSRになった決め手は前節の2つめの軸——開いたあとも中身が動き続けるか——のほうです。会話はWebSocketで流れ続けるので、最初のHTMLをサーバーが丁寧に組み立てても、表示した瞬間から古くなります。「CSRはSEOに悪い」と一括りにするのではなく、検索に出したいか、開いたあとも動き続けるかの両方で決めるのが実際のところです。