はじめに
タイトルにもあるようにSSRがよくわからんかった。
だから調べた。
それをここにアウトプットします。
調査
なんかわかりやすそうなサイト(小並)
www.ragate.co.jp
- CSR ( Client Side Rendering )
- ブラウザ側でHTMLを生成する際にJSが実行される。
- 初回にページ全体を処理するので、最初の読み込みが遅いがそれ以降速い。
- フロー
- ブラウザがURLへリクエスト
- が空っぽのHTMLを取得
- ブラウザはJSを実行してHTMLやCSSをにレンダリング
- ブラウザはHTMLのに展開されたHTML情報を表示
- SSR ( Server Side Rendering )
- サーバー側でレンダリング(描画)を行う
- CSRと比較するとブラウザでJSを実行しない→コストが低い
- フロー
- ブラウザがURLへリクエスト
- サーバー(NodeJS)がリクエストを受け取り、HTML/CSSを生成
- 完成したHTML/CSSをブラウザにレスポンス、展開する
- SSG ( Static Site Generation )
- ビルド時にHTMLなどのコンテンツが生成され、各リクエスト時に再利用してブラウザにわたす
- リクエスト時にHTML/CSSを生成しないから速い
- ページの更新時にアプリケーション全体をビルドするので、ページ数が多い大規模なアプリケーションには不向き
- フロー
- ブラウザがURLへリクエスト
- ビルド時に生成されていた静的ファイルをブラウザにレスポンス
- ISR ( Incremental Static Regeneration )
- SSGとSSRの昨日を兼ね備えた手法
- 一定時間ごとにバックグラウンドでビルドを行って、APIからのデータ取得や再レンダリングを行ってくれる
- CSR・SSRと比べてデータ更新のリアルタイム性は低いものの、SSGのようなページ速度の速さを実現している。
- SSRのメリット
- SEOに強い
- Googleは読み込みが速いサイトには優先的に検索順位を与える
- SSRは確実にクロールされるので、CSRよりもやや優れている
- 初期描画の表示速度がCSRより速い
- そりゃそう
- 描画スピードがユーザーのネットワーク環境やデバイスのスペックに左右されない
- アプリケーションの仕様変更に強い
- Nuxt or Nextの場合は、
<client-only>で囲むことでSSRのプロジェクトでも一部的にCSRにすることができる
- いろいろ自由(柔軟性が高い)らしい
- 動的なOGPなどはサーバー側での処理が必要(らしい)ので、SSRはよき
- 実行結果をCDNでキャッシュ可能
- CDNとは
- 一つのサーバーだけで、リクエストに対応していたら、遅いじゃん？(ワンオペ的な感じになるからね) それよりも、一つのオリジンサーバーからのレスポンス情報を複数のサーバーでキャッシュしていたら、対応早そうじゃん。(一人のマネージャーがマニュアル作って、それを複数人に配って、お客さんからの要望にマニュアル通りに対応する感じ) そゆこと。
- そりゃそう
