CSR
概要
- ブラウザがサイトにアクセスすると、
<script>要素だけ書いた、中身が空のHTMLを返す - JS読み込み、APIでデータ取得(ページは表示されない)
- データが出揃ったらReactなどでDOMをレンダリングする
メリット
- クライアントサイドで動くことだけを考えれば良いので実装が単純
- HTMLとJSなどの静的ファイルを返せばいいので動的なサーバーの運用コストがない
- 動的なURLをHTMLに向けるためのルーティングは必要(SSGより面倒)
デメリット
- 初期表示のパフォーマンスが出ない
- JSが実行できないクライアントが内容を読めない
- SEOの問題は少ない(検索エンジンのクローラーがJS実行できるようになった)
- OGPが生成できない
用途
- 管理画面やGmail
SSG
概要
- デプロイのタイミングなどで事前にHTMLを静的に作成
- ブラウザがサイトにアクセスすると、プリレンダリングされたHTMLを表示(クリックイベントなどの振る舞いはない)
-
<script>要素からJSをロード - Reactでレンダリング
メリット
- 初期表示のパフォーマンスが良い
- JSが実行できないクライアントでも読める(OGP生成可能)
- サーバ不要でS3や静的CDNを活用できる
デメリット
- ビルドする対象が多い場合、ビルド時間が長い
- コンテンツが追加されたり変更される度にビルドが必要になる
- コンテキストによる内容の出しわけが困難
- ビルドされる静的ファイルに情報を含めずにクライアントサイドで出し分けると、レイアウトシフトが発生してしまう
用途
- コンテンツが頻繁に更新されないブログなどのメディア
SSR
概要
- Railsと同じ
- ブラウザがサイトにアクセスすると、サーバーが動的にHTMLを生成して返す
- SSGと同じコンテンツ表示
メリット
- CDNを使えばSSGと同様のパフォーマンスを得られる
- コンテキストによってサーバーでの生成内容を変えれる
デメリット
- 動的なサーバーを運用する必要がある
- 実装が複雑になる
- クライアントとサーバーで同じコードを用いるが、実行環境がクライアントはブラウザ、サーバーはNode.jsで異なる
- Nextで複雑さが多少軽減される
用途
- SSGでは難しい、更新頻度が高い大量のコンテンツを持つページ
CSR vs SSG vs SSR
-
まずは CSRかSSGのどちらかを検討
- 静的にHTMLを生成するのが難しくない場合CSR
-
コンテンツ的に静的生成が難しくてOGPの対応や初期レンダリング速度に妥協できない場合SSR
-
サイト全てを統一する必要はない
- レシピページはSSR、その他はCSR
- ブログ記事はSSR、コメントはCSRとか