AstroとSSRとSSGの関係性の歴史について

SSGとSSRという言葉を、フロントエンド開発をしたことがある者ならば聞いたことがあるはずだ。それぞれの正式名称は下記の通りである。

SSG ... Static Site Generation
SSR ... Server-Side Rendering

Astroというフレームワークはリリース前、純粋なSSGとして開発されていたようだ。以下は公式ブログ記事からの引用である。

When we set out to build Astro, we decided to focus on the prebuilt, static site architecture popularly called “Jamstack” (also known static-site generation or SSG). （翻訳） Astroの開発に着手した際、私たちは「Jamstack」（静的サイト生成、SSGとも呼ばれる）と呼ばれる、事前に構築された静的サイトアーキテクチャに焦点を当てることにしました。

しかし、現在のAstroはSSRも実装が可能になっている。本番リリースのタイミングでは、SSGもSSRもどちらも使えるウェブフレームワークとなっている。その理由について、SSGのみでは下記のような課題があることを原因として挙げている。

Large sites can’t pre-render to static HTML without introducing longer build times or slower, client-side rendering of dynamic content.

Dynamic sites can’t pre-render to static HTML without forcing you to rebuild and redeploy some portion of your site whenever your data changes.

Interactive sites can’t pre-render to static HTML without moving all user-individualized data to the client. User names, avatars, and permissions all get more complicated when you’re dealing with static, pre-built HTML.

（翻訳）

大規模サイトの場合、ビルド時間の延長や動的コンテンツのクライアント側レンダリングの遅延を招くことなく、静的HTMLへの事前レンダリングを行うことはできません。

動的サイトは、データが変更されるたびにサイトの一部を再構築して再デプロイする必要が生じるため、静的HTMLへの事前レンダリングを行うことはできません。

インタラクティブなサイトは、ユーザー固有のデータをすべてクライアント側に転送しない限り、静的なHTMLにプリレンダリングすることはできません。静的な事前構築済みHTMLを扱う場合、ユーザー名、アバター、権限などはすべてより複雑になります。

ここまでのブログの流れから分かることは、Astroの開発当初はSSGとして開発されたが、SSGでは対処しきれない課題に対応できるようにSSRとしての機能も使えるようになって現在に至る……という歴史である。実に学びのある歴史の授業でした……と言いたいところだが、おそらくSSRもSSGも知らないという方には理解が難しい内容だったことだろう。

本記事の目標は、SSGのみでは解決できなかった下記の課題について納得できることとする。そのためにまずは、SSGとSSRのそれぞれの概要について説明していきたい。

大規模サイトの限界（ビルド時間の増大）： ページ数が数万件に及ぶと、事前にすべてのHTMLを生成するビルド処理が極端に重くなる。
動的データの限界（リアルタイム性の欠如）： データが更新されるたびにサイト全体の再ビルド＆デプロイが必要になり、即時性に欠ける。
パーソナライズの限界（ユーザー情報の扱い）： ログインユーザーごとに表示（ユーザー名や権限など）を変えたい場合、静的HTMLだけでは限界があり、結局クライアント側で重いJavaScriptを動かす必要が出てくる。

SSRとSSGの概要

SSGとSSRの違いを説明するための前提知識として、ブラウザがサイトを表示する流れを思い浮かべて欲しい。

仔細は省くが、サーバーからHTMLやCSS、JavaScriptなどで記述されたデータをブラウザが受け取り、それらを画面上に描画するレンダリングという処理を経てサイトが表示される。ここでサーバーがブラウザに渡すデータの生成タイミングが、SSGとSSRで異なってくる。

Astroを使ってサイトを作成しようとした際、*.astroという拡張子のファイルを実装していくこととなる。これらをAstroのコマンドを使って、Webサイトファイル一式を生成するビルドを行う。このビルドのタイミングで、ブラウザに渡すデータを生成するのがSSGである。一方、SSRはサーバーがブラウザに送付するデータを送るタイミングで生成される。これらをもう少し深掘りして解説したい。

方式	データ生成のタイミング
SSG	ビルド時（事前にまとめて作成）
SSR	リクエスト時（ユーザーがアクセスした瞬間）

SSGにおけるデータ生成

SSG（Static Site Generation）は、Webサイトを公開する前に行う「ビルド（astro build）」のタイミングで、全ページのHTMLをあらかじめ生成しておく方式だ。

例えるなら、「料理を作り置きしておき、注文が来たらそのまま渡すお弁当スタイル」である。

開発・ビルド時： プログラムを実行し、あらかじめ全ページのHTMLファイルを作っておく。
アクセス時： ユーザーからリクエストがあったら、作成済みHTMLを返すだけ。

すでに完成しているHTMLをただ返却するだけなので、サーバー側の計算処理が発生せず、「とにかく爆速でページが表示される」のが最大の特徴である。

しかし、この「ビルド時にすべて作ってしまう」という仕組みこそが、冒頭で触れた3つの限界を生む原因となる。

大規模サイトの限界： 10万ページあれば、ビルド時に10万枚のHTMLを作る必要があるため、事前ビルドに膨大な時間がかかる。
動的データの限界： データベース内の価格や在庫数が変わっても、事前に作ったHTMLは自動で書き換わらない。再度ビルド＆デプロイを行わない限り、最新データが反映されない。

SSRにおけるデータ生成

一方、SSR（Server-Side Rendering）は、ユーザーがページにアクセスしてきた「リクエスト時」に、サーバー上でHTMLを生成する方式だ。

例えるなら、「注文を受けてから厨房で調理して出す、できたての料理」である。

アクセス時： ユーザーからリクエストが届く。
サーバー処理： その瞬間にデータベースへ問い合わせ、最新データやログインユーザー情報を反映させたHTMLをオンデマンドで生成して返す。

アクセスされるたびにサーバーが計算を行うため、SSGほどの超極小なレスポンスタイムとはいかないものの、「常に最新のデータ」や「ログインユーザーごとに異なる画面（マイページなど）」を柔軟に作ることができる。

これこそが、SSGの3つ目の課題であった「パーソナライズの限界」を鮮やかに解決する手段なのだ。

まとめ

SSGとSSR、それぞれのデータ生成タイミングを理解すると、Astroの歴史的な進化の理由が見えてくる。

初期のAstro（純粋なSSG）：
「とにかく高速でZero JSなサイトを作る」ために、 Jamstack / SSG に特化してスタートした。
現在のAstro（SSG + SSRのハイブリッド）：
「大規模サイト」「リアルタイム更新」「ログイン機能やマイページ」といったWeb開発の実務課題に対応するため、SSRの機能も統合した。

Astroは単に流行りに乗ってSSRを取り入れたわけではない。「コンテンツを最速かつ最も柔軟に読者に届ける」というコンテンツ駆動の目的を果たすために、SSGの限界を真摯に受け止め、SSRという武器も手に入れたのだ。