SSR（Server-Side Rendering）は、ユーザーの要求を受けたサーバがテンプレートとデータからHTML文字列を組み立て、完成した画面をブラウザへ返す描画方式です。PHPやRuby on Railsなど従来のWebアプリでは長らく当たり前の手法でしたが、JavaScriptフレームワーク時代に「クライアント描画ではなくサーバで描画し直す」という意味で再定義されました。Next.js（2016年Vercel発表）やNuxt（2016年Sébastien Chopin氏ら発表）が代表で、初回表示の速さとSEOで有利になる点が採用理由として挙げられます。
この記事の目次
- SSRが効く3つの局面
- リクエストからレスポンスまでの流れ
- 採用前に検討する観点
- CSR・SSG・ISRとの比較
- まとめ
SSRが効く3つの局面
SSRが最も価値を発揮するのは、ユーザーがURLを開いた瞬間に意味のある画面が見える必要がある場面です。ブラウザは受け取ったHTMLをそのまま描画するため、JavaScriptのダウンロードや実行を待たずに本文・見出し・画像が映ります。計測指標で言えばFCP（First Contentful Paint）とLCP（Largest Contentful Paint）が短縮され、通信が細い端末や低スペック機でも体感速度が崩れにくいのが特長です。ニュースサイトやECの商品ページのように、初回離脱率がそのまま売上を左右する用途で重宝されます。
もう一つの局面はSEOとSNSプレビューです。Googlebotは現在JavaScriptもある程度実行しますが、レンダリングを後段に回す関係で反映が遅れる場合があり、サーバが既に完成HTMLを返すSSRなら本文がそのまま読み取られます。TwitterやFacebookなどのSNSクローラはJavaScriptをほぼ実行しないため、OGP（Open Graph Protocol）のメタタグをSSRで埋め込むことが共有時のサムネイル表示には不可欠です。EC・メディア・コーポレートサイトでSSRが選ばれ続ける根拠はここにあります。
リクエストからレスポンスまでの流れ
SSRの内部処理は4ステップに整理できます。まずブラウザからリクエストが届くと、Node.jsやDenoなどのサーバが該当ルートのコントローラを実行します。Next.jsならgetServerSidePropsまたはServer Components、Nuxtならasync setupやasyncDataがここで呼ばれ、データベースや外部APIから必要な情報を取得します。認証されたユーザー固有の値も、この段階でセッションから読み取られて画面に反映されます。
次にReactなら renderToString、Vueなら renderToString を使ってコンポーネントツリーをHTML文字列へ変換し、ヘッダ・本文・フッタを連結して完成したHTMLをレスポンスとして返します。ブラウザはそのHTMLを即座にパースして描画するため、初回画面はJavaScript未読込でも見えます。その後にJavaScriptバンドルがダウンロードされ、Hydrationによってボタンやフォームがインタラクティブになります。サーバ計算コストとレスポンス時間がトレードオフになるため、CDNでのエッジキャッシュやストリーミング配信が組み合わされます。
採用前に検討する観点
SSR導入の検討では、最初にトラフィックパターンと負荷見積もりを行います。リクエストごとにサーバがHTMLを組み立てるため、静的配信より明らかにCPU・メモリを使い、突発的なアクセス急増ではオートスケーリングや待ち行列の設計が必要です。ログイン後画面のようにユーザー固有のデータが含まれる場合はキャッシュが効きにくく、認証セッションの取り扱いとパフォーマンスの両立が論点になります。
次に検討すべきはデータ取得のレイテンシです。SSRはサーバがDBや外部APIの応答を待ってからレスポンスを返すため、上流サービスが遅いとTTFB（Time To First Byte）が悪化します。対策としてはステイル・ホワイル・リバリデート方式のCDNキャッシュ、Vercel EdgeやCloudflare Workersのようなエッジでの実行、上流障害時の簡略HTMLによるフォールバックなどが定番です。本番投入前には負荷試験と障害注入で挙動を確認しておくと安心です。
CSR・SSG・ISRとの比較
SSRとCSR（Client-Side Rendering）は、HTMLを誰が組み立てるかが最大の違いです。CSRは空のdivとJavaScriptバンドルだけを返し、ブラウザがAPIを叩いてDOMを構築するため、ログイン後ダッシュボードのように検索エンジン非対象でインタラクションが多い画面に向きます。対するSSRはサーバがHTMLを返し終えるまでレスポンスが発生しないものの、初回が速くSEOに強いという特性があります。Next.jsやNuxtでは画面ごとに方式を切り替えられるため、両者の良いとこ取りができます。
SSG（Static Site Generation）はビルド時にあらかじめHTMLを書き出しておく方式で、更新頻度が低いブログやドキュメントに向きます。ISR（Incremental Static Regeneration）はSSGの拡張で、一定時間ごと、あるいはオンデマンドに再生成する仕組みです。SSRが「毎回作る」、SSGが「事前に作る」、ISRが「事前に作って必要に応じて作り直す」と整理すると関係が把握しやすく、実際のサイトでは記事一覧をISR、商品個別ページをSSR、管理画面をCSRと使い分ける構成が一般的です。
まとめ
SSRはサーバが完成HTMLを返すことで初回表示とSEOを底上げするレンダリング方式で、Next.jsやNuxtによってJavaScriptフレームワークの世界にも標準装備されました。毎リクエスト処理によるサーバ負荷とのトレードオフはあるものの、エッジ実行やキャッシュ戦略と組み合わせれば実用性は高く、CSR・SSG・ISRと画面ごとに使い分ける設計がモダンWebの主流になっています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント