サーバーサイドレンダリングの理由

サーバーサイドレンダリング（SSR）は、Angularアプリをサーバー上で実行し、リクエストごとに完全にレンダリングされたHTMLを生成します。ブラウザーは空のシェルではなく、意味のあるマークアップをすぐに受け取れます。

純粋なクライアントレンダリング（CSR）アプリは、ほぼ空の index.html とJavaScriptを配信します。バンドルのダウンロード、解析、実行が完了するまで、ユーザーやクローラーには空白のページが表示されます。SSRはこの初回表示までの空白時間を解消します。

多くのクローラーやリンクプレビュー用ボットは、最初に返されるHTMLを読み取ります。SSRでは、ページのタイトル、メタタグ、コンテンツがレスポンスに含まれるため、インデックス登録やソーシャルメディアのリッチプレビューが改善されます。

サーバーがレンダリング済みのHTMLを送信するため、ブラウザーはより早くコンテンツを描画できます。これにより、特に低速なネットワークやデバイスで、First Contentful Paint (FCP) と体感速度が改善されます。

SSRでは、JavaScriptの実行後ではなく初期HTMLで主要コンテンツを配信することで、Largest Contentful Paint (LCP) を改善できます。優れた指標は、ユーザー体験と検索順位の両方に役立ちます。

誰かがリンクを共有すると、各プラットフォームはURLを取得し、HTMLからOpen GraphやTwitterのメタタグを読み取ります。SSRなら、これらのタグに実際のページの内容が反映され、正確なカードが生成されます。

HTMLを配信した後、同じアプリがクライアント上で起動し、インタラクティブな動作を引き継ぎます。この処理をハイドレーションと呼びます。最新のAngularは再レンダリングせず、サーバーのHTMLを再利用します。

SSRには、サーバーのコストと複雑さが加わります。Nodeランタイム、サーバー専用コードとブラウザー専用コードの扱い、リクエスト時のレンダリングなどが必要です。アプリにとってのSEOやパフォーマンスの向上と比較して判断してください。

コンテンツが多く、公開されていて、SEOが重要なページ（マーケティングサイト、ブログ、ECの商品一覧など）で特に効果があります。ログイン後に表示する内部ダッシュボードでは、SSRのメリットが小さいことがよくあります。

ほとんど静的なルートでは、プリレンダリング（SSG）によってビルド時にHTMLを生成できます。これにより、稼働中のサーバーなしでSSRに近いメリットを得られます。AngularではSSRとプリレンダリングを併用できます。

最新のAngularは、アプリケーションビルダー、完全なDOMハイドレーション、ルートごとのレンダリングモードを備えたファーストパーティのSSRを @angular/ssr で提供しており、従来のAngular Universal構成よりもSSRがはるかに簡単になっています。

SSRが重要な理由を学びました。初回リクエストで実際のHTMLを返すことで、SEO、ソーシャルプレビュー、FCP、LCPが改善されます。一方でサーバーコストが増えるため、公開されたコンテンツの多いページに適しており、プリレンダリングとも併用できます。最新のAngularでは @angular/ssr によって標準機能として利用できます。