🍣
CSR,SSR,SSG,ISRについて理解する
はじめに
CSR、SSR、SSG、ISR という用語はよく目にしますが、これまでなんとなくでしか理解できていませんでした。
そこで、この機会に、それぞれがどのようなメリット・デメリットを持つのか、そしてどのような場面で採用するべきかを整理していきたいと考えています。
CSR（Client Side Rendering）
CSR は、リクエストに対して、サーバから空の HTML ファイル、CSS、JavaScript を取得し、その後、初期データを取得して HTML をレンダリングします。
処理の流れ
- クライアントからリクエストが送られる。
- サーバーから空の HTML ファイル、CSS、JavaScript が返却される。
- API を叩いて初期データを取得して HTML をレンダリング。
CSR を採用するメリット
- ブラウザによるページ遷移の時間がかからないので、UX を向上することができる
- ページ遷移が高速（実際には遷移しているように見えているだけ）
- ネイティブアプリの代わりとして利用できる。
- CSR を採用するデメリット
- 初回にまとめてデータを取得してくるので、初回ロードが遅い。
- アプリケーションの大きさに比例して JavaScript の記述量も増加するので、ページを表示させるのが遅くなる可能性がある。（ユーザーの回線速度などに依存）
- ブラウザの処理に任せていた部分を、開発者が実装することになるため開発コストがかかる。
- SEO に影響する場合がある 空の HTML が返却されるので、クローラーがコンテンツを認識できない可能性がある。 ※現在は SEO に影響する問題は少なくなっています。
- OGP に対応することができない Facebook や Twitter のクローラーが JavaScript を実行しないため
どのような場面で採用するべき？
- SEO をそこまで意識しないような管理画面系など
- ユーザーが頻繁にページ遷移をするようなサービス
SSR (Server Side Rendering)
SSR はクライアント側ではなく、サーバー側で HTML をレンダリングします。
リクエストを受けたサーバーが必要なデータを取得した後に HTML を生成し、クライアントに返却します。
処理の流れ
- クライアントからリクエストが送られる。
- サーバーが API リクエスト
- 必要なデータを取得する
- サーバー側で HTML をレンダリング
- HTML/CSS/JavaScript をクライアントに返却
- クライアントサイドで JavaScript が実行されてレンダリングされる。
（ハイドレーション）
SSR を採用するメリット
- サーバーサイドで HTML が生成されるので、SEO と OGP に対応可能
- サーバー側で JavaScript を実行して生成した HTML をクライアントに返却するため初回ローディングがはやい。
- ブラウザ側の負担が減るので、低スペックなデバイスや回線速度が低い場合も表示速度を保つことができる。
SSR を採用するデメリット
- リクエストごとに HTML を生成するので、大量のアクセスが来た場合などに、サーバー側の負荷が高くなってしまう。
- CSR に比べると、初回表示が早いが、ユーザーからのリクエストを受けてから HTML を生成するため、時間がかかる。
- サーバーサイドで JavaScript で実行する必要があるため、Node.js が乗った Web サーバーが必要になる
どのような場面で採用するべき？
- SEO を意識するようなサービス
- 動的コンテンツが多いサービス
SSG (Static Site Generation)
SSG は、ビルド時に事前にサーバー側で API でのデータフェッチも含め、サイト全体の HTML 構築を完了しておく。
リクエストがあった際にはそれを返却するだけです。
CDN にキャッシュさせておくことによって高速にページを表示することが可能です。
処理の流れ
- API リクエスト
- データ取得
- 静的ファイル生成
↑ ビルド時に静的ファイル生成までを事前に完了しておく。
- クライアントからリクエストが送られる。
- サーバーは事前に生成しておいた静的ファイルを返却する。
SSG を採用するメリット
- 静的ファイルを使用するため、表示速度が SSR よりも高速
- SEO に強い
SSG を採用するデメリット
- 更新にはビルドが必要になるため、リアルタイムで更新することが難しい。
- ビルド時にページ数が多いと、ビルド時間が長くなる場合がある。
どのような場面で採用するべき？
- 静的コンテンツが多く、更新頻度が少ない Web サイト
例：コーポレートサイト•ブログなど
ISR (Incremental Static Regeneration)
ISR とは、直訳すると段階的な静的サイト生成です。
ページにキャッシュの有効期限を指定することができ、有効期限が切れると、ユーザーがページにアクセスした際に、裏側でページの再ビルド（SSR）が行われてコンテンツが更新されます。
処理の流れ
- クライアントからリクエストが送られる。
- サーバーはリクエストされたページのデータを取得し、ページを生成します。 ここで生成されたページはキャッシュされて、次回以降のアクセスに利用されます。 また、有効期限を設定することが可能で、有効期限が切れたあとの一回は古いキャッシュを返して、裏側でページの再生成(SSR)を行います。
- サーバー側で生成、またはキャッシュされた HTML を返却する。
- ページが表示される
ISR を採用するメリット
- 次回以降アクセスしたユーザーにはキャッシュした HTML を返却するので高速。
- 事前にすべてのページを生成しないので、ビルド時間を大幅に短縮可能。
- 一定期間ごとに SSR を行うため、頻繁に更新する必要があるコンテンツにも対応することができる。
- ISR を採用するデメリット
- 初回アクセス時にページが必要に応じて生成されるため、表示速度が遅くなる可能性がある。
- リアルタイムな更新には対応しづらい場合がある。
- どのような場面で採用するべき？
- 更新頻度が高いサイト
- 全ページのビルドに時間がかかる大規模なサイト
おわりに
以上のように、CSR、SSR、SSG、ISR について整理してみました。
今後はそれぞれのレンダリング方式を状況によって適切な使い分けができるように、実際に動かしながら理解を深めていきたいと思いました。
参考記事
Discussion