サーバーサイドレンダリングとは？リクエストごとに構築される HTML

サーバーサイドレンダリング（SSR）は、リクエストごとにサーバーでページを生成し、ブラウザが埋めなければならない空のシェルではなく、表示準備の整った HTML を送ります。

純粋なクライアントレンダリングのアプリは、ほぼ空の HTML ファイルを出荷してブラウザでページを構築するため、first paint が遅れ、SEO が複雑になります。SSR はまずサーバーで HTML をレンダリングするので、ユーザーはすぐにコンテンツを見られます。もはや静的ファイルだけでなく実行中のサーバーが存在するため、build が何を生み出すか、どう deploy するかを変えます。

SSR の仕組み

各リクエストについて、サーバーはアプリのコードを実行し、最終的な HTML を生成してブラウザに送ります。ブラウザはそれをすぐに表示し、それから hydration を通じてインタラクティブ性を引き継ぐ JavaScript を読み込みます。

SSR 対クライアントサイドレンダリング

クライアントサイドレンダリングは、ブラウザで DOM を構築する JavaScript を出荷するため、最初のレスポンスはほぼ空です。SSR は最初のレスポンスで意味のある HTML を出荷します。SSR は、リクエストごとにサーバーを実行するコストと引き換えに、体感速度と SEO を改善します。

何を犠牲にするか

static hosting だけでなく、実行中のサーバーやサーバーレス関数が必要。
負荷下では、サーバーのレンダリング時間がレイテンシを追加する。
コードは server と browser の両方の環境で実行されなければならない。

SSR を行うフレームワーク

Next.js、Nuxt、Remix、SvelteKit はすべて SSR をサポートします。これらは server と client の境界をぼかし、どちらの場所でもレンダリングするコンポーネントを書けるようにし、フレームワークが hydration を配線します。

CI/CD での SSR

SSR の build は client bundle と server bundle の両方を生成し、deploy 先はファイルを配信するだけでなくその server コードを実行しなければなりません。pipeline は両方を build し、それから server bundle をサーバーレスやコンテナのランタイムに出荷します。これにより、build artifact と deploy ステップは static site より重くなります。

重要なポイント

SSR はリクエストごとにサーバーで HTML をレンダリングし、速い first paint とより良い SEO をもたらします。
実行中のサーバーが必要なため、deploy は static hosting より重くなります。
CI は client と server の両方の bundle を build し、それから server をランタイムに出荷します。