今更CSR,SSG,SSRをざっくり説明

CSR（Client-Side Rendering）

Client-side rendering (CSR) means rendering pages directly in the browser using JavaScript. All logic, data fetching, templating and routing are handled on the client rather than the server.

レンダリングをClient側に任せる方法。 React や Vue などのJavaScriptライブラリやフレームワークを使う場合は特に意識せずに、自然に使う方法でもある。

初期ロード時にデカイJavascriptを送信するし、レンダリングもJavascriptで行われるので処理量が増えて、ページロードされるまで時間がかかってしまう。 最近はクライアント側のデバイスの性能もよくなり、Javascriptエンジンの性能も凄くよくなったので個人レベルではあまり気にしなくても良いかも知れないが、デバイスの性能によって表示時間の問題も考えられる。 ReactではlazyとSuspenseを使うとコードの分割ができるので初期ロードやレンダリングの問題を少しは解消できるかも。

しかし、ユースケースにもよるが、 SEOを前提 にしているサイトであればCSRは弱点がある。

<html>
  <head>
    <title>sample</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/js/bundle.js"></script>
  </body>
</html>

CSRはクライアントでレンダリングをするので初期ロード時は上のようなページになる。 その結果、Googleさんが拾ってくれなくなるのでSEOではかなりのマイナス要素になってしまう。 これは全てのSPAやCSRのサイトでは共通している課題でもあるが、今のところ簡単にSEO対策をするのは難しいと思う。

最近のGoogleのイベントとかでもSPAのSEOの話は多く上がってきていて、今後はSPAやCSRのメディアもちゃんとクローリングしてくれることを期待しているが、今のところはSEOを念頭にしていれば他の方法を試すべきではないかな

ログインが必要なサービスや、ユーザーごとにカスタマイズされているサービスの場合はSEOの対策はいらないのでCSRでも十分。

SSR（Server-Side Rendering）

Server rendering generates the full HTML for a page on the server in response to navigation. This avoids additional round-trips for data fetching and templating on the client, since it’s handled before the browser gets a response.

CSRの弱点を補うため、クライアント側でなく、サーバー側でレンダリングをして、クライアントに返す方法。 ユーザーのデバイスの性能に依存しないのでレンダリングの問題は一定なくなるが、サーバーで処理してレンダリングさせるので最終的なレンダリングの時間は少なからずある。

SEOの観点ではCSRのような問題はなくなるが、SSGに比べると微妙かも。 パフォーマンスでもSSGより遅いし、そもそもSSRを実現するためには別途レンダリングのサーバーが必要になるので少し不便。

何より、Next.jsを使うなら SSRでできることはSSGでもできる ので個人的には好きではない。 昔は違ったかも知れないが、Nextの９以降からはSSGが非常に簡単に実現できるので特に凄くこだわりがなければSSGを使った方が良いかもと思っている。

余談だが、あまりSSRのイメージがつかないかも知れないが、ローカルで yarn dev とかで立ち上げる開発環境がまさにSSRになってるので

SSG(Static Site Generation)

SSGはビルド時にHTMLを構築する方法。 ビルド時に data fetching, templating and routing などのユーザーのリクエストを事前に行い、HTMLファイルとしてexportする。

HTMLにしておくメリットとしてはCDNに載せてキャッシュさせるとロードやパフォーマンスは上記の２つと比べると凄く早い。結果物はただのHTMLなので個別ページは小さくもなるし、SEOの対策も簡単。 セキュリティも複雑なロジックがなくなるので対策も簡単 or 要らないかも知れない。

Next.jsでは Dynamic routing や、 dyanamic contents SSGで簡単に扱えるのでSSRでやっていたことは大体できる。

ブログや、メディアを構築するなら SSG を最初に検討すべきだと思う。

しかし、個人レベルではなく、事業レベルのサイトで数万やそれ以上のページを持ったサイトの場合、事前に全てのページを全部レンダリングするSSGは現実的ではない。 また、SNSのように複数人が使い、更新が激しい場合はSSGではビルド時だけ data fetching を行うため、上手く情報を届けられなくなる。

Next.jsでは fallback、ISR で解決できるので事業レベルでのサービスでもSSGは検討してみる価値は十分あるのではないかと思う。

参考: google develpers rendering-on-the-web